Continuous-integration-overview
提供：Dev Guides
継続的インテグレーション-概要
継続的インテグレーションは、*クルーズコントロール*と呼ばれるソフトウェアで2000年に初めて導入されました。 長年にわたり、継続的インテグレーションはあらゆるソフトウェア組織で重要なプラクティスになりました。 これは、ソフトウェアチームに加えられたすべてのコード変更に対してビルドとその後のテストが確実に実行されるように開発チームを呼び出す開発プラクティスです。 この概念は、ビルドライフサイクルで問題の発生を遅らせる問題を取り除くことを目的としていました。 開発者が単独で作業して十分な統合を行わない代わりに、コードの変更とビルドが単独で行われないようにするために、継続的統合が導入されました。
なぜ継続的統合なのか？
継続的インテグレーションは、ソフトウェア開発プロセスの非常に不可欠な部分になっています。 継続的な統合プロセスは、ソフトウェア開発チームにとって次の質問に答えるのに役立ちます。
- すべてのソフトウェアコンポーネントが必要に応じて連携して動作しますか？ –システムが非常に複雑になり、各コンポーネントに複数のインターフェースが存在する場合があります。 このような場合、すべてのソフトウェアコンポーネントが相互にシームレスに動作することを保証することが常に重要です。
- コードは統合のために複雑すぎますか？ –継続的インテグレーションプロセスが失敗し続ける場合、コードが複雑すぎる可能性があります。 そして、これは適切な設計パターンを適用して、コードの複雑さを軽減し、保守性を高めるためのシグナルになる可能性があります。
- コードは確立されたコーディング標準に準拠していますか？ –ほとんどのテストケースでは、コードが適切なコーディング標準に準拠していることを常にチェックします。 自動ビルド後に自動テストを実行することにより、これは、コードが必要なコーディング標準をすべて満たしているかどうかを確認するのに適しています。
- 自動テストでカバーされるコードの量は？ –テストケースがコードの必要な機能をカバーしていない場合、コードをテストしても意味がありません。 そのため、書かれたテストケースがアプリケーションのすべての主要なシナリオをカバーすることを保証することは常に良い習慣です。
- 最新の変更後、すべてのテストは成功しましたか？ –テストが失敗した場合、コードの展開を進める意味がないため、これはコードが展開ステージに移行する準備ができているかどうかを確認するのに適したポイントです。
ワークフロー
次の図は、ソフトウェア開発プロジェクトで継続的インテグレーションワークフロー全体がどのように機能するかの簡単なワークフローを示しています。 これについては、以降の章で詳しく説明します。
したがって、上記のワークフローに基づいて、これは一般に継続的インテグレーションプロセスの仕組みです。
- 最初に、開発者がコードをバージョン管理リポジトリにコミットします。 その間、統合ビルドマシン上のContinuous Integrationサーバーは、ソースコードリポジトリを変更のためにポーリングします（数分ごとなど）。
- コミットが発生するとすぐに、Continuous Integrationサーバーはバージョン管理リポジトリで変更が発生したことを検出するため、Continuous Integrationサーバーはリポジトリからコードの最新コピーを取得し、ソフトウェアを統合するビルドスクリプトを実行します
- Continuous Integrationサーバーは、指定されたプロジェクトメンバーにビルド結果を電子メールで送信することにより、フィードバックを生成します。
- そのプロジェクトのビルドに合格すると、単体テストが実行されます。 テストが成功すると、コードをステージングサーバーまたは運用サーバーに展開する準備が整います。
- 継続的インテグレーションサーバーはバージョン管理リポジトリの変更をポーリングし続け、プロセス全体が繰り返されます。
