パイプラインを設計する

このユニットでは、Tailspin Web チームに従って 、Space Game Web サイトのリリース パイプラインを定義します。

リリース パイプラインを計画するときは、通常、そのパイプラインの ステージ (主要な部門) を特定することから始めます。 通常、各ステージは環境にマップされます。 たとえば、前のモジュールでは、Andy と Mara の基本的なパイプラインに、Azure App Service インスタンスにマップされた デプロイ ステージがありました。

このモジュールでは、あるステージから次のステージに変更を 昇格 させます。 各ステージ内で、Space Game Web サイトをそのステージに関連付けられている環境にデプロイします。

必要なステージを定義したら、あるステージから次のステージに変更を昇格させる方法を検討します。 各ステージでは、ビルドを次のステージに移行する前に満たす必要がある成功条件を定義できます。 Azure Pipelines には、変更がパイプライン内を移動する方法とタイミングを制御するのに役立ついくつかの方法が用意されています。 全体として、これらのアプローチは リリース管理に使用されます。

このセクションでは、次の操作を行います。

会議

Tailspin Web チーム全体が集まります。 Azure Pipelines でのリリース パイプラインの作成で、チームは現在のスプリントのタスクを計画しました。 各タスクは、 Space Game Web サイトのリリース パイプラインの構築に関連します。

チームはスプリントのために次の 5 つのタスクを決定したことを思い出してください。

• マルチステージ パイプラインを作成する
• Web アプリをデータベースに接続する
• 品質テストを自動化する
• パフォーマンス テストを自動化する
• リリース周期を改善する

チームは、最初のタスクである マルチステージ パイプラインの作成について話し合います。 チームがパイプラインを定義したら、基本的な概念実証から、より多くのステージ、品質チェック、承認を含むリリース パイプラインに移行できます。

Amita と Tim は、Andy と Mara が 2 回目のリリース パイプラインのデモンストレーションを見ています。 アーティファクトがビルドされ、App Service にインストールされていることがわかります。

どのようなパイプライン ステージが必要ですか?

リリース パイプラインを実装する場合は、まず、必要なステージを特定することが重要です。 選択するステージは、要件によって異なります。 チームがステージを決めるのに従いましょう。

ティム： さて、私は自動化されたパイプラインのアイデアを理解しています。 Azure に簡単にデプロイする方法が好きです。 しかし、このデモからどこに行くのですか? リリースに実際に使用できるものが必要です。

Amita: そうだね！ 他のステージを追加する必要があります。 たとえば、現在、テスト ステージの場所はありません。

ティム： さらに、新しい機能を管理に表示できるステージが必要です。 管理の承認がないと、運用環境に何も送信できません。

アンディ： そうですよ！ リリース パイプラインの機能の速度が上がったので、このパイプラインで必要な処理を行うにはどうすればよいでしょうか。

マラ： 次の手順の計画に役立つ要件を説明しましょう。 私たちが持っているものから始めましょう。

Mara はホワイトボードに移動し、既存のパイプラインをスケッチします。

マラ：ビルド ステージでは、ソース コードがビルドされ、パッケージが生成されます。 この場合、そのパッケージは .zip ファイルです。 デプロイ ステージでは、.zip ファイル ( Space Game Web サイト) が App Service インスタンスにインストールされます。 リリース パイプラインに何が足りないのですか?

開発ステージを追加する

アンディ： 偏っているかもしれませんが、 開発 段階が必要だと思います。 成果物がビルドされた後、このステージは最初のチェックポイントとなります。 開発者は、ローカル開発環境からサービス全体を常に実行できるわけではありません。 たとえば、eコマース システムでは、Web サイト、製品データベース、支払いシステムが必要な場合があります。 アプリが必要とするすべてのものを含むステージが必要です。

ここでは、 Space Game Web サイトのランキング機能が外部ソースからハイ スコアを読み取ります。 現時点では、ファイルから架空のスコアを読み取ります。 開発ステージを設定すると、Web アプリを実際のデータベースと統合できる環境が提供されます。 そのデータベースはまだ架空のスコアを保持している可能性がありますが、最終的なアプリに一歩近づくことになります。

マラ： それが好きです。 実際のデータベースとの統合はまだ行いません。 ただし、 開発 ステージでは、データベースを追加できる環境にデプロイできます。

Mara はホワイトボード上の図面を更新します。 "デプロイ" を "開発" に置き換えて、"開発" ステージを示します。

アンディ： あなたは興味深い点を持ち出します。 GitHub に変更をプッシュするたびにアプリをビルドします。 これは、各ビルドが完了後に 開発 ステージに昇格されることを意味しますか?

マラ： ビルドを継続的に行うと、ビルドとテストの正常性に関する重要なフィードバックが得られます。 ただし、コードを一部の中央ブランチ (メインまたは他のリリース ブランチ) にマージする場合にのみ、 Dev ステージに昇格させる必要があります。 その要件を示すために図面を更新します。

マラ： このプロモーションは、簡単に実現できるだろうなと思います。 リリース ブランチで変更が発生した場合にのみ、Dev ステージに昇格する条件を定義できます。

条件とは

Azure Pipelines では、 条件を使用して 、パイプラインの状態に基づいてタスクまたはジョブを実行します。 前のモジュールで条件を操作しました。

指定できる条件の一部を次に示します。

基本的な例を次に示します。

steps:
  - script: echo Hello!
    condition: always()

always()条件により、前のタスクが失敗した場合でも、このタスクは "Hello!" を無条件で出力します。

この条件は、条件を指定しない場合に使用されます。

condition: succeeded()

succeeded()組み込み関数は、前のタスクが成功したかどうかを確認します。 前のタスクが失敗した場合、同じ条件を使用するこのタスク以降のタスクはスキップされます。

ここでは、次を指定する条件を作成します。

• 前のタスクは成功しました。
• 現在の Git ブランチの名前は リリースです。

この条件を構築するには、組み込みの and() 関数を使用します。 この関数は、各条件が true かどうかを確認します。 いずれかの条件が true でない場合、全体的な条件は失敗します。

現在の分岐の名前を取得するには、組み込みの Build.SourceBranchName 変数を使用します。 条件内の変数には、いくつかの方法でアクセスできます。 ここでは、 variables[] 構文を使用します。

変数の値をテストするには、組み込みの eq() 関数を使用できます。 この関数は、引数が等しいかどうかを確認します。

これを考慮して、この条件を適用し、現在のブランチ名が "release" の場合にのみ Devステージを実行します。

condition: |
  and
  (
    succeeded(),
    eq(variables['Build.SourceBranchName'], 'release')
  )

and()関数の最初の条件は、前のタスクが成功したかどうかを確認します。 2 番目の条件は、現在のブランチ名が release と等しいかどうかを確認します。

YAML では、パイプ (|) 構文を使用して、複数行にまたがる文字列を定義します。 条件は 1 行で定義できますが、読みやすくするためにこの方法で記述します。

次のユニットでは、 開発 ステージを設定するときに、より完全な例を使用します。

Azure Pipelines の条件の詳細については、 式のドキュメントを参照してください。

マラ： 条件を使用すると、どの変更がどのステージに昇格するかを制御できます。 ビルドを検証し、正常であることを確認するために、任意の変更に対してビルド成果物を生成できます。 準備ができたら、それらの変更をリリース ブランチにマージし、そのビルドを 開発 ステージに昇格させることができます。

テスト ステージを追加する

マラ： ここまでは、 ビルド と 開発 のステージがあります。 次の予定は何ですか?

Amita: 次に テスト ステージを追加できますか? それは私が最新の変更をテストするのに適した場所のように思えます。

Mara は、ホワイトボード上の図面に テスト ステージを追加します。

Amita: 私が持っている懸念事項の1つは、アプリをテストする必要がある頻度です。 Mara または Andy が変更を行うたびに、メールで通知されます。 変化は一日中起こり、私はいつ飛び込むか分からない。 1 日に 1 回、おそらく出勤したときにビルドを見られるといいと思います。 私たちはそれを行うことができますか?

アンディ： もちろん。 勤務時間外に テスト にデプロイしないのはなぜですか? たとえば、毎日午前 3 時にビルドを送ることにしたらどうでしょう。

マラ： それは良いですね。 必要に応じて、いつでも手動でプロセスをトリガーできます。 たとえば、重要なバグ修正をすぐに確認する必要がある場合にトリガーできます。

Mara は図面を更新して、ビルドが 開発 ステージから毎日午前 3 時に テスト ステージに移動することを示します。

トリガーとは

Amita: 1つのステージが別のステージにどのように動くかがわかって、気分が良くなりました。 しかし、ステージを実行するタイミングを制御するにはどうすればよいでしょうか。

マラ： Azure Pipelines では、トリガーを使用できます。 トリガーは、ステージが実行されるタイミングを定義 します 。 Azure Pipelines には、いくつかの種類のトリガーが用意されています。 ここでは、次の選択肢を選択します。

• 継続的インテグレーション (CI) トリガー
• Pull request (PR) トリガー
• スケジュールされたトリガー
• ビルド完了トリガー

CI トリガーと PR トリガーを使用すると、プロセス全体に参加するブランチを制御できます。 たとえば、任意のブランチで変更が行われたときにプロジェクトをビルドします。 スケジュールされたトリガーは、特定の時刻にデプロイを開始します。 ビルド完了トリガーは、依存コンポーネントのビルドなど、別のビルドが正常に完了したときにビルドを実行します。 スケジュールされたトリガーが必要なようです。

スケジュールされたトリガーとは何ですか？

スケジュールされたトリガーでは、cron 構文を使用して、定義されたスケジュールでビルドが実行されます。

Unix および Linux システムでは、cron は、設定された時間間隔または特定の時刻にジョブを実行するようにスケジュールする一般的な方法です。 Azure Pipelines では、スケジュールされたトリガーは cron 構文を使用して、ステージの実行時を定義します。

cron 式には、特定の時刻パラメーターに一致するフィールドが含まれます。 フィールドは次のとおりです。

mm HH DD MM DW
 \  \  \  \  \__ Days of week
  \  \  \  \____ Months
   \  \  \______ Days
    \  \________ Hours
     \__________ Minutes

たとえば、次の cron 式は "毎日午前 3 時" を表します。 0 3 * * *

cron 式には、値のリストまたは値の範囲を指定する特殊文字を含めることができます。 この例では、アスタリスク (*) は、[ 日]、[ 月]、[ 曜日 ] フィールドのすべての値と一致します。

別の言い方をすると、この cron 式は次のように読み取ります。

• 分 0 で、
• 3 時間目に、
• 月の任意の日に、
• どの月にも、
• 週のどの日でも
• ジョブの実行

月曜日から金曜日の日にのみ午前 3 時を指定するには、次の式を使用します。 0 3 * * 1-5

Azure Pipelines でスケジュールされたトリガーを設定するには、YAML ファイルに schedules セクションが必要です。 次に例を示します。

schedules:
- cron: '0 3 * * *'
  displayName: 'Deploy every day at 3 A.M.'
  branches:
    include:
    - release
  always: false

この schedules セクションでは、次の操作を行います。

• cron は cron 式を指定します。
• branches は、 release ブランチからのみデプロイすることを指定します。
• alwaysは、デプロイを無条件で実行するか (true)、最後の実行 (release) 以降にfalseブランチが変更された場合にのみ実行するかを指定します。 ここでは、false ブランチが前回の実行以降に変更された場合にのみデプロイする必要があるため、releaseを指定します。

Azure Pipelines がスケジュールされたトリガーを実行すると、パイプライン全体が実行されます。 また、GitHub に変更をプッシュする場合など、他の条件下でもパイプラインが実行されます。 スケジュールされたトリガーに応答してのみステージを実行するには、ビルドの理由がスケジュールされた実行であるかどうかを確認する条件を使用できます。

次に例を示します。

- stage: 'Test'
  displayName: 'Deploy to the Test environment'
  condition: and(succeeded(), eq(variables['Build.Reason'], 'Schedule'))

このステージ Test、前のステージが成功し、組み込みの Build.Reason パイプライン変数が Scheduleと等しい場合にのみ実行されます。

このモジュールの後半で、より完全な例が表示されます。

Amita: 私はこれが好きです。 手動でリリースを取得してインストールする必要もありません。 準備は整っています。

アンディ： さらに後で自動化したい場合は、できることを覚えておいてください。 石には何も書いていません。 パイプラインは、改善と学習に伴って進化します。

ステージング ステージを追加する

ティム： 私の番です。 より多くのストレス テストを実行するためのステージが必要です。 また、承認を得るために管理にデモを行うことができるステージも必要です。 現時点では、これら 2 つのニーズを ステージングと呼ぶステージに組み合わせることができます。

アンディ： よく言った, Tim. ステージング環境または実稼働前環境を使用することが重要です。 多くの場合、このステージング環境は、機能またはバグ修正がユーザーに届く前の最後の停止です。

Mara はホワイトボード上の描画に ステージング を追加します。

Amita: スケジュールされたトリガーを使用して、 Dev ステージから テスト ステージに変更を昇格します。 しかし、 テスト から ステージングに変更を昇格するにはどうすればよいですか? そのプロモーションもスケジュールに従って行う必要がありますか?

マラ： これを処理する最善の方法は 、リリースの承認だと思います。 リリースの承認により、変更をあるステージから次のステージに手動で昇格させることができます。

Amita: それはまさに私が必要としているように聞こえます! リリースの承認により、ビルドを管理に提示する前に、最新の変更をテストする時間が与えられるでしょう。 準備ができたらビルドを公開できます。

Mara は図面を更新して、Amita が承認したときにのみビルドが テスト から ステージング に移行することを示します。

ティム： また、リリース承認を使用して、管理のサインオフ後に ステージング から 運用環境 に昇格することも想像できます。 私はどれくらいの時間がかかるかを予測することはできません。 サインオフされた後に、リリースを承認して、運用環境に手動で昇格させることができます。 しかし、リリース承認はどのように機能しますか?

リリース承認とは何ですか？

リリース承認は、承認者がリリースを承認または拒否するまでパイプラインを一時停止する方法です。 リリース ワークフローを定義するには、承認、条件、トリガーを組み合わせることができます。

Azure Pipelines でのリリース パイプラインの作成で、デプロイ環境を表す環境をパイプライン構成で定義したことを思い出してください。 既存のパイプラインの例を次に示します。

- stage: 'Deploy'
  displayName: 'Deploy the web application'
  dependsOn: Build
  jobs:
  - deployment: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: dev
    variables:
    - group: Release

環境には、リリースの特定の条件を含めることができます。 この条件では、その環境にデプロイできるパイプラインと、あるステージから次のステージにリリースを昇格するために必要な人間の承認を指定できます。

このモジュールの後半では、 ステージング 環境を定義し、自分を承認者として割り当てて、 Space Game Web アプリを テスト ステージから ステージングに昇格させます。

必要に応じて、最小限から最大限まで自動化する

Azure Pipelines では、自動化の準備ができていないステージを手動で制御しながら、一部のステージを自動化する柔軟性が得られます。

ティム： 私は、ある段階から次のステージへの変更を促進する基準を定義する方法が好きです。 しかし、パイプラインで手動の条件をいくつか定義しました。 DevOps は、すべてを自動化する作業だと思っていました。

マラ： あなたの言うことには一理あります。 DevOps は、反復的でエラーが発生しやすいタスクを自動化することです。 人間の介入が必要な場合があります。 たとえば、新機能をリリースする前に、管理から承認を受けます。 自動化されたデプロイの経験が増えるにつれて、プロセスを高速化するために手動の手順をさらに自動化できます。 たとえば、 テスト ステージでより多くの品質チェックを自動化できるため、Amita は各ビルドを承認する必要はありません。

ティム： いいですね。 ここでは、この計画に進み、後でシステムを高速化する方法を見てみましょう。

Amita: 私たちの計画について言えば、次のステップを要約できますか?

計画

Tailspin チームの計画を確認し、次のステップに進みましょう。

マラ： こちらが私たちが構築したいリリース パイプラインです。

Mara がホワイトボードを指し示します。

マラ： 要約すると、手順は次のとおりです。

1. GitHub に変更をプッシュするたびにビルド成果物を生成します。 この手順は 、ビルド ステージで行われます。
2. ビルド 成果物を Dev ステージに昇格させます。 この手順は、ビルド ステージが成功し、変更がリリース ブランチにあるときに自動的に行われます。
3. 毎朝午前 3 時にビルド成果物を テスト ステージに昇格させます。スケジュールされたトリガーを使用して、ビルド成果物を自動的に昇格します。
4. Amita がビルドをテストして承認した後、ビルド成果物を ステージング に昇格します。 リリースの承認を使用して、ビルド成果物を昇格させます。

管理がビルドを承認したら、ビルド成果物を運用環境にデプロイできます。

Amita: これは難しいでしょうか? それは多くの仕事のように思えます。

マラ： 私はそれがあまりにも悪いと思わない。 すべてのステージは、他のすべてのステージから分離されます。 ステージは別々になっています。 各ステージには、独自の一連のタスクがあります。 たとえば、 テスト ステージで何が起こるかは 、テスト ステージにとどまります。

パイプライン内のすべてのデプロイ ステージにも独自の環境があります。 たとえば、 アプリを開発 または テストにデプロイする場合、環境は App Service インスタンスです。

最後に、一度にテストするリリースは 1 つだけです。 パイプラインの途中でリリースを変更することはありません。 開発ステージではステージング ステージと同じリリースを使用し、すべてのリリースには独自のバージョン番号があります。 いずれかの段階でリリースが中断された場合は、修正し、新しいバージョン番号でもう一度ビルドします。 その新しいリリースは、最初からパイプラインを通過します。

品質に関するいくつかの単語

あなたは今、チームがアプリのビルドからステージングまでの全過程をカバーするパイプラインを設計したところを見ました。 このパイプラインの要点は、生活を容易にすることだけではありません。 顧客に提供するソフトウェアの品質を確保するためです。

リリース プロセスの品質を測定する方法 直接測定することはできません。 測定できる内容は、プロセスがどれだけうまく機能するかです。 プロセスを絶えず変更している場合は、何か問題があることを示している可能性があります。 パイプライン内の特定の時点で一貫して失敗するリリースは、リリース プロセスに問題があることを示している可能性もあります。

リリースは常に特定の日または時刻に失敗しますか? 特定の環境にデプロイした後、常に失敗しますか? リリース プロセスの一部の側面が依存または関連しているかどうかを確認するには、これらのパターンとその他のパターンを探します。

リリース プロセスの品質を追跡する良い方法は、リリースの品質の視覚化を作成することです。 たとえば、すべてのリリースの状態を示すダッシュボード ウィジェットを追加します。

リリース自体の品質を測定する場合は、パイプライン内であらゆる種類のチェックを実行できます。 たとえば、パイプラインの実行中にロード テストや UI テストなど、さまざまな種類のテストを実行できます。

品質ゲートを使用することは、リリースの品質を確認するための優れた方法でもあります。 さまざまな品質ゲートがあります。 たとえば、作業項目ゲートでは、要件プロセスの品質を確認できます。

セキュリティとコンプライアンスのチェックをさらに追加することもできます。 たとえば、複数人による確認に準拠しているか、適切な追跡可能性があるかどうかです。

このラーニング パスを進めるにつれて、これらの手法の多くが実際に行われていることがわかります。

最後に、品質リリース プロセスを設計するときは、ユーザーに提供する必要があるドキュメントやリリース ノートの種類について考えます。 ドキュメントを最新の状態に保つのは難しい場合があります。 HTTP によってトリガーされる関数を含む関数アプリである Azure DevOps リリース ノート ジェネレーターなどのツールの使用を検討することをお勧めします。 Azure Blob Storage を使用すると、Azure DevOps で新しいリリースが作成されるたびに Markdown ファイルが作成されます。