ビルドツールの責任はどこで終わり、CIツールの責任はどこから始まりますか？
ソフトウェアの配信において、そして デプロイメントパイプライン の意味で、Mavenなどのビルドツールの責任はどこで終わり、CIの責任はどこから始まりますか？
発生する問題の大まかな例として;ビルドツールは、実際にアーティファクトをビルドするよりもパイプラインのさらに下にあるときに、受け入れテストの構成と実行に責任を持つ必要がありますか？
私の例のように、具体的なものではなく、展開のライフサイクルフェーズの意味で対処する回答が必要です。例は答えを強化するのに役立ちますが。
このコメント 正しいように聞こえます。
私の意見では、ビルドコードのできるだけ多くは、antのbuild.xml、mavenのpom.xmlなどの製品の内部ビルドスクリプトに含める必要があります。これには3つの目的があります。
- ビルドプロセスを製品とともにバージョン管理します。ソース管理で製品のブランチをフォークし、ビルドの変更が必要な変更を加えた場合（たとえば、以前は存在しなかったjavascriptファイルにミニファイステップを追加する場合）、ソース管理の外部で変更する必要はありません。
- 開発とオンボーディングの容易さ。開発者として、ソース管理からコードをチェックアウトしてビルドコマンドを実行できると、生産性が向上します。
ant clean buildやmvn packageなどです。 - ビルドのCIへの依存を削除します。 shouldビルドにCIを使用しますが、何らかの理由でJenkinsがダウンしている場合は、ビルドできなくしたくありません。 CIは、既存の合理化されたビルドプロセスの自動化に関するものでなければなりません。
理想的には、CIサーバーは単にこれを行うように構成する必要があります。
- チェックアウト
- ビルドコマンドを実行します。できれば、開発者が実行するのと同じコマンドか、おそらくそれらのコマンドのスーパーセットを実行します。
- ビルドを公式のビルドアーカイブの場所にアーカイブします。
これがあまり明確にならないのは、ビルド時に発生するが、単体テストや統合テストなど、ビルドに厳密に必要ではないプロセスです。
私の好みは、コアビルドに単体テストを含めることです。つまり、単体テストを実行して合格しないと、開発でもビルドを取得できません。もちろん、それは膨大な規律を必要とし、めったに行われません。幸運なことに、自動化された単体テストを実行する環境があり、コアビルドにそれらを含めるのは良い考えのようです。
ただし、統合テストはさらに時間がかかる可能性があるため、コードをコンパイルしたいときにいつでもテストを実行すると、生産性が大幅に低下する可能性があります。すべてのコンパイル->テストサイクルに1時間の統合テストスイートが必要かどうかを想像してみてください。コンパイルの頻度を減らすことで補うことができます。つまり、テストが少なくなり、当然、そこから得られるメリットはありません。
私がすることは、ソース管理内のビルドスクリプトでそのような機能を定義することですが、notそれらをコアビルドにワイヤリングします。 Mavenについてはよく知りませんが、antの場合は、明示的に実行する必要があるant integrationTestsのような別のターゲットを定義します。これはCIシステムで構成でき、そのようにして、開発者は自分のシステムで実行するかどうか、いつ実行するかを選択できます。
パイプラインビューに入れるには、おそらく次のようなものです。
チェックアウト->ビルド->統合テスト->システムテスト->パフォーマンステスト->ロードテスト->ビルドのアーカイブ->デプロイ
これらの各ステップの実装は、ソース管理の製品のビルドスクリプト内にある必要があり（チェックアウトを除く、そうでない場合は鶏が先か卵が先か問題があります）、ビルドprocessがどのステップを呼び出すかの決定を所有しますどのような順序で。すべてのビルドで特定の手順が必要になるとは限りません。たとえば、負荷テストは、リリース後に1回だけ実行される可能性があります。
それは私の2セントです。私はこの件に関する権威ではありませんが、ビルドがうまく行われ、ビルドがうまく行われていないのを見てきました。