継続的インテグレーションを使用するための推奨事項

この Azure Well-Architected Framework のオペレーショナル エクセレンス チェックリストの推奨事項に適用されます。

OE:04 開発とテストに関する業界で実証済みのプラクティスに従って、ソフトウェア開発と品質保証プロセスを最適化します。 明確なロール指定を行う場合は、ツール、ソース管理、アプリケーション設計パターン、ドキュメント、スタイル ガイドなどのコンポーネント全体でプラクティスを標準化します。

関連ガイド: ビルド速度の | 向上 ツールとプロセスの標準化

コードを開発、更新、または削除する際に、これらの変更をメインコード ブランチに統合するための直感的で安全な方法を使用すると、開発者は価値を提供できます。

開発者は、小さなコード変更を行い、これらの変更をコード リポジトリにプッシュし、品質、テスト カバレッジ、導入されたバグに関するほぼ瞬時のフィードバックを得ることができます。 このプロセスを使用すると、より速く、より自信を持って、より少ないリスクで作業することができます。

継続的インテグレーション (CI) は、ソフトウェア開発チームが、自動化されたビルド、テスト、およびフィードバック メカニズムを利用できるようにするために、ソース管理システムとソフトウェア デプロイ パイプラインを統合する手法です。

主要な設計戦略

継続的インテグレーションは、開発者がソフトウェア更新プログラムを定期的にソース管理システムに統合するために使用するソフトウェア開発プラクティスです。

継続的インテグレーション プロセスは、コード変更を統合する準備ができていることを CI システムに通知する GitHub 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 に表示されます。

GitHub リポジトリの Azure DevOps 状態バッジのスクリーンショット。

テスト統合

継続的インテグレーションの重要な要素は、開発者がコードをコントリビューションする際のコードの継続的な構築とテストです。 作成された 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 ポータルに表示されるテスト結果を示しています。

Azure DevOps ポータルでの Azure DevOps パイプライン テストのスクリーンショット。

失敗したテスト

失敗したテストでは、デプロイを一時的にブロックし、発生した内容をより深く分析する必要があります。 失敗したテストは、テストの絞り込み、またはテストの失敗の原因となった変更の改善にもつながります。

CI 結果バッジ

多くの開発者は、リポジトリにステータス バッジを表示することで、コードの品質が高くなっていることを示しています。 次の図は、GitHub のオープンソース プロジェクトの readme ファイルに表示される Azure Pipelines バッジを示しています。

GitHub の readme ファイルの Azure Pipelines バッジのスクリーンショット。

Azure ファシリテーション

Azure DevOps は、コラボレーション、効率的、および一貫性のある開発プラクティスを構築するのに役立つサービスのコレクションです。

Azure Pipelines には、 アプリケーションの継続的インテグレーションと継続的デリバリー (CI/CD) をサポートするビルドおよびリリース サービスが用意されています。

Azure 用 GitHub for Actions を使用すると、CI/CD プロセスを自動化できます。 デプロイを簡略化するために、Azure と直接統合されます。 リポジトリ内のすべての pull request をビルドしてテストするワークフロー、またはマージされたプル要求を運用環境にデプロイするワークフローを作成できます。

GitHub または Azure DevOps を使用して継続的インテグレーション パイプラインを作成する方法について説明します。

リポジトリにバッジを表示する方法について説明します。

オペレーショナル エクセレンス チェックリスト