苦労した経験から、ほとんどすべてがソース管理に属していることがわかりました。（ここでの私のコメントは、プロプライエタリなハードウェア上に埋め込まれた/テレコムシステム用に開発された10年半の色で、プロプライエタリで、時には見つけにくいツールもあります。）
ここでの答えのいくつかは、「ソース管理にバイナリを入れないでください」と言っています。それは間違っている。サードパーティのコードが多く、ベンダーのバイナリライブラリが多数ある製品で作業している場合は、バイナリライブラリをチェックインします。そうしないと、ある時点でアップグレードを行うことになり、トラブルに直面するからです。ビルドマシンに最新バージョンがないため、ビルドが中断します。誰かが、新しい男にインストールする古いCDを提供します。プロジェクトwikiには、インストールするバージョンに関する古い指示があります。さらに悪いことに、特定の問題を解決するためにベンダーと緊密に協力する必要があり、1週間で5セットのライブラリを送信する場合は、どのバイナリのセットがどの動作を示したかを追跡できます。ソース管理システムは、まさにその問題を解決するツールです。
ここでの答えのいくつかは、「ツールチェーンをソース管理に入れないでください」と言っています。間違っているとは言いませんが、堅実な構成管理（CM）システムがない限り、ツールチェーンをソース管理に入れる のが最善です。繰り返しますが、上記のアップグレードの問題を考慮してください。さらに悪いことに、私は、雇われたときにツールチェーンの4つの異なるフレーバーが浮かんでいるプロジェクトに取り組みました- それらはすべてアクティブに使用されています！（ビルドを機能させることができた後）最初にしたことの1つは、ツールチェーンをソース管理下に置くことでした。（堅実なCMシステムのアイデアは、期待を超えるものでした。）
また、プロジェクトごとに異なるツールチェーンが必要な場合はどうなりますか？適切な事例：数年後、プロジェクトの1つがベンダーからアップグレードされ、すべてのMakefileが壊れました。彼らはGNU makeの新しいバージョンに依存していたことが判明しました。だから私たちは皆アップグレードしました。おっと、別のプロジェクトのMakefileがすべて壊れました。レッスン：GNU makeの両方のバージョンをコミットし、プロジェクトチェックアウトに付属するバージョンを実行します。
または、他のすべてが手に負えない場所で作業している場合、「ねえ、新しい男が今日始めている、コンパイラのCDはどこにあるの？」「ダンノ、ジャックが辞めてから彼らを見たことがない、彼はCDの守護者だった。」「うーん、2階から上に移動する前にそうではなかったのですか？」「たぶん彼らは箱か何かの中にいるでしょう。」また、ツールは3年前のものなので、その古いCDをベンダーから入手する見込みはありません。
すべてのビルドスクリプトはソース管理に属します。すべて！環境変数に至るまで。ビルドマシンは、プロジェクトのルートで1つのスクリプトを実行することにより、プロジェクトのビルドを実行できる必要があります。（./build合理的な標準です。./configure; makeほぼ同様です。）スクリプトは必要に応じて環境を設定し、製品をビルドするツール（make、antなど）を起動する必要があります。
仕事が多すぎると思うなら、そうではありません。実際、大量の作業を節約できます。時間の初めに一度ファイルをコミットし、その後、アップグレードするたびにコミットします。一人のオオカミが自分のマシンをアップグレードし、いくつかのツールの最新バージョンに依存する多数のソースコードをコミットして、他の人のビルドを壊すことはできません。新しい開発者を雇うとき、プロジェクトをチェックアウトして実行するように彼らに伝えることができます./build。バージョン1.8に多くのパフォーマンスチューニングがあり、コード、コンパイラフラグ、および環境変数を微調整する場合、コードが本当に必要なため、新しいコンパイラフラグがバージョン1.7パッチビルドに誤って適用されないようにする必要があります。それらに伴う変化、またはいくつかの毛深い競合状態が見られます。
何よりも、いつかはお尻を救います：月曜日に製品のバージョン3.0.2を出荷すると想像してください。やったー 火曜日の朝、VIPの顧客がサポートホットラインに電話し、18か月前に出荷したバージョン2.2.6のこの超臨界で緊急のバグについて苦情を申し立てます。そして、あなたはまだそれをサポートする必要があり、バグは新しいコードで修正されたことを確認できるまでアップグレードを拒否し、あなたを踊らせるのに十分な大きさです。2つの並列ユニバースがあります。
ソース管理にライブラリ、ツールチェーン、ビルドスクリプトがなく、堅実なCMシステムがない宇宙では...正しいバージョンのコードをチェックアウトできますが、ビルドしようとすると、あらゆる種類のエラーが発生します。5月にツールをアップグレードしましたか？いいえ、それはライブラリでした。わかりました、古いライブラリに戻ります-待って、2つのアップグレードがありましたか？ああ、それは少し良く見えます。しかし今、この奇妙なリンカのクラッシュはおなじみに見えます。ああ、それは古いライブラリが新しいツールチェーンで動作しなかったからです。だからアップグレードする必要がありましたよね？（残りの努力の苦しみをspareしまない。2週間かかり、最後には誰も幸せではない。あなたも、経営者も、顧客もそうではない。）
すべてがソース管理内にあるユニバースでは、2.2.6タグをチェックアウトし、1時間程度でデバッグビルドを準備し、1、2日かけて「VIPバグ」を再現し、原因を突き止め、修正します。現在のリリース、およびアップグレードするように顧客を説得します。ストレスが多いが、ヘアラインが3cm高い他の宇宙ほど悪くはない。
そうは言っても、あなたはそれをやりすぎます：
- 「ゴールドコピー」がある標準OSをインストールする必要があります。おそらくREADMEで、それを文書化している将来の世代は、バージョン2.2.6およびそれ以前のが唯一のRHEL 5.3および2.3.0で構築された以降のみのUbuntu 11.04上に構築されたことを知っているように、ソース管理に。この方法でツールチェーンを管理する方が簡単な場合は、信頼できるシステムであることを確認してください。
- プロジェクトのドキュメントは、ソース管理システムで管理するのが面倒です。プロジェクトドキュメントは常にコード自体よりも先にあり、現在のバージョンのコードを作成中に次のバージョンのドキュメントを作成することは珍しくありません。特に、すべてのプロジェクトドキュメントが、差分やマージができないバイナリドキュメントである場合。
- ビルドで使用されるすべてのバージョンを制御するシステムがある場合は、それを使用してください！ビルドマシンを含む全員が同じツールセットからプルできるように、チーム全体で簡単に同期できるようにしてください。（Debianのpbuilderやpythonのvirtualenvの責任ある使用法のようなシステムを考えています。）