まとめ
お疲れさまでした。 パイプラインが形になりつつあります。 あなたと Tailspin チームは、基本的な概念実証から現実的なリリース パイプラインに移行しました。 このパイプラインを使用して成果物をビルドし、ユーザーに提供する前にテストすることができます。
このモジュールでは、変更をパイプラインのあるステージから次のステージに移行する方法を制御する方法を学習しました。 このモジュールで作成したパイプラインを確認してみましょう。 この画像には、パイプライン全体の形状が示されています。
"開発"、"テスト"、"ステージング" の各ステージでは、独自の Azure App Service 環境にビルド成果物がそれぞれデプロイされます。
- 変更が GitHub にプッシュされると、"トリガー" によって "ビルド" ステージが実行されます。 "ビルド" ステージでは、出力としてビルド成果物が生成されます。
- "開発" ステージは、"リリース" ブランチで変更が行われた場合にのみ実行されます。 この要件を指定するには、"条件" を使用します。
- "テスト" ステージは毎朝午前 3 時に実行されます。 このステージは、最後の実行以降に行われた変更が "リリース" ブランチに含まれている場合にのみ実行されます。 "テスト" ステージを実行するタイミングを指定するには、"スケジュールされたトリガー" を使用します。
- "ステージング" ステージは、"テスト" ステージで変更が承認された後にのみ実行されます。 変更が承認または拒否されるまでパイプラインを一時停止するには、"リリースの承認" をステージング環境に追加します。
このパイプラインでは、Tailspin チームの要件が満たされています。 実際のパイプラインの形状と、変更がどのように流れるかは、チームのニーズと、作成するアプリとサービスによって異なります。
チームは、リリースの周期を向上させていますが、さらに改良する余地はあります。 たとえば、QA 担当の Amita は、チームが新しい機能を管理に提示する前に、手動でビルドをテストおよび承認する必要があります。 次のモジュールでは、Tailspin チームと一緒に、さらに多くのテストを自動化し、変更をより迅速にパイプラインに移行することができるようにします。
詳細情報
このモジュールでは、条件、トリガー、承認を使用しました。 詳細については、次のリソースを参照してください。