パイプライン ステージについて

  • 7 分

パイプラインを使用すると、デプロイ プロセスの手順を自動化できます。 プロセスには、実行するジョブの論理グループがいくつか含まれる場合があります。 このユニットでは、パイプライン ステージと、それらを使用して Bicep デプロイに品質管理プロセスを追加する方法について説明します。

パイプライン ステージとは

"ステージ" は、パイプラインを複数の論理ブロックに分割するのに役立ちます。 各ステージには、1 つ以上のジョブを含めることができます。 ジョブには、コマンドライン スクリプトの実行など、完了する必要があるステップの順序付きリストが含まれています。

1 つのジョブを含むステージが含まれているパイプラインを示す図。ジョブには 4 つのステップが含まれています。

パイプラインのステージを使用して、責務の分離を明確にすることができます。 たとえば、Bicep コードを使用する場合、コードの検証は Bicep ファイルのデプロイとは別の問題です。 自動化されたパイプラインを使用する場合、コードのビルドとテストは、多くの場合、継続的インテグレーション (CI) と呼ばれます。 自動化されたパイプラインにコードをデプロイすることは、多くの場合、継続的デプロイ (CD) と呼ばれます。

CI ステージでは、コードに加えられた変更の有効性を確認します。 CI ステージでは、品質保証を提供します。 ライブ運用環境に影響を与えずに実行できます。

多くのプログラミング言語では、ユーザーがコードを実行するには、まずコードを "ビルド" する必要があります。 Bicep ファイルがデプロイされると、Bicep から JSON に変換 (トランスパイル) されます。 ツールでは、このプロセスが自動的に実行されます。 ほとんどの場合、パイプライン内の JSON テンプレートに対して Bicep コードを手動でビルドする必要はありません。 ただし、Bicep コードについて説明するときは、継続的インテグレーションという用語を引き続き使用します。コードの検証など、CI の他の部分は引き続き適用されるためです。

CI ステージが正常に実行されると、加えた変更も正常にデプロイされるという確信が高まるはずです。 CD ステージでは、各環境にコードをデプロイします。 通常は、テストやその他の非運用環境から始めて、運用環境に進みます。 このモジュールでは、1 つの環境にデプロイします。 今後のモジュールでは、非運用環境や運用環境など、複数の環境にデプロイするようにデプロイ パイプラインを拡張する方法について説明します。

ステージはシーケンスで実行されます。 各ステージの実行の方法とタイミングを制御できます。 たとえば、CI ステージが正常に実行された後にのみ実行されるように CD ステージを構成できます。 または、コードをビルドしてテストするために、複数の CI ステージを順番に実行する必要がある場合があります。 また、前のデプロイ ステージが失敗した場合にのみ実行される ロールバック ステージを含めることもできます。

シフト レフト

ステージを使用すると、デプロイする前にコードの品質を確認できます。 これらのステージの使用は 、左シフトと呼ばれることもあります。

コードを記述するときに実行するアクティビティのタイムラインを検討します。 タイムラインは、計画フェーズと設計フェーズから始まります。 その後、ビルドおよびテスト フェーズに移ります。 最後に、ソリューションをデプロイしてサポートします。 次の図は、タイムライン上のこれらのステージを示しています。

横軸がタイムライン、縦軸がコストを表すグラフ。グラフ線は、エラーの特定が遅くなるほど、コストが増加することを示しています。

これは、プロセスの早い段階でエラーが見つかるほど (タイムラインの左側に近いほど)、修正が容易で、高速で、安価である、ソフトウェア開発のよく理解されたルールです。 プロセスでのエラーの特定が遅くなるほど、修正が困難になります。

そのため、目標は、問題の検出を図の左側にシフトすることです。 このモジュール全体を通して、パイプラインの進行に従って、さらに検証とテストを追加する方法について説明します。

デプロイを開始する前に検証を追加することもできます。 Azure DevOps などのツールを使用する場合、"プル要求" は通常、チームの一員がメイン ブランチのコードに対して行う変更を表します。 プル要求のレビュー プロセス中に CI ステップを自動的に実行する別のパイプラインを作成すると便利です。 この手法は、提案された変更を行っても、コードが引き続き機能することを検証するのに役立ちます。 検証が成功した場合は、変更がメイン ブランチにマージされても問題が発生しないという確信が得られます。 チェックに失敗した場合、プルリクエストをマージする準備が整うまでに、さらなる作業が必要であることがわかります。

重要

自動検証およびテストは、作成したテストと同程度の効果があるにすぎません。 テストする必要のある項目を検討するとともに、デプロイが問題ないという確信を得るために実行する必要のあるステップを検討することが重要です。

パイプライン ステージを定義する

各パイプラインには、少なくとも 1 つのステージが含まれます。 パイプラインにステージが 1 つしかない場合は、明示的に定義する必要はありません。 Azure Pipelines では、それは自動的に定義されます。 パイプラインに複数のステージがある場合は、それぞれを定義する必要があります。 ステージは、指定したシーケンスで実行されます。

2 回 (米国のインフラストラクチャに 1 回、ヨーロッパのインフラストラクチャに 1 回) デプロイする必要がある Bicep ファイルを作成したとします。 ファイルをデプロイする前に、Bicep コードを検証します。 このプロセスを定義するマルチステージ パイプラインの図を次に示します。

Validate ステージ、Deploy US ステージ、Deploy Europe ステージを含むパイプラインを、その順序で示す図。

この例には 3 つのステージがあります。 Validate ステージは CI ステージに似ています。 DeployUS ステージと DeployEurope ステージは、次に実行されます。 それぞれのステージで、環境のいずれかにコードがデプロイされます。

パイプライン YAML ファイルでステージを定義する方法を次に示します。

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  jobs: 
  - job: DeployEurope

ステージのシーケンスを制御する

既定では、ステージは定義した順序で実行されます。 ステージは、前のステージが成功した場合にのみ実行されます。 ステージ間に依存関係を追加して、順序を変更できます。

上記の例の続きとして、次のように両方のデプロイを並列で実行するとします。

Validate ステージ、Deploy US ステージ、および Deploy Europe ステージを含むパイプラインを示す図。2 つのデプロイ ステージは並列で実行されます。

ステージ間の依存関係を指定するには、dependsOn キーワードを使用します。

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  dependsOn: Test
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  dependsOn: Test
  jobs: 
  - job: DeployEurope

dependsOn キーワードを使用すると、Azure Pipelines では、依存するステージが正常に終了するまで待機してから、次のステージが開始されます。 複数のステージのすべての依存関係が満たされていることが Azure Pipelines によって検出された場合は、それらのステージを並列で実行できます。

注

実際には、複数のジョブを同時に実行するのに十分なエージェントがある場合にのみ、ステージとジョブが並列で実行されます。 Microsoft によってホストされるエージェントを使用するとき、これを実現するために追加の "並列ジョブ" を購入することが必要な場合があります。

前のステージが失敗したときにステージを実行できます。 たとえば、次のような別のパイプラインがあるとします。 デプロイが失敗した場合、そのすぐ後にロールバックというステージが実行されます。

デプロイ ステージと、デプロイ ステージでエラーが発生してロールバック ステージが実行されるようにする条件を含むパイプラインを示す図。

condition キーワードを使用して、ステージが実行される前に満たされる必要がある条件を指定できます。

stages:

- stage: Test
  jobs:
  - job: Test

- stage: Deploy
  dependsOn: Test
  jobs: 
  - job: Deploy

- stage: Rollback
  condition: failed('Deploy')
  jobs: 
  - job: Rollback

前の例では、すべて問題がない場合、Azure Pipelines でまず検証ステージが実行されてから、デプロイ ステージが実行されます。 ロールバック ステージはスキップされます。 しかし、デプロイ ステージが失敗した場合は、Azure Pipelines でロールバック ステージが実行されます。 ロールバックについては、このモジュールで後ほどさらに学習します。

すべてのジョブは新しいエージェントで実行されます。 つまり、すべてのジョブはクリーンな環境から開始されるため、すべてのジョブでは通常、最初の手順としてソース コードをチェックアウトする必要があります。

Bicep デプロイ ステージ

一般的な Bicep デプロイ パイプラインには、いくつかのステージが含まれています。 パイプラインのステージが進むにつれて、後続のステージが成功するという確信が強まるようになることが目標です。 Bicep デプロイ パイプラインの一般的なステージを以下に示します。

リント、検証、プレビュー、デプロイ、スモーク テストという 5 つのステージを含む Bicep デプロイ パイプラインを示す図。

  1. リント: Bicep リンターを使用して、Bicep ファイルが整形式であり、明らかなエラーが含まれていないことを確認します。
  2. 検証: Azure Resource Manager のプレフライト検証プロセスを使用して、デプロイ中に発生する可能性のある問題を確認します。
  3. プレビュー: what-if コマンドを使用して、Azure 環境に対して適用される変更の一覧を検証します。 パイプラインを進める前に、What-If の結果を人によって手動で確認し、承認してください。
  4. デプロイ: デプロイを Resource Manager に送信して終了するまで待ちます。
  5. スモーク テスト:デプロイした重要なリソースの一部に対して基本的なデプロイ後チェックを実行します。 これらのレビューは、"インフラストラクチャ スモーク テスト" と呼ばれます。

組織のステージのシーケンスが異なる場合や、Bicep デプロイを、他のコンポーネントをデプロイするパイプラインに統合する必要がある場合があります。 ステージがどのように動作するのかを理解したら、ニーズに合わせてパイプラインを設計することができます。

このモジュール全体を通して、ここに記載されているステージについて詳しく学習し、各ステージを含むパイプラインを段階的にビルドします。 また、次のことも学習します。

  • 前のいずれかのステージで予期しないことが発生した場合にパイプラインでデプロイ プロセスを停止する方法。
  • 前のステージで何が起こったかを手動で確認するまで一時停止するようにパイプラインを構成する方法。