継続的インテグレーション-要件

以下は、継続的インテグレーションの最も重要な要件のリストです。

• Check-In Regularly−継続的インテグレーションが適切に機能するための最も重要なプラクティスは、ソースコードリポジトリのトランクまたはメインラインへの頻繁なチェックインです。コードのチェックインは、少なくとも1日に数回行う必要があります。定期的にチェックインすると、他にも多くのメリットがあります。変更が小さくなり、ビルドが破損する可能性が低くなります。これは、後続のビルドでミスが発生したときに、元に戻すソフトウェアの最新バージョンがわかっていることを意味します。

  また、コードのリファクタリングについてより規律を保ち、動作を維持する小さな変更に固執するのにも役立ちます。多くのファイルを変更する変更が他の人の作業と競合する可能性が低くなるようにするのに役立ちます。これにより、開発者はより探索的になり、アイデアを試し、最後にコミットされたバージョンに戻すことでアイデアを破棄できます。

• Create a Comprehensive Automated Test Suite−自動テストの包括的なスイートがない場合、ビルドに合格するということは、アプリケーションをコンパイルしてアセンブルできることを意味するだけです。一部のチームにとってこれは大きなステップですが、アプリケーションが実際に機能していることを確認するには、ある程度の自動テストを行うことが不可欠です。

  通常、継続的インテグレーションで実行されるテストには3つのタイプがあります。 unit tests, component tests、および acceptance tests。

  単体テストは、アプリケーションの小さな部分の動作を個別にテストするために作成されています。これらは通常、アプリケーション全体を起動せずに実行できます。データベース（アプリケーションにデータベースがある場合）、ファイルシステム、またはネットワークにはヒットしません。アプリケーションが本番環境のような環境で実行されている必要はありません。単体テストは非常に高速に実行される必要があります。大規模なアプリケーションであっても、スイート全体を10分未満で実行できる必要があります。

  コンポーネントテストは、アプリケーションのいくつかのコンポーネントの動作をテストします。単体テストと同様に、アプリケーション全体を起動する必要はありません。ただし、データベース、ファイルシステム、またはその他のシステム（スタブアウトされている可能性があります）にヒットする可能性があります。通常、コンポーネントテストの実行には時間がかかります。

• Keep the Build and Test Process Short −コードのビルドと単体テストの実行に時間がかかりすぎると、次の問題が発生します。

  • 人々はフルビルドの実行を停止し、チェックインする前にテストを実行します。失敗するビルドが増え始めます。

  • 継続的インテグレーションプロセスには非常に長い時間がかかるため、ビルドを再度実行できるようになるまでに複数のコミットが行われるため、どのチェックインでビルドが中断されたかがわかりません。

  • ソフトウェアがビルドされてテストが実行されるのを何年も待つ必要があるため、チェックインの頻度は少なくなります。

• Don’t Check-In on a Broken Build−継続的インテグレーションの最大の失敗は、壊れたビルドをチェックインすることです。ビルドが壊れた場合、責任のある開発者はそれを修正するのを待っています。彼らはできるだけ早く破損の原因を特定し、それを修正します。この戦略を採用すれば、破損の原因を突き止め、すぐに修正するのに常に最適な立場になります。

  同僚の1人がチェックインを行い、その結果ビルドが壊れた場合、それを修正する可能性を最大限に高めるには、問題を明確に実行する必要があります。このルールに違反すると、ビルドが修正されるまでに必然的にはるかに長い時間がかかります。人々はビルドが壊れているのを見ることに慣れており、すぐにビルドが常に壊れたままになる状況に陥ります。

• Always Run All Commit Tests Locally Before Committing− CIサーバーで実行する前に、アプリケーション用に設計されたテストが最初にローカルマシンで実行されることを常に確認してください。これは、適切なテストケースが作成されていることを確認するためであり、CIプロセスで障害が発生した場合は、テスト結果が失敗したことが原因です。

• Take Responsibility for All Breakages that Result from Your Changes−変更をコミットし、作成したすべてのテストに合格したが、他のテストが失敗した場合、ビルドはまだ壊れています。通常、これは、アプリケーションにリグレッションバグが導入されたことを意味します。変更を加えたために、変更の結果として合格しなかったすべてのテストを修正するのは、あなたの責任です。CIのコンテキストでは、これは明白に思えますが、実際には多くのプロジェクトで一般的な方法ではありません。