継続的インテグレーションの使用に関する推奨事項
Azure Well-Architected フレームワークのオペレーショナル エクセレンスに関するチェックリストの次の推奨事項を対象とします。
| OE:04 | 業界で認められている開発とテストのプラクティスに従って、ソフトウェア開発と品質保証のプロセスを最適化します。 役割を明確に指定するため、ツール、ソース管理、アプリケーション設計パターン、ドキュメント、スタイル ガイドなどのコンポーネントの間でプラクティスを標準化します。 |
|---|
関連ガイド: ビルド速度を向上させる | ツールとプロセスを標準化する
コードを開発、更新、あるいは削除する際に、これらの変更をメイン コード ブランチに統合するための直感的で安全な方法を採用することで、開発者は価値を提供できます。
開発者は、コードを少し変更し、これらの変更をコード リポジトリにプッシュして、品質、テスト カバレッジ、発生したバグに関するフィードバックをほぼ瞬時に得ることができます。 このプロセスにより、いっそう速く確実に作業を行い、リスクを軽減できます。
継続的インテグレーション (CI) は、ソフトウェア開発チームが、自動化されたビルド、テスト、およびフィードバック メカニズムを利用できるようにするために、ソース管理システムとソフトウェア デプロイ パイプラインを統合する手法です。
主要な設計戦略
継続的インテグレーションは、開発者がソフトウェアの更新をソース管理システムに定期的に統合するために使うソフトウェア開発手法です。
継続的インテグレーション プロセスは、コードの変更を統合する準備ができたことを CI システムに通知する GitHub pull request をエンジニアが作成した時点で始まります。 複数のベースラインとテストに対するコードの検証が統合プロセスによって行われるのが理想的です。 その後、これらのテストの状態に関するフィードバックが要求元のエンジニアに提供されます。
ベースライン チェックとテストで問題がない場合は、統合プロセスによって、更新されたソフトウェアをデプロイするアセットが生成されてステージングされます。 これらのアセットには、コンパイル済みのコードとコンテナー イメージが含まれます。
継続的インテグレーションを使うと、次のアクションが実行されるので、高品質のソフトウェアをより迅速に提供するのに役立ちます。
- コードに対して自動テストを実行して、破壊的変更を早期に検出する。
- コード分析を実行して、コードの標準、品質、および構成を確認する。
- コンプライアンスとセキュリティのチェックを実行して、ソフトウェアに既知の脆弱性がないことを確認する。
- 受け入れテストまたは機能テストを実行して、ソフトウェアが想定どおりに動作することを確認する。
- 検出された問題に関するフィードバックを迅速に提供する。
- 必要に応じて、更新されたコードを含むデプロイ可能なアセットまたはパッケージを生成する。
パイプラインを使って継続的インテグレーションを自動化する
継続的インテグレーションを実現するために、ソフトウェア ソリューションを使用して、プロセスを管理、統合、および自動化します。 一般的な手法は、継続的インテグレーション パイプラインを使うことです。
継続的インテグレーション パイプラインには、次のものを提供する (多くの場合、クラウドでホストされた) ソフトウェアが含まれます。
- 自動テストを実行するためのプラットフォーム。
- コンプライアンス スキャン。
- レポート作成。
- 継続的インテグレーション プロセスを構成する他のすべてのコンポーネント。
ほとんどの場合、パイプライン ソフトウェアは、pull request が作成されたりソフトウェアが特定のブランチにマージされたりして、継続的インテグレーション パイプラインが実行されると、ソース管理にアタッチされます。 また、ソース管理の統合により、pull request に対するフィードバックを CI に直接提供することもできるようになります。
Azure Pipelines や GitHub Actions などの多くのソリューションで、継続的インテグレーション パイプラインの機能が提供されています。
パイプラインとソース管理を統合する
継続的インテグレーション パイプラインとソース管理システムの統合は、高速のセルフサービス コード コントリビューションを実現するために重要です。
CI パイプラインは、新しく作成された pull request に対して実行されます。 パイプラインには、すべてのテスト、セキュリティ評価、その他のチェックが含まれます。 CI のテスト結果は pull request に直接表示され、品質に関するフィードバックがほぼリアルタイムでわかります。
もう 1 つの一般的な手法は、現在のビルドの状態がわかるようにソース管理で提供できる、小さなレポートまたはバッジを作成することです。
次の図は、GitHub と Azure DevOps パイプラインの統合を示しています。 この例では、pull request を作成すると Azure DevOps パイプラインがトリガーされます。 パイプラインの状態が pull request に表示されます。
自動テストを組み込む
継続的インテグレーションの重要な要素は、開発者がコードのコントリビューションを行ったときのコードの継続的なビルドとテストです。 pull request を作成するとそのテストが行われ、コミットによって破壊的変更が発生していないことを示すフィードバックが直ちに提供されます。 この利点は、継続的インテグレーション パイプラインでのテストを、テスト駆動開発中に実行されるテストと同じにできることです。
次のコード スニペットは、Azure DevOps パイプラインのテスト ステップを示しています。 このステップには 2 つのタスクがあります。
- 1 つ目のタスクでは、一般的な 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 ファシリテーション
Azure DevOps は共同作業に適した、効率的で一貫性のある開発プラクティスを構築するのに役立つサービスのコレクションです。
Azure Pipelines には、アプリケーションの継続的インテグレーションと継続的デリバリー (CI/CD) をサポートするビルドとリリースのサービスが用意されています。
GitHub Actions for Azure は、CI/CD プロセスを自動化できるようにします。 デプロイを簡略化するために、Azure と直接統合されます。 リポジトリ内のすべての pull request を作成してテストする、またはマージされた pull request を運用環境にデプロイするワークフローを作成できます。
関連リンク
GitHub または Azure DevOps を使って継続的インテグレーション パイプラインを作成する方法を理解します。
リポジトリにバッジを表示する方法を理解します。