開発部門のロールアウトプランプロセス
このページについて
このページでは、開発部門内のロールアウトプランの要件、成功基準、および手順について説明します。
ロールアウトプランとは何か、なぜ必要なのか？
ロールアウトプランとは、変更を本番環境に正常に適用し、期待通りに動作させるための方法の説明です。
ロールアウトプランを作成するプロセスは、多くの場合プラン自体よりも価値があります。なぜなら、成功を達成するために何をすべきかを考えることに時間を投資するからです。これにより、本番環境に移行する前に対処できる実装または観測可能性の問題が明らかになる場合があります。その時点では変更が容易であることが多いです。
これらのプランを持つことが有用なのは、初回でロールアウトを成功させることで、手戻りや機能が期待通りに動作しないリスクを軽減できるためです。
ロールアウトプランの作成
ロールアウトプランは、必要なプロジェクトやIssueごとに異なります。
最低限、ロールアウトプランには以下が含まれている必要があります:
- 期待される結果の詳細。
- その結果を検証する方法についての情報。
- ロールアウトに影響する可能性のあるリスクや障壁の考慮。
- ロールアウトが失敗した場合のロールバックプランの定義。
ロールアウトプランに含めることを検討すべき事項:
- 期待値
- ロールアウトプランが完了した時に期待される成果を定義する。どのように機能すべきか？ユーザーには何が表示されるか？システムはどのような詳細やメトリクスを提供すべきか？
- ロールアウトが失敗した場合に何が起こるかを文書化して、_予期しない_成果に備える。何を見れば分かるか？これらの予期しない成果のリスクをどのように軽減できるか？
- 問題が発生した場合の対応手順を文書化する。これには特定のSlackチャンネルでSREチームと連携したり、フィーチャーフラグを無効化したりするなど複数のタスクが含まれる場合があります。完全なロールバックプランになる場合もあります。
- 観察するメトリクス
- 期待値が満たされているかどうかを理解するために監視できるデータへのリンクを提供する。データはSentry、Sitespeed、Grafana、Kibana、または私たちの他の監視ツールなどのツールからの事前定義済み検索に基づく場合があります。
- テストシナリオ
- ロールアウト中にロールアウトが期待通りに機能していることを確認するための手動テストを定義する。
- 必要な自動化テストが通過していることを確認するためにカウンターパートと連携する。
- プロダクトへの広範な影響を持つ変更については、テストケースを収集するために関連するプロダクトグループと連携する。
- キャッシュされたデータや以前有効な状態のデータなど、ロールアウト中のデータの異なる状態を考慮する。
- マルチバージョン互換性/後方互換性のサポートを確認するためのチェックリストを含める。
- コミュニケーション
- 他のステージグループ、部門などの関連ステークホルダーを含むコミュニケーションプランや、変更をユーザーに伝えるためのサポートとの連携を含める。
- ロールアウト失敗のシグナルを伝達するまたは探す場所をロールアウトプランに記載する（#productionSlackチャンネルや新しいIssueリストなど）。
- ステージングおよび本番環境のチェック
- 変更がステージングおよび本番環境でリリースされた際に行う必要がある特定のチェックを含める。
- セルフマネージドインスタンスに特別に必要なチェックを含める。これは、リリース前にリファレンスアーキテクチャで変更をテストすることを含む場合があります。
- ロールアウトプロセス自体
- ロールアウトの準備として何をしなければならないかを説明する
- 従うべき具体的な手順を含める
- 観察するメトリクスとそれをいつ観察すべきかを含める（たとえば、一部の機能は変更が成功したかどうかを判断する前に1日分のメトリクス観察が必要）
- ロールアウト後のレトロスペクティブ
- 次のロールアウトが容易になるよう、ステージ/グループの共通プラクティスを更新する
- ロールアウトを振り返り、チームに学びを共有する
- ロールアウトをより安全で効率的にするためにその一部を自動化するIssue/MRを開くことを検討する。マネージャーにこの作業をエンジニアリングアロケーションの一部にするよう推薦する。
追加のロールアウトプランプロセス
注意すべき追加のロールアウトプランプロセス:
ロールアウトプランテンプレート
上記のシナリオ向けにこれらのテンプレートが存在しますが、ロールアウトプランのベースとしても使用できます:
