Deployment Rings

向井の紹介した論文の中で Deployment Ring と呼ばれる Microsoft のリリース戦略が紹介されていました。Deployment Ring がどんなものかは Microsoft Azure の Devops 解説サイトにも解説があります。

要するに、ユーザをリスク許容度に応じてサブセット (ring) に分割し、Ring ごとにデプロイするバージョンを決めましょうという話。なお上の記事によると ring の原点は書籍 "Continuous Delivery" だそうです。(手元にあったのでぱらぱら眺めましたが ring という語は使われていませんでした。)

野次馬としては Microsoft がいくつの ring すなわちステージングを使っているのか気になるところです。このページでは Office 365 が 5 つの ring を定義している様子が伺えます。なおエンタープライズ向け Windows は管理者が社内配布用に ring を定義できるらしく、この文書では 7 つの ring を定義する例を紹介していました。そんなにいっぱい必要なの・・・。

向井は Ring が Chrome の Channel に相当すると指摘しました。Chrome が則っているリリースサイクルは以下の文書で説明されています。

Chrome の Channel は Depoloyment Ring の一種。ユーザが自薦によってリスク許容度を決めます。高いリスクを受け入れ新しい機能をいち早く試したいユーザはデフォルトの Stable channel のかわりに Beta や Dev といった channel をインストールすることができます。

Deployment Rings 内にある各 ring のバージョンをどのように更新していくかはチーム次第です。Chrome の channel は 6 週間に一度、同時にすべての channel のバージョンを一つづつ上げる、つまり一つ手前の ring のバージョンが次の channel に降ってくる方針をとっています。例外は ring 0 に相当する canary channel で、この channel には 6 週間をまたずもっと頻繁にビルドが降ってきます。

Deployment Rings でもバージョンは内側から外側へ波及していきます。一方で ring の数が多かったりリリースの頻度が高い場合, Chrome のように全ての ring/channel が異なるビルドを持つことは稀でしょう。複数の ring が同じビルドを指すことも多いのではないでしょうか。

Development Branches

Deployment Rings に配るビルドは、バージョン管理システムの特定リビジョンを Continuous Integration / Delivery システムがビルドのちプッシュします。

デプロイ先のユーザ人口を決める Deployment Rings とソースコードバージョン管理の Development Branches は直交した概念ですが、現実には Deployment Ring ごとに特定の Development Branch を割り当てるのが普通です。一つ前の節で「バージョン」という言葉をつかっていますが、ここでいうバージョンは branch に対応すると考えて良いでしょう。

大昔は rings に 1:1 で対応する長生きな branches を作り, branch 間でひたすらマージを続ける開発モデルもありました。現代的な開発では長生きするのは master のみで、release branch はバージョンごとに使い捨てて cherrypick のマージだけをするのが普通です。現代的なブランチの運用方法については以下のサイトによくまとまっています。

なおリリース間隔が長い operating systems の開発などでは branch が長生きしがちで、 trunk based development を実践するのは難しいように感じます。そんななか Microsoft は "Windows as a Service" を名乗る Windows 10 からリリース間隔を縮め, Git に乗り換えて trunk based development を実践しているそうです。すごい！一方同じく Git ベースで開発をしている Android ではしばしば branch から master に "upstream" をしていることが知られています。やめてくれ！

つい勢いで Android の悪口を書いてしまいましたが、長命 branch に upstream をするアプローチには今でも根強いファンがいます。たとえば Git 運用の文脈でしばしば引用される Gitflow などはこのアプローチのひとつ。個人的には嫌いですが宗教論争になりがちなので深入りはしません。

Monorepos

リリースやソースコードの管理に関する宗教論争といえば "Monorepo" を忘れてはいけません。Monorepo はある製品、あるいは組織全体のソースコードを一つのレポジトリで管理する方法。Google が企業全体のコードを一つのレポジトリで管理している (といいつつ Android と Chrome は別) のは Monorepo の例として一部では良く知られた話ですが、上でリンクした資料によると Microsoft Windows のソースコードも単一の Git レポジトリで管理されているそうです。企業全体はともかく一つの製品が一つのレポジトリに収まっているのはわかりやすい気がします。

Monorepo には確かに利点があるものの、現在のソフトウェア開発エコシステムではデプロイの単位に Git レポジトリを使うのが慣習になっています。複数製品のコードを一つのレポジトリに押し込むとこの慣習から外れるためツールの採用などで不都合が多く、現実的ではないでしょう。AWS が自社データセンターの時代を終わらせたように、GitHub が Monorepo 優位の時代に終止符を打ったというのが森田の印象です。自社データセンターを持つ Facebook や Twitter などが Monorepo を採用しているのは象徴的というか、ある種の時代を感じます。

とはいえ直接デプロイする先のあるプロジェクト以外、たとえばライブラリやフレームワークにどのような粒度で独立したレポジトリを与えるべきかには共通見解がないような気がします。もちろんプログラミング言語など文脈によって変わるものではありますが、なんらかの方針がないと不安。森田が Monorepo の世界に飼いならされて時代の空気をわかってないせいでしょうか。なにか良い資料をご存知の方は教えてください。

今週のエピソード

そんなわけで今週は向井が Microsoft のデプロイに関するツールを、森田は画像認識の話を紹介しました。

お手紙紹介

少し前に AWS の障害があった影響か Episode 64 を聴いてくれた人が多かったみたいですね。Podcast はオフラインでも聞けるのでクラウドが落ちても安心。AWS の postmorterm は昔から割と定評がありますが、最近はどうなんでしょうね。かつて S3 の postmortem でしれっと gossip protocol の採用を明かし一部の人（森田含む）を戦慄させたのは・・・もう 10 年前のことでした。年取ったな・・・。

幸運をお祈り申し上げます。

論文は無限にあるのでみんなやろうぜ！がんばってる人類として Leading NLP Ninja と Researchat.fm を（再）紹介しときますね。

われわれも引き続き人類してきたい所存です。

広めたいので iTunes に星つけてね！あと慣れない専門用語に噛み噛みしているのを聞きつつ寝落ちしたいという声に応え、少し前から細かい編集をやめました。Hahaha.

それではまた次回。