バックグラウンド
これまでのキャリアの中で、Visual Studio でプロジェクトをコンパイルして実行することが実際に困難なプロジェクトを数多く見てきたことに驚かされてきました。通常、問題の原因は次のとおりです: 依存関係の欠落、ドキュメントの欠如、壊れたプロジェクト参照など。
これらの頭痛の種を避けるために、私は次のようなプロジェクト/ソリューションを自動化しようとしています:
- プロジェクトが開発者のマシンでコンパイルされると、ランタイム環境が自動的にセットアップされます (たとえば、バッチ スクリプトを使用して不足している Windows レジストリ キーをインポートします)。
- プロジェクトをコンパイルすると、正しい依存関係が自動的に取得されます (ビルド マシンと開発者マシンの両方で)
問題
今日まで、私はこのアプローチでかなりの成功を収めてきました。しかし、最近、Microsoft Windows SDK に依存するネイティブ C++ プロジェクトを受け取りました。コンパイル時に、プロジェクトは Windows 環境変数を使用して不足している依存関係 (Microsoft Windows SDK など) を見つけます。
環境変数を使用することが、以前は行われていた方法であることを理解しています。ただし、ソフトウェア開発者に依存して開発環境を構成すると、次のようになります。
- あなたは彼らが環境を適切に構成すると仮定しています
- 開発者は、開発に費やすべき時間を設定に費やしている
開発者に開発環境を構成してもらうことのメリットについて議論したくはありませんが、知りたいのは次のとおりです。
今日存在するテクノロジ (TFS など) を考えると、チーム環境で C++ プロジェクトの大きな依存関係 (Windows SDK など) を処理するための、信頼性が高く反復可能なアプローチは何ですか?
考えられる解決策
- 環境変数を使い続ける
- Adv: 依存関係がインストールされると、ビルド マシンがプロジェクトをコンパイルするのは非常に簡単です。
- 欠点: ビルド マシンを最初から構成できるようにするには、文書化に時間を費やす必要があります (たとえば、ステップ 1: 依存関係 A をインストールし、ステップ 2: 依存関係 B をインストールするなど)。
- Dis:魔法の環境変数が正しいターゲットを指していることに依存しています。
- Dis: 開発者は、開発すべき時期を設定するのに時間を浪費している
- 依存関係を TFS にチェックインする
- Adv: すべてが一元化された場所に保管されます
- Adv: 設計上、ソース管理は履歴を保持します
- Adv: ある意味で、ソース管理は物事を自己文書化します
- Dis: ビルド マシンのワークスペースが TFS から Windows SDK を繰り返し取得する必要があるため、ビルド マシンでのコンパイルにかなりの時間がかかるようになりました。
- 他の？
環境
- プログラミング言語: アンマネージ C++
- ソース管理: TFS 2012
- 依存関係:
- Microsoft Windows SDK (~416Mb)
- 家の図書館で
- TFS ビルド マシンを管理/構成する方法についての知識は限られています。
参考文献
- Microsoft: Visual Studio TFS を使用したチーム開発 (第 6 章)