22章 大規模変更
リポジトリーへのコード提出の前にコード変更内の全ファイルが最新であるのを保証することすら難しくなる
これ最近やらかしました
影響範囲の広い変更をマージした際、入れ違いで入った変更に影響箇所があってtrunk のテストが落ちました
リリース直前だったので慌ててrevertしました
社会的テクニックと技術的テクニックの双方について語る
社会的テクニックにも言及があって「お、気になる」となった
22.1 大規模変更とは何か
22.2 誰がLSCを扱うのか
数個のチームのみにLSCを担当させることにより、そうしたコストを内部化すると同時に(中略)コスト削減を行っている
この種の移行を実行するチームに予算と人員を付けるのは(中略)予算がつけられていない命令が生み出す外部性を内部化しているだけであり、さらに規模の経済の恩恵にもあずかることができる。
外部性:経済活動の費用や利益のうち、第三者に影響が生じるもの。無料のWebサービスや大気汚染など
目の付け所への驚きはもちろんあるが、モノリポの運用コストとして一番馬鹿にならない部分だったんだな、とも思える
私もここ面白いと思いました
22.3 アトミックなコード変更への障壁
変更サイズが増大するのに従い、マージの競合が起こる
featureを使ったgit-flowで開発してるがコンフリクトがつらい...
エンジニアの人数が増えてきて、辛さが増してきた
Googleのコードベースは自重ですぐに萎縮し潰れてしまう
良い表現だなあ
コードが複雑であればあるほど運用コストと変更コストを生み出してしまうことの良い例え
TAPトレイン
すごい仕組み
変更の局所性を活かして無作為にテストを実行して、落ちた箇所の原因の特定までやって通ったものだけリポジトリに乗せる
キューと定時実行でリソースを抑える
1, 2は枝刈り?
リポジトリ提出前テストの実行を1回に抑えるため
コードレビュー
始まる前にkyonさん言ってたけど、コードレビューとかもAIがやる時代だし、ある程度のコミット数は許容できるのかも (人力はつらい
LLMによるレビューの延長として、形式を作成し、それ使ってのレビューができると面白い
22.4 LSCインフラストラクチャー
LSCを取り巻く文化的転回
「各々が担当している領域のドメイン知識に対する信用」がインフラの先頭で扱われているの、Googleがいかに組織を大事にしているかがわかる
コストを下げるのは信用
22.5 LSCプロセス
1人の専門家にそのコード変更の性質を理解させた上で、そのコード変更を適切にレビューする作業をめぐる自動化処理の構築を任せる方が、コストが低くなる。
「専門家」の存在と組織的にこの判断ができるのが強みだよなあ
「専門家」とはparserの専門家が多いのだろうか
少し後でプログラミング言語やライブラリの専門知識を備えている「グローバル承認者」が出てきた
認可、コード変更の作成、シャード管理、クリーンアップと定義されているのがなんかいいなーっておもった。ウォーターフォール開発?のようになりそうなこの領域をソフトウェアの言葉で再定義して、メタファーとしてわかりやすくしつつ、ライトな感じにしているというか。
シャード分割以外はウォーターフォール的になるのは仕方なさそう
自動化された処理っぽい名前になっているし、実際に大半は自動化されている
要件定義→認可、実装→変更作成、テスト・レビュー→シャード管理、横展開・運用→クリーンアップ
グローバル承認者は各コード変更をレビューするのにパターンベースの別のツール環境群を使い、自身の期待を満たすコード変更を自動的に承認
まさにAIじゃないか。。。
必要ならツールを作るんでしょうねこの人たち
Tricorderフレームワークを用いて、廃止されたオブジェクトの利用をエンジニアが新しく始めている場合には、レビュー時点でフラグを立てる
大規模変更で一番しんどいのは古い書き方を使わないよう周知することなので、これは無敵に近いソリューションかも
22.6 結論
22.7 要約
みんなからのコメント
Googleにしかできないとしたら、それはなぜか?
LSCを効率化するための自動化ツールの開発力がそこまでなさそう & 自動化ツールが入りやすいように整備された既存の環境がない。
モノリポでないと必要になる状況が少ない
事実上、「グローバル承認者」が必須の仕組み。言語ごとに違うらしいので、Googleの人材プールでないと機能しないのでは?
現場でどこまでできているか?
LSCにたいしてはたぶんほとんどなにもできていない気がする。
CIでのテスト全件実行が通れば、そこを信頼するくらい
この本があるのになぜ実践する企業はすくないのか?
既存のツールがあまりないからとか?でも、GitHub Copilot系でこれは進むような気もする。
大規模変更が巨大になりすぎるのはモノリポ採用によるトレードオフで、これを避けるためモノリポを導入していない、というところが多そう
Rosieに含まれるようなツールを内製しているところがあっても、表に出てきにくい?
それの乗り越え方はなにか?
言語やツールやリポジトリのルールを厳しくしたら、プロセスの導入くらいはできそうかも?
(アナログだったり手動だったりであれば、ウォーターフォールの会社でやっていることとにているなーっておもったり。それを高速でスケールするようにしているのがすごいので、そのための制約をいかにつくりこめるかなのかなーとか)
ステップを小さくするとしたらどうできそうか?
自動テストの選別の考え方くらいはすぐにでもできそう。Launchableでも実装してくれないかなーみたいなことをおもった。
1つのリポジトリ全体にまたがる変更をレビューする際の仕組みとして採用する
レビュー用のツールを作る、大規模変更用のレビュアーを用意する、PRをシャード分割して出す、テストを選別してCIを回す仕組み
廃止されたオブジェクトを検出する仕組みがほしい