仕様文書をsvnなどのソース管理システムに配置する必要がありますか？

11

今日、同僚の1人と「SVNなどのソース管理システムに仕様書を入れるべきか」について議論しています。私の意見では、そうあるべきです。プロジェクトの開発に関連するすべてのものは、ソース管理システムで慎重に管理する必要があります。ソフトウェア開発プロセスの概念は間違っていますか？

version-control specifications

— エジソン・チュアン
ソース

4

それでは、ほとんどのソース管理システムがそれらをブロブとしてのみ保存する場合はどうでしょうか？ほとんどの人はドキュメント間の差分についてリッピングしませんが、もしそうすれば、いつでも2つのバージョンを取得し、オーサリングシステムの機能を使用してそれらを差分できます。

— SnoopDougieDoug
ソース

2

確かに、SVNが常に現在のバージョンを持っていることを確認してくれるとうれしいです。ほとんどの場合、差分はそれほど重要ではありません。

— ザカリーK

それだけが問題ではありません。複数の編集者がいる場合、変更のロックと上書きが問題になります

— ニコル

1

文書の相違は重要ではありません。しかし、PMにとっては、仕様の変化を見る能力が非常に重要です。

— マーティンヨーク

この回答は、他の回答に関するコメントのようです。たとえば、質問ではBLOBについては何も言及されていません。

— ブライアンオークリー

15

ハードディスクの空き容量が1ギガバイト/月であるため、ソース管理システムにドキュメントを配置しない正当な理由はなく、有用である可能性があります。私の個人的な好みは、インラインマークアップを使用してドキュメントを書くことです。たとえば、WikiマークアップやDocBookです。これにより、ドキュメントの比較と改訂に強力なツールを使用できます。

— ケビン・クライン
ソース

3

他に何もなければ、仕様のv1.0がどのように見えるかを見るのは面白いです。

— マーティンベケット

8

仕様書のバージョン管理は間違いなく価値のある目標です。

しかし、あなたの仕様書はテキストのみでプレーンテキストファイルにありますか？もしそうなら、これは良い解決策かもしれません。

そうでない場合、ソース管理はおそらくそれらに適した場所ではありません。ソース管理はバイナリファイルには不適切です。

通常、プレーンテキストファイルは、書式設定やクイックビューには適していません。そのため、バージョン管理機能付きのWikiを使用する方がよいでしょう。

— ニコール
ソース

通常、ドキュメントにはプレーンテキストコンテンツだけでなく、UML図などの画像も含まれます。バイナリ形式のファイルはソース管理システムに適していないことに完全に同意します。しかし、何もないよりはましだと思います。正しい？ウィキがあれば、採用できます。それは素晴らしいことです。しかし、私はそれを心配しています。Wikiの使い方を学ぶには「忙しすぎ」ます。（悲しい）

— エジソンチュアン

1

現在、WYSIWYGエディターを備えた多くのWikiがあります。私は非常に消極的なシェアポイント変換です。開発者として、私はsharepointを情熱を持って嫌っていました。次に、SharePointに付属するMicrosoft BPOSにサインアップし、リモートチームメンバーとのプロジェクトでのコラボレーションに使用しました。Wiki、フォーラム、カレンダー、ドキュメントライブラリ（Microsoft Office Docsの追跡を行う）、およびプロジェクトのコラボレーションを非常に簡単にする他の多くの機能を備えています。生きている仕様としてのWikiは、それが提供する歴史のために完璧だと思います。

— マイケルブラウン

厳密に言えば、ソース管理はバイナリファイルにとっては悪くありません。何らかの方法でそれらを破壊したり変異させたりするようなものではありません。ただし、おそらく、バイナリファイルはソース管理に悪影響を及ぼすが、それは、それらが大量のディスク領域を占有し、クローン作成が遅くなるからです。ただし、ディスクスペースは安価であるため、5年前ほど悪くはありません。

— ブライアンオークリー

1

すべてのドキュメントは、何らかの形式のアーカイブである必要があります（できれば、リビジョン管理が必要です）。

ソース管理システムは1つのソリューションです。ただし、通常、これらのシステムはプレーンテキストドキュメント用に設計されています。そのため、WordやRTFドキュメントなどはそれほどうまく適合しません（特に異なるバージョンを試して比較する場合）。

しかし、ドキュメント専用に設計された他のソリューションがあります。SharePointが思い浮かびますが、他にもあるはずです。

— マーティン・ヨーク
ソース

0

間違いなく。文書がバイナリ（たとえば、単語文書）として保存されるという問題は厄介です。良い回避策は、Tortoiseツール（SVNとMercurialを試しました）のいずれかを使用する場合、docdiffを選択できる「Visual Diff」を選択できることです。docdiffを使用すると、すべての変更を色やもので確認できます:-)。主な欠点は、変更を加えるたびに、ドキュメント全体が（変更だけでなく）再度コミットされることです。しかし、テキスト文書は通常巨大ではなく、おそらくそのスペースが主な問題ではないことを考えると、これは問題ありません。

Tortoiseを使用せずにdocdiffを使用できると確信しています。試したことがないだけです。

— オマール・コール
ソース

ただし、「複数のエディターからの変更を上書きする」問題は解決しません。

— オマーコール

0

議論すべき代替アプローチがあります：BDD

実行可能な仕様での振る舞い駆動開発を検討してください。仕様は、一連の指定された-いつ-テキストファイルに格納される一連のステートメントに簡素化されます。CucumberやSpecFlowなどのBDDツールは、これらのテキストファイルを実行可能なテストに変換し、ビルドツールで実行できます。

キュウリ：http : //cukes.info/-Rubyの BDD

SpecFlow：http : //www.specflow.org/-.Netの BDD

SpecFlowなどのツールを使用したワークフローの簡単なデモについては、Rob ConeryのSpecFlowウォークスルーをご覧ください：http ://tekpub.com/view/concepts/5

これで、コードのバージョン管理だけでなく、仕様、および継続的統合ツール（TeamCity、CruiseControl、Hudsonなど）が、すべての仕様がすべてのビルドで有効であることを強制しています...それはあなたにとって価値がありますか？

— ジェフ・フリッツ
ソース