Microsoft には、高度にスケーラブルなサービスを運用環境に提供する数十年の経験があります。 Microsoft のサービスと環境が拡大するにつれて、その配信プラクティスも時間の経過と同時に進化しています。 多くの Microsoft のお客様も、これらの効率的な配信プラクティスを採用し、メリットを得られています。 次の主要な DevOps の原則とプロセスは、最新のソフトウェア配信作業に適用できます。
DevOps 配信プロセスを実装するために、Microsoft は次のイニシアチブを採用しました。
- 組織の意識とリズムを成果物の提供に集中させる。
- 機能を所有、テスト、提供する自律的で説明責任のあるチームを形成します。
- 運用環境のシステムをテストおよび監視する権利をシフトします。
配信に重点を置く
迅速な発送は、組織やチームが簡単に測定して評価できる明らかな利点です。 一般的な DevOps 周期には、運用への通常のデプロイを伴う短い スプリント サイクルが含まれます。
短いスプリントで製品の安定性が不足することを恐れて、一部のチームはスプリントサイクルの終了時に安定化期間を補っていました。 エンジニアはスプリント中にできるだけ多くの機能を出荷したいと考えていたため、安定時に支払わなければならなかったテスト負債が発生しました。 スプリント中に負債を管理したチームは、借金を組み立てたチームをサポートする必要がありました。 追加コストは、配信パイプラインを通じてプロダクション環境に浸透しました。
安定期間を取り除くことで、チームが債務を管理する方法がすぐに改善されました。 重要なメンテナンス作業を安定化期間に押し上げる代わりに、債務を蓄積したチームは、次のスプリントを債務目標に追いつくために費やさなければならなかった。 Teams は、スプリント中にテスト負債を管理する方法をすぐに学習しました。 機能は、実績があり、デプロイのコストに見合った価値があるときに提供されます。
パイプラインを完全に自動化する
多くの改善チームは、コードリポジトリから本番環境へのパイプラインを完全に自動化することで、即座に大きな改善を得ることができます。 自動化には、 継続的インテグレーション (CI)、自動テスト、 継続的デリバリー (CD) を含むリリース パイプラインが含まれます。
チームは展開が難しいのでデプロイを回避する可能性がありますが、展開の頻度が低いほど、展開が困難になります。 デプロイの間隔が長いほど、問題が増えます。 コードが最新でない場合は、デプロイの負債があります。
頻繁にデプロイすることで、より小さなチャンクで作業する方が簡単です。 この考えは後見では明白に思えるかもしれませんが、当時は直感に反しているように見えるかもしれません。 また、頻繁なデプロイでは、より効率的で信頼性の高いデプロイ ツールとパイプラインの作成に優先順位を付ける動機付けもチームに与えられます。
社内ツールを使用する
Microsoft は、構築したリリース管理システムを使用し、お客様に出荷します。 1 回の投資により、チームの生産性と Microsoft 製品の両方が向上します。 セカンダリシステムを使用すると、開発と配信の速度が低下します。
チームの自律性とアカウンタビリティ
特定の主要な進行状況インジケーター (KPI) は、チームの生産性やパフォーマンス、または機能が順調に進んでいるかどうかを測定しません。チームは、組織の目標に合わせる方法を見つけながら、独自の計画とバックログを管理できる必要があります。
進行状況を追跡するには、チームと直接やり取りすることが重要です。 ツールはコミュニケーションを容易にする必要がありますが、会話は最も透過的なコミュニケーション方法です。
機能に優先順位を付ける
重要な目標は、機能の提供に集中することです。 スケジュールでは、特定の期間にチームと個人が合理的に完了できる量を評価できますが、一部の機能は早期に提供され、一部は後で提供されます。 Teams は、最も重要な機能が運用環境に届くように、作業の優先順位を付けることができます。
マイクロサービスを使用する
マイクロサービスは、配信を 向上させ、簡素化するさまざまな技術的な利点を提供します。 マイクロサービスは、チームの所有権にも自然な境界を提供します。 チームがマイクロサービスへの投資に対して自律性を持っている場合、機能を実装して負債を管理する方法に優先順位を付けることができます。 Teams は、マイクロサービスに依存するサービス全体に関係なく、バージョン管理などの要因の計画に集中できます。
メインで作業する
エンジニアは、以前は別々のブランチで働いていました。 各ブランチのマージ負債は、エンジニアがブランチをメイン ブランチに統合しようとするまで増加しました。 チームやエンジニアが多いほど、統合が大きくなりました。
統合をより速く、継続的に、より小さなチャンクで行うために、エンジニアはメイン ブランチで作業するようになりました。 Git に移行する大きな理由の 1 つは、軽量ブランチ Git オファーです。 内部エンジニアリングの利点は、深いブランチ階層とその無駄を排除することでした。 以前は統合に費やされたすべての時間が、配信に注ぎ込まれるようになりました。
機能フラグの使用
一部の機能はスプリントデプロイでは完全には完了していませんが、運用環境でのテストの恩恵を受けることができます。 Teams は、開発チームや早期導入者の小さなセグメントなど、特定のユーザーの機能を有効にする機能 フラグ を使用して、このコードをマージして展開できます。 機能フラグは、ユーザー ベース全体の問題を危険にさらすことなく露出を制御し、チームが機能を完了するかどうかとその方法を決定するのに役立ちます。
運用環境でのテスト
運用環境でテストする権限をシフトすることで 、実稼働前テストが有効であること、および絶えず変化する運用環境でデプロイを処理する準備が整っていることを確認できます。
計測機器のテストと指標
アプリがデプロイされる場所に関係なく、すべてをインストルメント化することが重要です。 インストルメンテーションは、問題の特定と修正に役立つだけでなく、使用状況と次に追加する内容に関する貴重な調査を提供できます。
回復性パターンをテストする
複雑なデプロイのリスクは連鎖故障であり、1つのコンポーネントの故障が依存するコンポーネントの故障を引き起こし、最終的にシステム全体が崩壊するというものです。 単一障害点 (SPOF) がどこにあり、どのように軽減されるかを理解し、特に運用環境で軽減プロセスをテストすることが重要です。
適切なメトリックを選択する
メトリックの設計は困難な場合があります。 一般的な間違いは、何も見つからないのを避けるために、含めるメトリックが多すぎる場合です。 ただし、これは、特定のニーズを満たしていないメトリックの値を無視したり、信頼を誤ったりする可能性があります。 代わりに、Microsoft チームは、成功を測定するために必要なデータを判断するのに時間がかかります。 Teams はメトリックを追加または変更する場合がありますが、最初から目的を理解すると、そのプロセスが容易になります。
チームは、メトリックの基礎に加えて、測定に必要なメトリックを考慮します。 たとえば、ユーザーの獲得速度や高速化は、ユーザーの合計数よりも有用なメトリックである可能性があります。 メトリックはプロジェクトによって異なりますが、最も役に立つのは、ビジネス上の意思決定を推進する可能性があるメトリックです。
メトリックを使用して作業をガイドする
Microsoft には、最高のリーダーシップ レベルでのレビューを含むメトリックが含まれています。 6 週間ごとに、組織は、正常性、ビジネス、シナリオ、および顧客テレメトリに関してどのように行っているかを提示します。 組織は、経営陣やチームとメトリックについて話し合います。
組織の各チームは、エンゲージメントのあるユーザーメトリクスを調べて、機能に対する意味を判断します。 Teams は機能を出荷するだけでなく、ユーザーが機能を使用しているかどうかを確認します。 チームはこれらのメトリックを使用してバックログを調整し、機能が目標を達成するためにより多くの作業を必要とするかどうかを判断します。
配信ガイドライン
- A から B まで直線になることも、B も終わりではありません。
- 常に後退と間違いがあります。
- プロセスの特定の部分を完了するための戦術を変更する学習機会として、後退を表示します。
- 時間が経つにつれて、すべてのチームは、変化するニーズに合わせてエクスペリエンスを構築し、調整することで、DevOps プラクティスを進化させます。
- 重要なのは、エンド ユーザーと配信プロセス自体の両方に価値を提供することに焦点を当てることです。