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

  • 7 分

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

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

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

Diagram that shows a pipeline with a stage containing one job. The job contains four steps.

パイプラインでステージを使用すると、関心の分離をマークできます。 たとえば、Bicep コードを操作するとき、コードの "検証" は Bicep ファイルの "デプロイ" とは別の関心です。 自動化されたパイプラインを使用する場合、コードのビルドとテストは、多くの場合、継続的インテグレーション (CI) と呼ばれます。 自動化されたパイプラインにコードをデプロイすることは、多くの場合、継続的デプロイ (CD) と呼ばれます。

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

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

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

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

シフト レフト

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

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

Chart with a timeline on the horizontal axis, cost on the vertical axis, and a line showing that the cost increases the later an error is identified.

ソフトウェア開発の鉄則としては、プロセスのできるだけ早い段階で (タイムラインの左側に近いほど) エラーを特定できれば、簡単、迅速、かつ安価にエラーを修正できることが知られています。 プロセスでのエラーの特定が遅くなるほど、修正が困難になります。

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

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

重要

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

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

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

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

Diagram that shows a pipeline with a Validate stage, a Deploy U S stage, and a Deploy Europe stage, running in sequence.

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

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

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  jobs: 
  - job: DeployEurope

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

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

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

Diagram that shows a pipeline with a Validate stage, a Deploy U S stage, and a Deploy Europe stage, with the two deployment stages running in parallel.

ステージ間の依存関係を指定するには、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 で複数のステージのすべての依存関係が満たされていることが検出された場合は、それらのステージを並列で実行できます。

Note

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

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

Diagram that shows a pipeline with a Deploy stage, and a condition so that a failure in the Deploy stage results in the Rollback stage running.

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 デプロイ パイプラインの一般的なステージを以下に示します。

Diagram that shows a Bicep deployment pipeline with five stages: Lint, Validate, Preview, Deploy, and Smoke Test.

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

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

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

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