4

何年にもわたって、完全なプロジェクト ビルドを実行するために一連の NAnt スクリプトを作成および調整してきました。メイン スクリプトは、単一のアプリケーション エンドポイント (たとえば、Web アプリケーション プロジェクト) を取り、ソース管理から完全なビルドを行います。スクリプトは、ビルド出力場所、ソース管理アドレスなどに関する必要な情報で事前構成されています。主なポイントは、スクリプトにほとんど情報を供給せず、特定のプロジェクトをゼロから構築できることです。これは、私の質問の「任意」の部分を満たしています。

過去に、いくつかのソフトウェア製品 (主に Web アプリケーション) を作成する会社で働いていました。この環境は、製品ごとにインテグレーターが存在する典型的な継続的インテグレーションのセットアップに非常に適しています。CI ビルドの両方として機能するインテグレーターと、完全なリリース候補ビルドと QA 展開を処理するインテグレーターをセットアップしました。これらのインテグレーターはマスター ビルド スクリプトを使用するため、インテグレーター自体は、ソース管理の監視とマスター NAnt スクリプトの呼び出しにすぎません。

私は現在、多くのアプリケーションを作成する開発グループで働いています。多くの場合、開発者は、最初に他の人が作成したアプリケーションをサポートするよう求められます。私が始めたとき、ビルド管理はありませんでした。私は、1 つのビジネス ユニットの製品スイート (約半ダースの完全なシステム) の 4 人のチームの主任開発者として、グループ内で特にユニークな立場にあります。CI ビルドと RC ビルドの両方を実行するためのマスター ビルド スクリプトを使用して、CruiseControl.Net を実装しました。これは、ビジネスの製品スイート内の固定されたプロジェクトのセットに対して機能します。

私は何年もの間 CCNet を使用してきたので、CCNet で何ができるかを十分に認識しています。製品スイートのすべてのプロジェクトで使用しているため、継続的インテグレーションの分野への貢献に大きな敬意を払っています。私は自分のチームに、開発以外の場所に向けられたもののマスター ビルダーとして、公式の RC ビルド インテグレーターを使用することを強調しました。これにより、CCNet の管理下にあるプロジェクトの固定セットを大幅に管理できます。

ただし、他のアプリケーションを構築している他の開発者もいます。これらのいくつかは、プロジェクトのライフ サイクル (私が変更しようとしている他の何か) に入るまでソース管理さえされないことが多い 1 つの開発者プロジェクトです。これらのプロジェクトの多くは 1 回限りのものであり、デプロイされた後はあまり開発されません。それにもかかわらず、彼らはまだサポートする必要があります。それらをサポートする上で不可欠なのは、これらのプロジェクトの集中ビルド管理がなければ、QA に送られ、最終的には本番用のリリース候補ビルドが個々の開発者マシンで行われることになります。もちろん、これは、開発者のマシン ビルドの他の要因の中で、すべてがソース管理下にあるという保証をまったく提供しません。

私が解決しようとしている問題は、この種の任意のビルドを集中管理するためにどのようなシステムを使用できるかということです。これは間違いなく固有の問題ではありません。ただし、集中型ビルド、ビルドの自動化、および継続的インテグレーションについて私が行った多くの読書では、固定されたプロジェクト/製品と、それらの継続的な開発をサポートするタスクに焦点が当てられています。常に新しいプロジェクトの開発を行っているビジネスでは、どのようなプロセスが使用されていますか? これらのタイプのプロセスを使用していませんか?

マスター ビルド スクリプトはビルド サーバー上に存在しますが、使いにくいです。また、ビルド サーバーへのコンソール アクセスを制限したいと思います。そのため、中央システムで任意のビルドを起動するためのより簡単なアクセスを提供するために、何らかの管理システムが必要です。

私が探しているものは、MS Team Build のカバーの下にある可能性があることに気付きました。残念なことに、MS について読み始めると、MS のマーケティング資料を読み始めると流砂のような気分になり、すぐに道に迷い、自分がやりたいことがそれでできるかどうかを実際に知ることができなくなります。さらに、ライセンス コストは、Team Foundation Server と Team System のトピックに関する過去の一般的な議論で、目立たないものとして取り上げられてきました。

この問題を解決した人からの提案をお待ちしています。私は、マスターの "build-any-project" ビルド スクリプトに基づいた集中型ビルド システムでいくつかの作業を行いました。ただし、私が持っているものはまだ初期段階にあり、主に私が取り組んでいるプロジェクトの種類だけをサポートするように構築されています。現時点では、多くの種類のアプリケーションや、Visual Studio で可能な大量のプロジェクト/ソリューション構成を処理するために必要なサポートが不足しています。

4

1 に答える 1

3

中央ビルド システムで私が目にする最大の問題は、世界で最高の意志を持っていても、ツールがチーム間または時間の経過とともに分岐することです。

単一のモジュールをチェックアウトする必要があるような、特定のプロジェクト用のビルドシステムを設計することを好みます。MyProjectBuildEnvironment を作成し、Windows システムの build.bat など、非常にツールに依存しない方法で単一のスクリプトを実行します。

可能であれば、マシン レベルのインストーラーを必要とするのではなく、モジュール MyProjectBuildEnvironmen をチェックアウトするだけで、ビルド環境で使用されるすべてのツールを実行できるようにする必要があります。

これら 2 つの制約は、チームがその時点で好みのツールを使用する自由を妨げるものではありません。

セントラル ビルド システムは、プロジェクトごとに 1 つのモジュールをチェックアウトし、build.bat ファイルを実行するだけの単純なシステムにすることができます。メタ ビルド システムと呼ぶことができます。

正直に言うと、各プロジェクトのビルド モジュール名を説明する単純な wiki だけで、誰でもその 1 つのモジュールをチェックアウトして共通の build.bat コマンドで開始できるようにするのに十分なので、おそらくやり過ぎでしょう。

最後に、ビルドを開始するためのスクリプトは常に環境を調べて、不足しているツールがないか、またはビルドを正常に完了するためにマシン構成を微調整する必要があるかどうかをユーザーに通知する必要があります。

于 2008-09-10T09:26:42.707 に答える