Continuous-integration-requirements
提供：Dev Guides
継続的インテグレーション-要件
以下は、継続的インテグレーションの最も重要な要件のリストです。
- 定期的なチェックイン-継続的インテグレーションが適切に機能するための最も重要なプラクティスは、ソースコードリポジトリのトランクまたはメインラインへの頻繁なチェックインです。 コードのチェックインは、少なくとも1日に2〜3回行う必要があります。 定期的にチェックインすると、他にも多くのメリットがあります。 変更が小さくなり、ビルドが壊れにくくなります。 これは、以降のビルドでミスが発生した場合に戻す、ソフトウェアの最新バージョンが既知であることを意味します。 +また、コードのリファクタリングに関する規律を強化し、動作を維持する小さな変更に固執するのにも役立ちます。 多くのファイルを変更する変更が他の人の作業と競合する可能性が低くなるようにするのに役立ちます。 これにより、開発者はより探索的になり、アイデアを試し、最後にコミットされたバージョンに戻すことでアイデアを破棄できます。
- 包括的な自動テストスイートを作成します-自動テストの包括的なスイートがない場合、ビルドの合格は、アプリケーションをコンパイルおよびアセンブルできることを意味します。 一部のチームにとってこれは大きなステップですが、アプリケーションが実際に機能していることを確信できるように、ある程度の自動テストが不可欠です。 +通常、継続的インテグレーションでは、ユニットテスト、コンポーネントテスト、および*受け入れテスト*の3種類のテストが実施されます。 +単体テストは、アプリケーションの小さな部分の動作を個別にテストするために作成されています。 通常、アプリケーション全体を起動せずに実行できます。 データベース（アプリケーションにある場合）、ファイルシステム、またはネットワークにはヒットしません。 アプリケーションを本番環境で実行する必要はありません。 単体テストは非常に高速に実行する必要があります。大規模なアプリケーションであっても、スイート全体を10分以内に実行できる必要があります。 +コンポーネントテストは、アプリケーションのいくつかのコンポーネントの動作をテストします。 単体テストのように、アプリケーション全体を常に開始する必要はありません。 ただし、データベース、ファイルシステム、または他のシステム（スタブアウトされている可能性があります）にヒットする可能性があります。 通常、コンポーネントテストの実行には時間がかかります。
- ビルドとテストのプロセスを短く保つ-コードのビルドと単体テストの実行に時間がかかりすぎると、次の問題が発生します。
- ユーザーはフルビルドの実行を停止し、チェックインする前にテストを実行します。 失敗するビルドが増え始めます。
- 継続的インテグレーションプロセスには時間がかかるため、ビルドを再度実行できるようになるまでに複数のコミットが行われるため、どのチェックインがビルドを中断したかはわかりません。
- ソフトウェアがビルドされ、テストが実行されるのを何年も待たなければならないため、チェックインの頻度が少なくなります。
- 壊れたビルドでチェックインしない-継続的インテグレーションの最大の欠点は、壊れたビルドでチェックインすることです。 ビルドが壊れた場合、責任のある開発者はそれを修正するのを待っています。 破損の原因をできるだけ早く特定し、修正します。 この戦略を採用すれば、破損の原因を突き止めてすぐに修正するために常に最適な立場になります。 +同僚の1人がチェックインを行い、その結果ビルドが壊れた場合、それを修正する最善の機会を得るために、問題を明確に実行する必要があります。 このルールが破られると、ビルドの修正に時間がかかります。 人々は、ビルドが壊れているのを見ることに慣れ、非常に迅速に、ビルドが常に壊れたままになる状況に陥ります。
- コミットする前にすべてのコミットテストをローカルで常に実行する-CIサーバーで実行する前に、アプリケーション用に設計されたテストがローカルマシンで最初に実行されることを常に確認します。 これは、適切なテストケースが書き込まれるようにするためであり、CIプロセスに障害が発生した場合は、テスト結果が失敗したためです。
- 変更の結果として生じるすべての破損に対する責任を取ります-変更をコミットし、作成したすべてのテストに合格し、他のテストが破損しても、ビルドは破損します。 通常、これは、アプリケーションに回帰バグを導入したことを意味します。 変更の結果として合格していないすべてのテストを修正するのは、変更を行ったためです。 CIのコンテキストではこれは明らかなように見えますが、実際には多くのプロジェクトで一般的な慣行ではありません。
