16章 バージョンコントロールとブランチ管理
16.1 バージョンコントロールとは何か
プレゼンテーションv5 - 最終版 - 2重赤線 - Joshのバージョンv2
文書管理がいまだにこんな感じになっている会社は少なくない
すごいわかる。。。(「文書_0605」と「文書_0603V2」と「文書_最新版」と何が新しいかわからないファイルがフォルダにあるw。
これは分かってしまうなw
社内的にはboxが一般的に使われるようになってだいぶ変わってきたと感じているが、いまだにやっている人は多い
Office系のファイルは実体が圧縮ファイルになっていてVCSで差分が見えづらいので、こうなってしまう感じは多少ある
MSさん、md形式で書くとOfficeのファイルができるようなもの、開発おなしゃす ()
Googleのような場所においても、新入社員にとっては、2人以上で作業したり、2週間よりも長い作業期間でのコード開発の経験はほぼないか全くないという状態は、全くもっともな話である
章の本筋とは関係ないけど、これはかなり意外だった
16.2 ブランチ管理
一貫したユニットテストが普通になる前の時代は、任意の変更の導入によりシステムの別の部分で機能のリグレッションが起きるリスクが高い状態であり、トランクを特別扱いすることが理にかなっていた
これ、安定したユニットテストがない状態でトランクベース開発を取り入れることは難しいと捉えて良さそうかな?
DevOps関連のSurveyとかだとトランクベース開発を実施している企業は安定したユニットテストを抱えている企業よりも多かったので、トランクベース開発はしているけどユニットテストを抱えていないみたいな企業はまともに運用できているのか気になる
ブランチの統一をしたがテストがなかった事例: ブランチの管理が煩雑になり統一した。ハードウェアなど、外部機器に依存するコードが多かったのでユニットテスト作成の徹底が難しかった
組み込みならばアップデートがないので、テストはリリースバージョンにつき1回でOKと考えられる
devブランチを多用するバージョンコントロールのポリシーは本質的に見当違いである
言っていることはとてもよくわかるけど、やっちゃう(これが中毒か。。。)
個人的な経験でいうと継続してメンテするブランチがトランク以外に2本あるとかなりきつい
この2本が同じ箇所を触ってるともう無理
特定の顧客向けの改修でもfeature toggleなどを使う、というのがここ最近の風潮
「トランクから頻繁に変更を取り込んで差分を最小限にする」「devブランチでもCIを回す」をやれば1本くらいは普通に管理できる
既存機能の改修でUATが必要なケースなどはこれをやらざるを得ない
ブランチを増やす話になったときには長期的なROIを示すと皆まともに考えてくれる
既存のブランチの数が多ければ多いほど増やすコストは増大する
損益分岐点はどこか?
話を持ってきた営業が個人の成績で評価されているケースだと、話す先を会社全体の利益を考える人に変えると上手くいくかもしれない
1日に何度もトランクからリリースする能力を備えることを達成している組織には、おそらくリリースブランチをスキップする傾向がある。
それはそうか
16.3 Googleでのバージョンコントロール
Google はPiperと呼ばれる内製の中央集権的VCSに依存しており
モノリポのポリシーを守るのにはたしかにgitだと都合が悪そうではある
16.1 の「信頼できる情報源」に関する議論はこの事実をフォローするためのものかも
組織にとっては選択の余地がないことこそが効率的なスケーリングのために欠くべからず要素となっている状況を、我々は繰り返し目にしている
実際、スケーリングのための作業って何も生み出さないですもんね。。。しかもテストしにくく壊れやすい
「コードは負債であって提供する機能が資産」という価値観がここでも/icons/iine.icon
16.3.4 存続期間の長いブランチを(ほとんど) なくす
去年あたりから急にトランクベース開発が騒がれだしたイメージがある
個人的な感覚だとだいぶ前(4-5年前)くらいから騒がれていたイメージはある /icons/iine.icon
「LeanとDevOpsの科学」の邦訳出版が5年前なので、その頃でしょうか
DevOps 技術: トランクベース開発
16.4 モノリポ
モノリポというアプローチについての論文
あった
ChatGPTに食わせてモノリポを選んだ理由を聴いてみた
Googleは、バージョン管理、コード共有、依存関係管理の簡素化、アトミックな変更、大規模なリファクタリング、チーム間のコラボレーション、柔軟なチーム境界とコード所有権、コードの可視性などの利点から、繰り返し中央リポジトリに固執することを選択しました。
重要なのは、モノリポを重視するかどうかではない。重要なのは単一バージョン原則をできるだけ、最大限に守ることである。
この章のキーセンテンスじゃなかろうか
VCSの話をしているようでずっと単一バージョン原則の話をしている。。
第3部っぽい章
Googleの「原則を作って徹底的にスケールさせる」力はすごい
全員を納得させるだけのエビデンスをちゃんと取ってくるあたりもさすがGoogle
VCSとビルドシステムの両方を含むソフトウェアエンジニアリングのツールは、粒度の細かいリポジトリーとモノリポをスマートな形で混合するメカニズムを提供することが増えている。
ビルドコマンドを実行すると依存関係を勝手にダウンロード・ビルドしてくれるビルドシステムが多くなってきてて便利
dotnet run, meson/ninja, bitbake, etc...
Go言語など、言語のコンパイラ組み込みのものも。
Visual Studioを使った開発だと、親リポにソリューションファイルだけがあり、サブモジュールとしてプロジェクトファイルやソースコードが管理されていることはよくある
バーチャルモノリポ
package.json のようなモノをイメージしているが合っているのだろうか
babelの名前空間が移行したときには酷い目にあったのでモノリポのメリットはわかる
あれこれ論じてはきたものの、ファイルシステム形式の選択は実際のところ、そのファイルに書き込む内容ほどに重要なわけではない。
良いしめくくりだが、その後(16.5)でもファイルシステムの話が出てくる所が面白い。
16.5 バージョンコントロールの未来
事実上の標準としてのバーチャルモノリポが発生することになるだろう。そのモノリポ内のユーティリティに頼ることで、互換性のある依存関係のセットを一単位として簡単にアクセスできるようになるだろう。
業界に「依存関係が解決された最新バージョンのセット」が出現する、という予測
現在でも依存ライブラリを最新に更新していればこれに近い状態が実現している
Python 2と3みたいなことになると誰も幸せになれないのでリリース時期を固定する運用が増えている
例: ruby, nodejs
ただ、この標準モノリポで、あるライブラリAに破壊的な変更が入ったことによって別のライブラリBが動かなくなった場合、AとBどっちを優先して上げるかで揉めそう
OSSコミュニティ内での政争は破滅フラグ
Linusのようなオーナーが居る単一コミュニティ内で、サブライブラリ間の優先順位を決めるなら大丈夫そう
メニーリポのアプローチに固有の有利な点は、別々のリポジトリーが、権限のある開発者、可視性、パーミッション等のセットを個別に持つことが、当然ながら可能であることだ。この特徴をモノリポに継ぎ足すことは可能だが、カスタマイズと保守の面での、多少の継続的な維持コストを失う。
開発ベンダーが別れたりしていると、この辺の考慮が必要になってメニーリポにせざるを得なくなりそう。
クローズドなソースがあるとリポジトリを分けざるを得ない
Googleにとっては社内開発とOSSの2種類しかコードがないのかも
16.6 結論
すなわち、個々の開発者にとっては単一バージョンルールはうっとうしいかもしれないが、総合的には、最終結果がはるかに優れたものとなるのだ
上に単一バージョンルールの話をずっとしているという話も書いていたが、章の結論としてふさわしいと感じる内容だった。
この観点で考えると、「開発者体験を上げよう」レベルの解像度だと組織のスケーリングに支障をきたしそうだなあと思った /icons/iine.icon
16.7 要約
みんなからのコメント
Googleにしかできないとしたら、それはなぜか?
50,000人のエンジニアが24時間ストレスなく上流からのクローン処理を行い続けることができるバージョンシステムを作れる技術力
クローン処理に関しては計算資源/ネットワーク資源がじゃぶじゃぶかもしれない
単一バージョン原則の重要性を見抜けるシンクタンクが社内にあって、全社にスケールするまでやりきるだけの実働部隊を抱えている組織力
現場でどこまでできているか?
バージョン管理のルール化はされていて、WikiやリポジトリのREADME.mdにも書いてあったが、割と皆思い思いのブランチを切っていた。
もっと原始的だが、似たような開発体制になっている。trunkベース開発+免許性(免許を持った人だけがコミットできる)で運用している。なおかつモノリポ。
チーム内でのモノリポ運用はほとんど達成(CIでビルドをやらせたいDockerfileだけ別管理)&トランクベース開発は実現できているが、社内にある複数のチームのリポジトリ統合は考えもしなかった
社内ライブラリの開発が発達している会社では全社モノリポ運用の事例がある?
ソウゾウ社では事例があるとのこと
https://www.youtube.com/watch?v=YK3I4c41Hfo
モノリポならshared library の再発明が不要
最初期のトップダウンな決定が必要
モノリポに伴って発生する問題
「このコード書いてる人がこの職位?」
この本があるのになぜ実践する企業はすくないのか?
安定したユニットテストの有無は一つの壁になっているような気がする
納期の問題などで、ブランチを切った上で最低限の修正・追加実装をしてリリースすることもしばしば
それの乗り越え方はなにか?
トランクベース開発でうまくいかなかった時に、テストの改善に踏み切る
体制を立て直すための工数を算出し、ロジカルに説明して上から工数を勝ち取る
16.2 ブランチ管理 の長期的なROIの話参照
https://scrapbox.io/files/6487183d7d4f1f001c54bec2.png
Debt(SonarQube)
Technical Debt: The estimated time required to fix all maintainability issues and code smells
ステップを小さくするとしたらどうできそうか?
トランクベース開発をしてみて、頻度が高く必要になってくるリグレッションテストをまず洗い出すというところかな、と思った