version-control - ビルド ツールとライブラリをバージョン管理する方法は?

Question

ソース管理システム自体にコンパイラ、ライブラリ、およびその他のツールを含めるための推奨事項は何ですか?

過去に、私はすべてのソース コードを持っていたにもかかわらず、製品の古いバージョンをビルドすることは、Visual Studio、InstallShield、およびその他のツール (を含む製品のビルドに使用される正しいパッチ バージョン)。次のプロジェクトでは、これらのビルド ツールをソース管理にチェックインし、それらを使用してビルドすることで、これを回避したいと考えています。これにより、新しいビルド マシンの設定も簡単になります。1) ソース管理ツールをインストールし、2) 適切なブランチを指定し、3) ビルドします。それだけです。

私が検討したオプションは次のとおりです。

• インストール CD ISO をソース管理にコピーする - 古いバージョンに戻らなければならない場合に必要なバックアップを提供しますが、「ライブ」で使用するには適していません (各ビルドはインストール手順から開始する必要があります)。 、1 時間のビルドを 3 時間に簡単に変えることができます)。
• ソース管理へのソフトウェアのインストール。ClearCase はブランチをドライブ文字にマップします。このドライブの下にソフトウェアをインストールできます。これは、レジストリ設定など、ツールのインストールのファイル以外の部分を考慮していません。
• すべてのソフトウェアをインストールし、仮想マシン内でビルド プロセスをセットアップし、仮想マシンをソース管理に保存し、起動時に VM でビルドを実行する方法を見つけます。「ビルド マシン」の状態を簡単にキャプチャできますが、VM のオーバーヘッドが発生し、「開発者が同じツールを使用できるようにする」という問題には役立ちません。

構成管理の基本的な考え方のように思えますが、これを行う方法についてのリソースを追跡できませんでした。提案は何ですか？

Answer 1

VM が最適なソリューションだと思います。一貫性を保つために、常に専用のビルド マシンを使用していました。古い COM DLL 地獄の時代には、インストールされた非開発ソフトウェア (Office) に (COMCAT.DLL など) への依存関係がありました。最初の 2 つのオプションは、COM コンポーネントを共有しているものは何も解決しません。共有コンポーネントの問題がない場合は、おそらく動作します。

クリーンな環境でデバッグできるようにするために、開発者が同じ VM のコピーを取得できない理由はありません。メールサーバー、データベースサーバーなど、アーキテクチャに多くの物理レイヤーがある場合、問題はより複雑になります。

Answer 2

これは、ご使用の環境に非常に固有のものです。そのため、すべての状況を処理するためのガイドが表示されるわけではありません。私が働いてきたすべての異なる店はこれを異なって扱ってきました。私はあなたに私が私にとって最もうまくいったと思うことについての私の意見を与えることができるだけです。

• アプリケーションを構築するために必要なすべてのものを、ソース管理下の新しいワークステーションに配置します。
• IDE、SDK、データベースエンジンなど、大規模なアプリケーションをソース管理から除外します。これらをISOファイルとしてディレクトリに保存します。
• アプリのビルドに必要なISOファイルのリストを含むテキストドキュメントをソースコードとともに維持します。

Answer 3

私は間違いなく、アイデアを取り巻く法律/ライセンスの問題を検討します。ツールチェーンのさまざまなライセンスに応じて許可されますか？

VMイメージのアイデアが気に入らない場合は、リリースをビルドできる新しい開発マシンをゴースティングすることを検討しましたか？もちろん、ハードウェアの変更時にゴースト化されたイメージを実行し続けることは、価値があるよりも厄介な場合があります...

Answer 4

バージョン管理システムでのライブラリのバージョン管理に関するメモ:

• これは良い解決策ですが、パッケージ化を意味します (つまり、そのライブラリのファイル数を最小限に減らします)。
• 「構成の側面」（つまり、「私の「3.2」プロジェクトにはどの特定のライブラリセットが必要ですか？」）は解決しません。
  set は、プロジェクトの新しいバージョンごとに進化することを忘れないでください。UCM とその「複合ベースライン」は、その答えの始まりを示すかもしれません。

パッケージ化の側面 (ファイルの最小数) は、次の理由で重要です。

• ローカル アクセス ライブラリ ファイルを使用する場合よりもコンパイル時間がはるかに長くなるため、(動的ビューを使用する場合のように) ネットワーク経由でライブラリにアクセスしたくありません。
• ディスクにそれらのライブラリを取得したい、つまりスナップショット ビューを意味し、それらのファイルをダウンロードしたい...そして、これはライブラリのパッケージ化を高く評価する場所です:ダウンロードする必要があるファイルが少ないほど、より良いものになります;)

Answer 5

多くの場合、将来再現できないグローバル マシン設定に依存するのではなく、ソース管理にチェックインされたコンパイラとライブラリをビルドで使用するように強制できます。たとえば、C# コンパイラでは、/nostdlib スイッチを使用し、すべてのライブラリを手動で /reference して、ソース管理にチェックインされたバージョンを指すことができます。もちろん、コンパイラ自体もソース管理にチェックインします。

Answer 6

私自身の質問に続いて、別の質問への回答で参照されているこの投稿に出くわしました。回答というよりも問題の議論ですが、VM のアイデアについて言及しています。

Answer 7

「起動時にビルドする方法を理解する」に関しては、1人のシステム管理者と1人の開発者によって非常に迅速にカスタム作成されたビルドファームシステムを使用して開発しました。ビルド スレーブは、キューに入れられた適切なビルド リクエストをタスクマスターに照会します。それはかなりいいです。

製品はマルチプラットフォームであり、ビルドには自動化されたテストを含めることができるため、ツールチェーンの要件がスレーブのツールチェーンのバージョン (どの OS を含む) と一致する場合、要求はスレーブに「適しています」。通常、これは「最新の状態」ですが、そうである必要はありません。

スレーブのビルド準備が整うと、タスクマスターのポーリングを開始し、インストールされているものを伝えます。何を構築することが期待されているかを事前に知る必要はありません。SVN から特定のタグをチェックアウトするように指示するビルド リクエストを取得し、それらのタグの 1 つからスクリプトを実行してそこから取得します。開発者は、ビルド キューにリクエストを追加する方法だけで、利用可能なビルド スレーブの数、それらの名前、またはビジーかどうかを知る必要はありません。ビルド キュー自体は、かなり単純な Web アプリです。すべて非常にモジュール化されています。

スレーブは VM である必要はありませんが、通常は VM です。スレーブ (およびそれらが実行されている物理マシン) の数は、需要を満たすためにスケーリングできます。スレーブはいつでもシステムに追加でき、ツールチェーンがクラッシュした場合は削除できます。ツールチェーンの状態をアーカイブするという問題ではなく、実際にはこのスキームの要点ですが、適用できると思います。

古いツールチェーンが必要な頻度に応じて、必要に応じてビルド キューで VM を起動できるようにしたい場合があります。そうしないと、古いビルドを再作成したい人が適切なスレーブを表示するように手配する必要があるためです。これが必ずしも難しいというわけではありません。選択したマシンで適切な VM を起動するという問題かもしれません。

Answer 8

私の組織には「読み取り専用」のファイルシステムがあり、すべてがリリースとバージョンに入れられます。リリースリンク (基本的にはシンボリック リンク) は、プロジェクトで使用されているバージョンを指します。新しいバージョンが登場すると、ファイルシステムに追加されるだけで、シンボリックリンクをスイングできます。シンボリック リンクの完全な監査履歴があり、さまざまなバージョンの新しいシンボリック リンクを作成できます。

このアプローチは Linux ではうまく機能しますが、構成などを格納するためにレジストリなどのマシンにローカルなものを使用する傾向がある Windows アプリではうまく機能しません。

Answer 9

ビルドに NAnt などの継続的インテグレーション (CI) ツールを使用していますか?

.Net の例として、ビルドごとに特定のフレームワークを指定できます。

おそらく、開発に使用する一般的な CI ツールには、バージョン管理システムに複数の IDE を保存することを回避できるオプションがあります。