ビルドスクリプトとビルドサーバーの責任

ビルドスクリプトとビルドサーバーの責任について明確にする必要があります。

継続的な統合とビルドに関するいくつかのネット上の記事を読みました。含む

• F5キーはビルドプロセスではありません
• ビルドサーバー：プロジェクトのハートモニター
• 毎日のビルドはあなたの友達

そして、私たちのソフトウェアのビルドプロセスについてアドバイザーと会話しました。彼は非常に経験豊富であるため、私は彼の発言を信頼しますが、混乱が残りました。

私が理解しているように、私の研究から（そして私が尋ねているのでここで私を修正してください）理想は次のようになるはずです：

• すべてのプロジェクトにはビルドスクリプトがあります
• このスクリプトはプロジェクトをビルドします
• このスクリプトは、依存関係が以前に構築されていることを確認します

依存関係は他のプロジェクトになる可能性があるため、独自のビルドスクリプトを使用すると、ツリーのような階層が生じます。すべてのプロジェクトとアプリケーションをビルドするトップビルドスクリプトがある場合があります。

ただし、ビルドサーバーの責任は次のとおりです。

• リポジトリをチェックアウトする
• ビルドをトリガーする
• トリガーテストおよびその他のQAツール
• アーティファクトを利用可能にする

これは、手動で、夜間に、またはリポジトリが変更されるたびにトリガーされます。

私のアドバイザーの目的は、私が理解しているように、1つのビルドスクリプトは柔軟性がなく、維持できない方法であるということです（レガシーコードベース用に作成するのに非常に時間がかかるという事実は別として）。また、ビルドサーバーは依存関係を維持する必要があります。たとえば、新しい依存関係を作成するときに古い依存関係を使用すると失敗します。特にAnt、具体的な主題であったため、コードベースで使用されるあらゆる種類の異なるテクノロジーを構築することはできず、依存関係を維持することもできません。

目的を詳しく説明して、責任を明確にしてください。

これらは直交しています：

ビルドスクリプトはたてチェックアウトソースツリー上の呼び出し時に、必要なターゲットと依存関係の完全なビルドを生み出す、という仕組みです。メイクファイルがある場合は単に「すべてを作成する」ことも、MSBuild、Ant、Maven、またはSconsを適切に呼び出すこともできます。依存関係または関連プロジェクトの複雑な階層がある場合、「ビルドスクリプト」はトップレベルのファイルであり、それらを順番に呼び出して、成功を確認します。

ビルドスクリプトは、チェックアウト、ビルド、テスト、パッケージなど、おそらく多数のスクリプトのうちの1つにすぎませんが、コマンドラインパラメーターによって制御されるオールインワンメカニズムを使用することもできます。環境によって異なります。

ビルドサーバー、またはむしろ継続的統合サーバーは、チェックアウト->ビルド->テスト->パッケージ->ステージ->パイプラインのデプロイのスケジューリング/トリガー、監視、レポートを行う自動化メカニズムです。洗練されたものが手元にない場合は、cron /タスクスケジューラを使用できますが、Jenkins、Cruise Control、TeamCityなどの優れたツールが多数あります。

ビジー/オフライン/到達不能/その他の理由で利用できない場合、CIサーバーを使用せずにビルドを呼び出すことができることが重要です。そのため、ビルド/テスト/実行を取得するロジックはCIシステム。ただし、それによって起動可能で、ブランチ/ビルドタイプ/バージョン/アーキテクチャなどによってパラメータ化されます。