安全なデプロイ プラクティスを採用する
 デプロイ プロセスにガードレールを実装して、エラーや予期しない状態の影響を最小限に抑えてください。 |
|---|
開発サイクル中、ワークロードの成果物は、実装されテストされるときや、バグが修正されるときに、多くの変更が実行されます。
デプロイ プロセスは、標準の運用手順に従う必要があります。 すべての変更は同じレベルの厳密さでデプロイする必要があります。 この原則は、コード、構成、および関連するすべての成果物に同様に適用されます。 重要なのは、運用環境で予測可能になるように、できるだけ早く安全なプラクティスを適用することです。 エラーが顧客に届いた場合でも、復旧の変更をできるだけ早くロールアウトできる必要があります。
サンプル シナリオ
Contoso Air は、お客様がアプリを通じてフライトを直接予約できる Web アプリケーションを開発しました。 このアプリは 1 年以上にわたって運用環境で実行されています。
アプリは Azure に完全にデプロイされ、Azure App Service、Azure Cosmos DB、Azure Functions、Azure Logic Apps、Azure Service Bus の上に構築されています。
自動デプロイ標準を体系化する
パイプラインなどの自動デプロイ プロセスを使用して、変更をデプロイするプロセスを標準化します。 すべての環境でパイプラインを使用する必要があります。環境ごとに資産とバージョンを分類して、簡単に追跡および識別できるようにします。
一貫性のあるデプロイ方法では、プロセスのエラーと差異によって発生する問題が減り、ワークロードの問題に集中できます。
標準化により、デプロイが安全かつ確実に、再現性を備えた状態で完了することが保証されます。
分類により、以前のデプロイと以前に発生した問題のログを簡単に表示できます。 その情報を使用すると、ロールバック操作とロールフォワード操作を迅速に処理できる場合があります。
"Contoso の課題"
- Contoso Air のワークロード チームは、自動ビルドおよびデプロイ パイプラインを使用しますが、通常、デプロイでは、さまざまな構成設定を変更して検証するために、操作全体で手動で介入する必要があります。
- 手動介入により、デプロイに頻繁にエラーが発生するため、すべてのリリースがチーム全体にとって非常にストレスの多い破壊的なイベントになります。 また、手動介入により、デプロイが失敗したときにロールバックが困難になります。
"アプローチの適用と結果"
- チームは、デプロイの一環として構成の変更を自動化し、追加された機能を既存のデプロイ パイプラインに統合するための時間を割り当てます。
- 各環境に関連付けられている構成設定は、追跡可能性を高めるためにソース管理に保存される各 JSON ファイルに外部化されます。 シークレットと見なされる設定はシークレット コンテナー ストアに保存され、各環境にも割り当てられます。
- デプロイ中にすべての変更がログに記録され、トラブルシューティングの作業と監査に役立つ完全な追跡可能性が実現されます。 また、チームは、構成の変更を検証するための自動テストもパイプラインに追加します。
- 次に、チームはロールバックの完全な自動化に取り組んで、プロセスをさらに最適化します。
- 新しい自動化の結果、デプロイの信頼性と予測性が向上し、チームの士気も高くなっています。
頻繁にデプロイする
小さな増分更新を定期的にデプロイします。
このアプローチを使用すると、プロジェクト管理の観点からユーザー ストーリーと作業項目が管理しやすくなり、デプロイが失敗した場合の大規模な問題のリスクを軽減できます。
"Contoso の課題"
- チームのデプロイ プロセスでは、これまで 3 か月から 4 か月ごとにメジャー リリースを行ってきました。 このプラクティスでは、リリースの検証が困難になります。 また、チームは、非常に多くの可動部分に関する問題のトラブルシューティングも困難でした。
- 中間リリースの修正プログラムを必要とするか、またはロールバックして破棄する必要がある問題のあるリリースが、複数回行われました。
- リリースは非常にストレスが多く、"全員が総力を挙げて取り組む" 状況として扱われてきました。これは、チームの士気に悪影響を与えました。
"アプローチの適用と結果"
- 問題のある最新のリリースの後、関係者は、デプロイのより良いアプローチを考え出すようにチームに求めました。 チームは、頻繁で小規模な変更を優先するようにプラクティスを変更することにしました。 各リリースのスコープは、ビルドが下位環境全体で昇格されるときに十分にテストされる 1 つまたは (最大でも) 数個の関連する変更に制限されます。
- その結果、リリースの効率が大幅に上がり、品質が向上しました。 リリースの検証が容易になり、問題のトラブルシューティングが簡単になります。
- 予測可能なリリースを定期的に用意することは、チームの自信と士気を回復するのに役立ちました。 ユーザーにもメリットがあります。 リリースの品質が向上すると、中断が少なくなり、新機能にはるかに早くアクセスできるようになります。
段階的公開アプローチを使用する
デュー デリジェンスを使用して、更新を段階的にロールアウトします。 すべてのユーザーが更新プログラムを安全に導入するまで、インスタンスと顧客の数を段階的に増やす制御を実現できるデプロイ モデルを使用します。
運用環境の早い段階で問題が修正されるように、適切な方法で各更新をテストします。 顧客ベース全体に影響を与える不具合のある更新をロールアウトしないようにします。
更新に下位互換性と上位互換性があるかどうかテストします。
"Contoso の課題"
- チームは、アプローチを切り替えてリリースを小さくすることで大きなメリットが見られます。 リリースに費やす時間を短縮し、オペレーショナル エクセレンスの改善の道を進むための活力を感じています。
- 新しい機能を試すと、一部の変更がユーザーの評判が良くなかったり、急な学習曲線によりサポート コールを増やす原因となりました。
- 人気や使いやすさのない機能をリリースする影響を最小限に抑える一方で、ユーザーの生産性を最大化するためにアプリケーションを革新し続ける方法に疑問を感じています。
"アプローチの適用と結果"
- 機能フラグを使用して新しい機能をユーザーに段階的に公開する機能リリース モデルを実装することにしました。
- 新しい機能の計画段階で、最初に機能が公開される先のユーザーを選択する基準が定義されます。 新しい機能を最初に受け取るために、少数のユーザー グループが選択されます。 ユーザー フィードバックに応じて、ユーザー全体が新しいバージョンを実行するまで、この機能はより大きなグループに連続してデプロイされます。 新しい機能が公開されるユーザーが増えるにつれて、サポート チームは、外部 FAQ を内部で共有し、データを取り込むためにサポート ケースの結果を文書化しています。