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