2020年のソフトウェア開発は、急速に環境が変化しています。 私たちの組織がこの政治的、経済的な不確実性の時代を生き抜こうとするならば、スピードと適応性をもって動く必要があることは、日に日に明らかになりつつあります。 しかし、スピードの中で安全を確保するためには、どのようにコントロールすればよいのでしょうか。 多くのガードレールと不定期なデプロイで構築されたソフトウェア デリバリ サイクルから、できるだけ迅速かつ安全に顧客に価値を提供するために頻繁なリリースによる応答性をサポートする、より近代的な手法に移行することが目標なら、変更管理の意思決定を誰に任せるかは非常に重要なポイントになります。 CAB自体は、企業のITの内外のさまざまな機能からの代表者の集まりで、提案された変更をレビューし、変更の評価、優先順位付け、およびスケジュール設定において変更マネージャを支援することを公約に掲げています。 設計上、このグループは提案された変更の設計や実装に直接関与しないため、彼らが行うプロセスが「外部」レビューと呼ばれる所以です。 スピードと安全性、およびビジネスインパクトを最適にサポートするためには、開発チームと顧客が意思決定を行うことが必要です。 技術的な観点からは、開発者はリリースに何が含まれているか、相互依存関係が存在するかどうか、テストされているかどうかについて、どんな変更諮問委員会よりも優れたアイデアを持っています。 ビジネスの観点からは、何がうまくいき、何がうまくいかないかを最終的に決定するのは顧客であり、一部のシニアマネージャーでもなければ、変更諮問委員会でもないことを理解するときが来たのです。
変更諮問委員会は遅いかもしれませんが、少なくとも安全ですよね？
変更諮問委員会 (および ITIL にあるものの多く) は、特に動きが遅く複雑な環境において、リスクを低減し厳密性を付加する妥当な方法のように思われるかもしれません。 30日や90日に一度しか生産工程を変更できないのであれば、品質ゲートとマネジメントの承認によってリリースから物事を遠ざけることは、リスクを管理する良い方法のように思われます。 開発者がコードを書いてから本番稼動するまでの時間が、数週間から数ヶ月長くなることは誰も議論しないでしょうが、その方が安全でしょう？
実は、そうではありません。 そうではありません。
さまざまな業界や環境での複数年にわたる調査により、CAB または同様の「外部承認」プロセスを持つことは、承認プロセスをまったく持たないことよりもパフォーマンスが悪いことが判明しました。 この結果について、筆頭著者である Nicole Fosgren 博士は次のように述べています。
外部承認は、リードタイム、展開頻度、および復元時間と負の相関があり、変更失敗率とは相関がないことがわかりました。 要するに、外部機関 (マネージャーまたは CAB など) による承認は、サービスを復元する時間および変更の失敗率によって測定される生産システムの安定性を高めるために、単純に機能しないのです。 しかし、物事を遅くすることは確かである。 実際、変更承認プロセスが全くないより悪いのです。
What’s Better than No Change Management at all?
Fosgren 博士と彼女のチームは、実際には承認プロセスを持たないことを提案しているわけではありませんが、CAB が現実の世界でどれほどひどいパフォーマンスであるかを考えると、どのようなプロセスが実際に安全を維持できるかを考え直さなければなりません。
これらの結果に基づく私たちの推奨は、ペア プログラミングやチーム内コード レビューなどのピア レビューに基づく軽量の変更承認プロセスを、悪い変更を検出して拒否するための展開パイプラインと組み合わせて使用することです。 このプロセスは、コード、インフラ、データベースの変更など、あらゆる種類の変更に使用できます。
Peer Code Reviews Combined with What Now?
2018年の3月にこの勧告を読んだとき、私は前半を問題なく視覚化できました。ピア コード レビューと毎週のチーム デモがすでに BlazeMeter では規範となっていたからです。 後半は？ そうでもないですよ！？ 私たちは “最新の “クラウドネイティブSaaSアプリでしたが、”デプロイメントパイプラインが悪い変更を検出して拒否する “というのは聞いたことがありませんでした。
当時、リリース時のリスクを管理するために、私たちはブルー/グリーン デプロイメントとカナリア リリースの組み合わせを使用しました。 プラットフォームは「プッシュ」はしますが、「検知」や「拒否」はしません。それは私たちの最も優秀な SRE が担当し、ユーザーが 100% になる前に何十ものものの健全性を手動でチェックしました。 “detect and reject bad changes “と書いても、ホワイトボードに書かれた “magic happens here “と書かれた黒い箱の絵しか出てきません。 9374>
Detect and Reject (検知と拒否)。
「探せばいくらでもある」
2年の間に、多くのことが変化します。 CD エバンジェリストとして Split に参加して以来、Lukas Vermeer が Booking.com のデプロイメント パイプラインで、悪い変更を 1 秒以内に検出して元に戻す方法について説明するのを見ました。 Walmart Labs の Sonali Sheel が、Expo プラットフォームを使用して、主要な測定基準に損害を与える前にロールアウトを途中で停止する方法 (彼らが Test to Launch と呼ぶもの) を説明するのを聞いています。 創設者たちは、AmazonやMicrosoftで同様のシステムの複雑さ、スピード、規模に取り組んだ人たちからアドバイスを受けました。
スプリットについて聞き、彼らが商品化している例を知ったとき、私は彼らの仲間になるチャンスに飛びつきました。 このようなプラットフォームを自社で構築することは、少数の巨人だけが取り組むことのできる時間とリソースを持っていることでした。 もし、SaaS として、同じような種類のきめ細かい公開と自動インパクト検出が可能であれば、インパクト主導のソフトウェア デリバリーは、ユニコーンの新興企業だけでなく、すべてのチームのために解放されることでしょう。 聴衆は、まず驚き、次に諦めの反応を示すのです。 「それはとてもクールなことですが、私たちは Booking.com や LinkedIn、Facebook ではありません。 私たちの環境では、そんなことはできません。”
Split の実装の詳細を避けて「ベンダー中立」であろうとした結果、「マジックはここで起こる」と記されたブラック ボックスの曖昧な絵を実質的に描き直していました。
What If It Wasn So Hard?
暴露のきめ細かい制御と、環境の悪い変更を検出して拒否するための厳格な自動メカニズムを提供するプラットフォームを見たことがなければ、それが SF だと思われても仕方がないでしょう。
ここで解決すべき主な問題は、次の 4 つであることが判明しました。 これは、真の継続的インテグレーション、小さなバッチ サイズ、漸進的な機能開発、および抽象化による分岐を促進し、これらはすべて、フローが標準である継続的デリバリを実行するために重要です。 これは、実稼働環境でのテスト、ドッグフーディング、早期アクセスプログラム、および変更を嫌う顧客のための変更のバッチ処理を促進します。 目標は、帰属プロセス (「誰が何を得たか」と「その後何が起こったか」の整合) を自動的かつ継続的に行うことです。
Decoupling deploy from release and selectively exposing new code is becoming known as progressive delivery, a termined by RedMonk analyst James Governor. 複数の商用フィーチャー フラッグ ベンダーがこれらの機能を提供しており、フィーチャー フラッグは、社内で構築して維持するよりも購入する方が理にかなっている開発者ツールのリストに加わっているというコンセンサスが生まれつつあります。
機能フラグは、フローを実現するための不可欠な基盤ですが、それ自体では影響の検出を高速化することはできません。 ほとんどの機能フラグの実装は、フローを容易にしますが、すべてがうまくいっているかどうか、または意味のある結果を達成しているかどうかを示すことはできません。
Head’s Up: Data Scientists Don’t Scale
Ingesting system and user behavior and automatically aligning it with the exposed cohort is rare among all but the most sophisticated in-house systems. この実践を試みるほとんどのチームは、多くの手動およびアドホックなデータ サイエンス作業を行っています。 計算能力よりも人的資源に制約されているため、いつ、どこに注目するかを選択することを余儀なくされているのです。
フローを目指す場合、認知的な負荷は味方にはなりません。そのため、Split の設計では、各機能フラグのロールアウトに関連付けるイベントをチームが選択する必要さえありません。 また、Segment、Sentry、mParticle、Google Analyticsとの連携により、イベントデータの特定と取り込みの作業も容易になります。
Semper Fi for Continuous Delivery Pipelines
各コホートに含まれる人と含まれない人の間でメトリックのパターンを厳密な方法で比較して、有意差を自動的に決定することは、アトリビューションよりもさらにまれなことです。 これは、まさに Split の Monitor および Experimentation モジュールが解決する問題です。 Monitor は、ロールアウトの進行中にメトリクスへの影響を特定して警告することに重点を置いています (「インシデントの爆発半径を制限する」としても知られています)。一方 Experimentation は、A/B テストと同様に、アナリストの利用可能性に制約されない、公平なデータの連続ソースを提供して、それぞれの機能が望ましい影響を達成したかどうかを示そうとするものです
Better Together: ピア レビュー、プログレッシブ デリバリー、および自動化されたセンス メイキング
なぜ私たちはフローを追求するのでしょうか。 それはアウトプットについてではありません。 それは結果についてです。 私たちは、より短い時間でより少ない摩擦で、アイデア -> 実施 -> 観察というフィードバックループを繰り返すことができるよう、フローに努めています。 インパクト駆動開発」と呼ぶにせよ「顧客駆動開発」と呼ぶにせよ、成果をより大きく（そしてより速く）意識してより速く進めるこのアプローチは、DORAチームがピアレビューの実践と組み合わせるよう推奨した「悪い変更を検出して拒否する展開パイプライン」をはるかに凌ぐものです。 しかし、より重要なのは、意味のあるビジネス成果に向けて三角測量するための再現可能なプロセスを構築できることです。
Learn More About Change Management and Flow, Together, in Continuous Delivery
- Continuous Delivery の定義に関する 4 分間のビデオでは、一貫したフローの達成になぜ小さなバッチ サイズが重要であるかが説明されています。
- O’Reilly の電子書籍「Continuous Delivery in the Wild」で、毎日本番環境に出荷している複数のチームからヒントを得る。
- Craig Sebenik (LinkedIn, Crunchbase, Matterport) による詳細なビデオで、トランクベースの開発に移行するメリットについて確認する。 Split ブログをブックマークしたり、YouTube で私たちをチェックしたり、Twitter @splitsoftware で私たちをフォローしてください。