コードを開発、更新、または削除する際に、これらの変更をメイン コード ブランチに統合するための直感的で安全な方法を使用することで、開発者は価値を提供できます。
開発者は、小規模なコード変更を行い、その変更をコード リポジトリにプッシュし、品質、テスト カバレッジ、混入バグに関するフィードバックをほぼ瞬時に得ることができます。 このプロセスにより、より高い信頼度と少ないリスクで速い作業が実現します。
継続的インテグレーション (CI) は、ソース管理システムとソフトウェアデプロイ パイプラインを統合して、ソフトウェア開発チームに自動ビルド、テスト、フィードバックメカニズムを提供するプラクティスです。
継続的統合プロセスは、エンジニアが GitHub pull request を作成して、コード変更を統合する準備ができていることを CI システムに通知するときに開始されます。 理想的には、統合プロセスでは、コードを複数のベースラインとテストに対して検証します。 次に、これらのテストのステータスに関するフィードバックを要求元のエンジニアに提供します。
ベースライン チェックとテストが適切に行われると、統合プロセスによって、更新されたソフトウェアをデプロイする資産が生成され、ステージングされます。 これらの資産には、コンパイルされたコードとコンテナー イメージが含まれます。
継続的インテグレーションでは、次のアクションを実行することで、高品質のソフトウェアをより迅速に提供できます。
- コードに対して自動テストを実行して、破壊的変更を早期に検出します。
- コード分析を実行して、コードの標準、品質、構成を確認します。
- コンプライアンスとセキュリティチェックを実行して、ソフトウェアに既知の脆弱性がないことを確認します。
- 受け入れテストまたは機能テストを実行して、ソフトウェアが期待どおりに動作することを確認します。
- 検出された問題について迅速なフィードバックを提供します。
- 該当する場合は、更新されたコードを含む展開可能なアセットまたはパッケージを作成します。
用語
継続的インテグレーションの実装を開始する前に、これらの重要な用語を理解しておいてください。
| 任期 | 定義 |
|---|---|
| アーティファクト | コンパイル済みのコード、コンテナー イメージ、デプロイ パッケージなど、ビルド プロセスからのデプロイ可能な出力。 |
| 自動テスト | コードの品質を検証し、手動による介入なしで問題を検出するために、CI パイプラインの一部として自動的に実行されるテスト。 |
| ビルド | ソース コードをコンパイルし、テストを実行し、デプロイ用の成果物を生成するプロセス。 |
| ビルド エージェント | CI パイプライン内でタスクと操作を実行するセルフホステッドまたはクラウドでホストされたコンピューティング リソース。 |
| 継続的インテグレーション (CI) | ソース管理システムと自動化されたパイプラインを統合して、コードの変更を自動的にビルド、テスト、検証するプラクティス。 |
| CI パイプライン | 開発者がソース管理にコミットしたときにコードの変更をビルド、テスト、検証する自動化されたワークフロー。 |
| 統合テスト | さまざまなコンポーネントまたはサービスがどのように連携するかを検証するテスト。多くの場合、単体テストよりも包括的です。 |
| 夜間ビルド | 統合テストや UI テストなど、実行時間の長いテスト スイートを実行するために一定の間隔 (通常は夜間) で実行されるスケジュールされたビルド。 |
| プルリクエスト | あるブランチのコード変更を別のブランチにマージするリクエスト。 CI パイプラインをトリガーして、統合前に提案された変更を検証します。 |
| リリース構築 | コンパイル、テスト、ドキュメント、コンプライアンス レポート、署名を含む包括的なビルド。 本番環境へのデプロイ用の最終版を作成します。 |
| ソース管理 | 時間の経過に伴うコードの変更を追跡および管理するシステム。 たとえば、Git、Azure Repos、GitHub などがあります。 |
| 状態を示すバッジ | ビルドまたはテストの現在の状態を表示する視覚インジケーター（通常は画像）が、リポジトリのドキュメントに頻繁に示されます。 |
| テスト駆動開発 (TDD) | 開発者がそれらのテストを満たすコードを記述する前にテストを記述する開発プラクティス。 |
| 単体テスト | 個々の関数またはコンポーネントを個別に検証して、期待どおりに動作することを確認するテスト。 |
パイプラインを使用して継続的インテグレーションを自動化する
継続的インテグレーションを実現するには、ソフトウェア ソリューションを使用してプロセスを管理、統合、自動化します。 一般的な方法は、継続的インテグレーション パイプラインを使用することです。
継続的インテグレーション パイプラインには、次を提供するソフトウェア (多くの場合、クラウドでホストされる) が含まれます。
- 自動テストを実行するためのプラットフォーム。
- コンプライアンス スキャン。
- レポート作成。
- 継続的インテグレーション プロセスを構成する他のすべてのコンポーネント。
ほとんどの場合、パイプライン ソフトウェアはソース管理にアタッチされるため、プル要求が作成されたり、ソフトウェアが特定のブランチにマージされたりすると、継続的インテグレーション パイプラインが実行されます。 ソース管理統合により、pull request 関する CI フィードバックを直接提供する機会も提供されます。
Azure Pipelines や GitHub Actions などの多くのソリューションは、継続的統合パイプラインの機能を提供します。
パイプラインをソース管理と統合する
継続的統合パイプラインとソース管理システムの統合は、迅速なセルフサービス コード コントリビューションを実現する鍵となります。
CI パイプラインは、新しく作成された pull request で実行されます。 パイプラインには、すべてのテスト、セキュリティ評価、その他のチェックが含まれます。 CI テストの結果は pull request に直接表示されるため、品質に関するフィードバックをほぼリアルタイムで得ることができます。
もう 1 つの一般的なプラクティスは、現在のビルド状態を表示するためにソース管理に表示できる小さなレポートまたはバッジを作成することです。
次の図は、GitHub と Azure DevOps パイプラインの統合を示しています。 この例では、プル要求の作成によって Azure DevOps パイプラインがトリガーされます。 パイプラインの状態が pull request に表示されます。
自動テストを組み込む
継続的インテグレーションの重要な要素は、開発者がコード コントリビューションする際の、コードの継続的な構築とテストです。 作成された pull request をテストすると、コミットによって破壊的変更が導入されていないというフィードバックが迅速に得られます。 利点は、継続的インテグレーション パイプライン内のテストが、テスト駆動開発中に実行されるテストと同じでよいことです。
次のコード スニペットは、Azure DevOps パイプラインからのテスト 手順を示しています。 この手順には、次の 2 つのタスクがあります。
- 最初のタスクでは、一般的な Python テスト フレームワークを使用して CI テストを実行します。 これらのテストは、Python コードと共にソース管理に存在します。 テスト結果は、test-results.xmlという名前のファイルに移動 します 。
- 2 番目のタスクは、テスト結果を使用し、統合レポートとして Azure DevOps パイプラインに発行します。
- script: |
pip3 install pytest
pytest azure-vote/azure-vote/tests/ --junitxml=junit/test-results.xml
continueOnError: true
- task: PublishTestResults@2
displayName: 'Publish Test Results'
inputs:
testResultsFormat: 'JUnit'
testResultsFiles: '**/test-results.xml'
failTaskOnFailedTests: true
testRunTitle: 'Python $(python.version)'
次の図は、Azure DevOps ポータルに表示されるテスト結果を示しています。
失敗したテスト
テストが失敗すると、展開が一時的にブロックされ、発生した内容が詳細に分析されます。 テストの失敗は、テストの改良や、テストの失敗の原因となった変更の改善につなげる必要があります。
ビルド状態を公開する
多くの開発者は、リポジトリにステータス バッジを表示することで、コードの品質が高い点を示しています。 次の図は、GitHub のオープンソース プロジェクトの readme ファイルに表示される Azure Pipelines バッジを示しています。
ビルド時間の最適化
より高速なビルドを実行するには、次の操作を行います。
パフォーマンス要件を満たすエージェントを選択する: 適切なビルド マシンを選択してビルドを高速化します。 高速マシンは、時間と分の違いを生み出すことができます。 パイプラインが Azure Pipelines にある場合は、Microsoft がホストするエージェントを使用してジョブを実行できます。 Microsoft がホストするエージェントを使用すると、メンテナンスとアップグレードが自動的に行われます。 詳細については、Microsoft ホステッド エージェントに関するページを参照してください。
ビルド サーバーの場所を最適化する: コードをビルドすると、ネットワーク経由でデータが送信されます。 ビルドへの入力は、ソース管理リポジトリと成果物リポジトリからフェッチされます。 コンパイル済みの成果物、テスト レポート、コード カバレッジの結果、デバッグ シンボルなど、ビルド プロセスからの出力をコピーする必要があります。 これらのコピー アクションを迅速に実行することが重要です。 独自のビルド サーバーを使用する場合は、ビルド サーバーがソースとターゲットの場所の近くに配置されていることを確認します。 高速アップロードとダウンロードにより、全体的なビルド時間を短縮できます。
ビルド サーバーのスケールアウト: 小規模な製品には、1 つのビルド サーバーで十分な場合があります。 製品のサイズとスコープ、および製品に取り組むチームの数が増えるにつれて、1 台のサーバーでは不十分な場合があります。 上限に達したら、インフラストラクチャを複数のマシンに対して水平方向にスケーリングします。 詳細については、「 エージェント プールの作成と管理」を参照してください。
ビルドを最適化します。
並列ジョブを追加して、ビルド プロセスを高速化します。 詳しくは、「並列ジョブの設定と支払いについて」をご覧ください。
並列テスト スイートの実行を有効にします。これは、多くの場合、特に統合テストと UI テストを実行する場合に、大量の時間を節約します。 詳細については、「 テスト ランナーに対してテストを並列で実行する」を参照してください。
乗数の概念を使用して、複数のビルド エージェントに対してビルドをスケールアウトできます。 詳細については、「パイプラインでジョブを指定する」を参照してください。
統合、UI、スモーク テストをリリース パイプラインに移動することを検討してください。 リリース パイプラインに移動すると、ビルド速度とビルド フィードバック ループの速度が向上します。
NuGet や Maven などのパッケージ管理ソリューションにビルド成果物を発行します。 パッケージ管理ソリューションに発行すると、ビルド成果物をより簡単に再利用できます。
ワークフローに合わせてビルドの種類を実装する
組織では、ビルド時間を最適化するために、いくつかの異なる種類のビルドを作成することを選択する場合があります。 考えられるビルドは次のとおりです。
継続的インテグレーション (CI) ビルド: このビルドの目的は、コードがコンパイルされ、単体テストが実行されるようにすることです。 このビルドは、コミットごとにトリガーされます。 プロジェクトのハートビートとして機能し、チームに質の高いフィードバックをすぐに提供します。 詳細については、「パイプラインをトリガーするイベントの指定」を参照してください。
夜間ビルド: 夜間ビルドの目的は、コードをコンパイルするだけでなく、ビルドごとに通常の周期で非効率的に実行される大規模なテスト スイートを保証することです。 通常、これらのテストには、統合、UI、またはスモーク テストが含まれます。 詳細については、「 パイプラインのスケジュールを構成する」を参照してください。
リリース ビルド: このビルドでは、コンパイルとテスト実行に加えて、API ドキュメントやコンプライアンス レポート、コード署名などが必要とされるケースがある、コードのビルドにおいて常に必要ではないその他の手順も含まれます。 このビルドは、最終的に運用環境にデプロイするためにリリース パイプラインにプッシュされるゴールデン コピーを提供します。
組織に必要なビルドの種類は、チームと組織の成熟度、作業中の製品の種類、デプロイ戦略などの要因によって異なります。
関連リンク
GitHub または Azure DevOps を使用して継続的インテグレーション パイプラインを作成する方法について説明します。
リポジトリにバッジを表示する方法について説明します。