まとめ

  • 3 分

このモジュールでは、新しいアプリケーション機能をユーザーにスムーズにロールアウトする自動化された方法としての "デプロイ パターン" を定義しました。 適切なデプロイ パターンは、ダウンタイムを最小限に抑える助けとなる可能性があります。 これを使用すると、ユーザーに新機能を段階的にロールアウトできるようにもなります。

複数のデプロイ パターンからの選択が可能です。 選択するデプロイ パターンは、デプロイの理由や実際のリソースによって異なります。 カナリア テストの担当者は設けていますか。 非通知起動を使用して、自分がテスト担当者であると知らないテスト担当者を選びますか。 小集団から大集団へと段階的に増加する、信頼できるテスターの集団がいる場合は、段階的公開デプロイを選択できます。 または、1 つのバージョンが別のバージョンよりも優れているかどうかを知りたい場合は、A/B テストを選択できます。

Tailspin チームは、Azure App Service のデプロイ スロットを使用して、ブルーグリーン デプロイ パターンを実装することを選択しました。 "デプロイ スロット" は、独自のホスト名を持つライブ アプリです。 チームは、2 つのデプロイ スロットをスワップできます。 スワップすることで、変更を運用環境に瞬時に昇格させることができます。 チームは Web サイトを一般向けにリリースする準備がまだできていませんが、ダウンタイムを発生させることなくユーザーに新機能を届けられることを実証してきました。

おまけに、このモジュールでは、Git のコミットを元に戻してから、元に戻した変更をパイプラインを通してプッシュすることによって、意図しない変更をロールフォワードする方法も学習しました。

チームはどのような評価を下していますか?

「既存のソフトウェア開発プロセスを評価する」モジュールでは、Mara が バリューストリーム マッピングの演習を行いました。 この演習は、チームが現在のリリース サイクル プロセスを分析する助けになりました。

"アクティビティ レシオ" (効率性) は、"処理時間" を "合計リード タイム" で割ったものであることを思い出してください。

$$ {Activity \ ratio\ = \} \dfrac{Process\ {time} Total\ lead\ {time}} $$

Tailspin の Web チームは当初、このメトリックを使用して、チームの効率性は 23% であると判断しました。

チームはまず、継続的インテグレーション (CI) を実装したときに一定の非効率性を低減しました。 彼らは、継続的デリバリー (CD) を適用することで、非効率性をさらに低減することになりました。

以前のラーニング パスでは、チームは以下を削減しました。

  • 新機能のソース管理の設定にかかる時間。 必要な時間は "3 日" から "0 日" になりました。

    チームは、一元的なソース管理から、分散ソース管理の一種である Git に移行することによって、この改善を実現しました。 分散ソース管理を利用すると、ファイルのロックが解除されるまで待つ必要がありません。

  • テスト担当者の Amita にコードを引き渡すのにかかる時間。 必要な時間は "2 日" から "0 日" になりました。

    チームは、ビルド プロセスを Azure Pipelines に移行することによって、この改善を実現しました。 Azure Pipelines では、ビルドが使用可能になると Amita に自動的に通知が行われます。 開発者は、Amita に通知するため、彼女のスプレッドシートを更新する必要がなくなりました。

  • Amita が新機能をテストのにかかる時間。 必要な時間は "3 日" から "1 日" になりました。

    チームは、コードの単体テストによってこの改善を実現しました。 彼らは、変更がビルド パイプラインを通過するたびに単体テストを実行するので、Amita に報告されるバグや回帰が減少しています。 ワークロードが減少するということは、Amita がそれぞれの手動テストをより迅速に完了できることを意味します。

このラーニング パスであなたとチームが構築したリリース パイプラインによって、以下が削減されました。

  • ビルドを "テスト" ステージにするのにかかる時間。 必要な時間は "3 日" から "1 日" になりました。

    チームは、毎日午前 3 時に テスト へのデプロイを行うようスケジュールされたトリガーを使用して、これを実現しました。

  • テストしたビルドを "ステージング" にするのにかかる時間。 必要な時間は "2 日" から "0 日" になりました。

    チームは、機能テストの 1 つの形式である Selenium UI テストを "テスト" ステージに追加することで、この改善を実現しました。 これらの自動テストは、手動のバージョンよりもはるかに高速です。

  • 承認されたビルドを "ステージング" からライブにするのにかかる時間。 必要な時間は "1 日" から "1 日未満" になりました。

    チームは、パイプラインに手動の承認チェックを追加することで、この改善を実現しました。 管理者がサインオフすると、Tim は変更を "ステージング" からライブにリリースできます。

これらの変更により、合計リード タイムが 22 日から 10 日に短縮されます。 これらの数値を式に代入すると以下のようになります。

$${Activity\ ratio\ =\ }{\dfrac{5\ days}{10\ days}}{ = 0.50}$$

結果を 100% で乗算すると、50% の削減率が求められます。

常に改善の余地はありますが、この変化はチームにとっての勝利です。 顧客がより早く価値を得るようになっただけでなく、Tailspin のチームでは、待ち時間が短縮された分、チームにとって一番楽しいこと、つまり、顧客が気に入るとわかっている機能を提供することに、より多くの時間を割けるようになりました。

詳細情報

以下の追加リソースを使用して、App Service、デプロイ スロット、変更のロールバックに関する詳細を確認してください。