テストの自動化とデリバリー パイプライン

ソフトウェアとサービスの継続的デプロイとデリバリーについて学んできましたが、この 2 つは実際には 3 つの要素のうちの一部です。 DevOps プラクティスは、継続的 インテグレーション、配信、デプロイを実現することを目的としています。 これらのプラクティスは、通常、その順序で構築され、それぞれがその前のプラクティスに応じて構築されます。

ここで、前に戻り、これらの最初の要素である統合について説明します。 これは、デプロイ前の開発プロセスの一部です。 DevOps では、チーム メンバーが単一の "メイン" または "トランク" コードベースを含む共有リポジトリにコードを頻繁に統合する開発プラクティスが推奨されています。 目標は、出荷されるコードに全員が貢献することであり、自分のコピーに対して作業を行い、最終段階ですべてを 1 つにまとめることではありません。

自動テストでは、各チーム メンバーの統合を確認できます。 このテストは、変更や追加が行われるたびにコードが "健全" であることを判断するのに役立ちます。 テストは、一般的に パイプラインと呼ばれるものの一部です。 このユニットの残りの部分では、統合されたテストと配信パイプラインに重点を置いています。

継続的デリバリー パイプライン

継続的デリバリー デプロイ モデルにおける自動テストの役割を理解するには、それがデリバリー パイプラインのどこに適合するかを調べる必要があります。 継続的デリバリー パイプラインとは、運用環境にデプロイされる前に、開発プロセスの中で変更が加えられたときにコードが通過する一連のステップを実装したものです。 次に示すのは、簡略化されたデリバリー パイプライン内のサンプル ステップの図です。

このパイプラインの手順を順を追って説明します。

• パイプラインのインスタンスは、コードまたはインフラストラクチャの変更が、(おそらくpull request を使用して) コード リポジトリにコミットされたときに開始されます。

• 次に、単体テストが実行され、多くの場合、統合テストまたはエンド ツー エンド テストが実行されます。 結果は、pull request を開いた開発者に通知されます。

• この段階では、リポジトリ内のコードでシークレット、脆弱性、構成ミスがスキャンされることがよくあります。

• すべてのチェックアウトが完了すると、コードがビルドされ、デプロイの準備が行われます。

• 次に、コードはテスト環境にデプロイされます。 レビュー担当者は、運用前ソリューションを調べることができるように、新しいデプロイの通知を受け取ることができます。 その後、レビュー担当者は運用環境への昇格を承認または拒否します。これにより、コードを運用環境にリリースするデプロイ プロセスの最後の部分が開始されます。

このパイプラインでは、統合とデプロイの概要がわかります。 強調表示されたマーカーは、含まれているロジックと自動化、または人間の介入を通じてパイプラインを停止できるいくつかの論理的な場所を示しています。

継続的インテグレーションと継続的デリバリーのためのツール: Azure PipelinesとGitHub Actions

継続的インテグレーションと継続的デリバリーを使用するには、適切なツールが必要です。 Microsoftには、Azureにビルドしてデプロイするための 2 つのファースト パーティ CI/CD オプション (Azure Pipelines (Azure DevOpsの一部) と GitHub Actions が用意されています。 どちらもコードの構築と一貫したテストを自動化でき、両方ともクラウドとオンプレミスのAzure サービス、仮想マシン、その他のターゲットにデプロイできます。 多くのチームは、ソース コードが既にGitHubに存在する場合にGitHub Actionsを採用しますが、Azure PipelinesはAzure DevOpsで標準化されたチームにとって依然として強力な選択肢です。

このユニットの残りの部分では、Azure Pipelinesに焦点を当てていますが、GitHub Actionsでは用語が異なる場合でも同様の高レベルのアイデアを使用します。 GitHub Actionsでは、ワークフローにはジョブとステップが含まれており、アクション は再利用可能な自動化をパッケージ化し、ランナーは作業を実行し、環境はデプロイを保護できます。

パイプライン (コードまたは構成) への入力は、GitHubや別の Git プロバイダーなどのバージョン管理システムに存在します。

Azure Pipelines仮想マシンやコンテナーなどのコンピューティング上で実行され、Windows、Linux、macOS を実行するMicrosoftホストされたビルド エージェントが提供されます。 ビルド環境を完全に制御する必要がある場合は、独自のセルフホステッド エージェントを登録することもできます。 また、テスト、セキュリティ、およびコード品質プラグインとの統合も提供します。最後に、簡単に拡張できるため、独自の自動化をAzure Pipelinesに取り込むことができます。

パイプラインは、Git リポジトリ内のコードと共に格納された YAML 構文を使用して定義されます。 YAML パイプラインは、新しいプロジェクトに推奨されるアプローチです。 Azure DevOpsのクラシック ユーザー インターフェイスはレガシ パイプラインでも使用できますが、ほとんどの新機能 (コンテナー ジョブや多くの高度な機能を含む) は YAML 専用です。 パイプラインには、Docker イメージのテンプレートや Node.js プロジェクトなどのパイプラインを簡単に作成するために使用できるテンプレートも用意されています。 既存の YAML ファイルを再利用することもできます。

パイプラインを設定する基本的な手順は次のとおりです。

1. Git リポジトリを使用するようにAzure Pipelinesを構成します。
2. azure-pipelines.yml ファイルを編集してビルドを定義します (または、従来のパイプラインの場合はクラシック エディターを使用します)。
3. バージョン コントロール リポジトリにコードをプッシュします。 この操作により、パイプラインがトリガーされ、コードがビルドおよびテストされます。

コードが更新、ビルド、およびテストされたら、それを任意のターゲットにデプロイできます。

Azure パイプラインの構築

パイプラインは次のような構造になっています。

• ジョブ: ジョブは、1 つのビルド エージェントで実行されるタスクまたはステップのグループです。 ジョブは、実行をスケジュールできる作業の最小コンポーネントです。 ジョブ内のすべてのステップが順番に実行されます。 これらの手順には、ソフトウェアのビルドやコンパイル、テスト用のサンプル データの準備、特定のテストの実行など、必要な任意のアクションを指定できます。

• ステージ: ステージは、関連するジョブの論理的なグループです。

各パイプラインには、少なくとも 1 つのステージがあります。 複数のステージを使用して、パイプラインを主要な区分に編成し、一時停止してチェックを実行できる、パイプライン内のポイントをマークします。

パイプラインは、必要に応じて単純にも複雑にもなります。 パイプラインの構築と使用に関するチュートリアルについては、Azure DevOps ラーニング パスを使用した Build アプリケーションを参照してください。

環境の追跡可能性

パイプラインには、信頼性に関連するもう 1 つの注目すべき側面があります。 運用環境で実行されているものと特定のビルド インスタンスを関連付けることができるように、パイプラインを構築できます。 理想的には、ビルドを特定のプル要求またはコード変更までトレースできる必要があります。 この追跡可能性は、インシデントの間、およびその後のインシデント後のレビュー中に、問題の原因となった変更を特定しようとするときに非常に重要です。 一部の CI/CD システム (Azure PipelinesやGitHub Actionsなど) ではこの相関関係が簡単になりますが、他の CI/CD システムでは、ビルド ID をすべてのステージに伝達するパイプラインを手動で構築する必要があります。