Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス

22章大規模変更

Hyrum Wright 著

Lisa Carey 編

　しばしの間、読者自身のコードベースについて考えてみてほしい。複数のファイルを一斉に更新対象とするコミット1回で、信頼性のある状態で更新可能なファイルの数は何個だろうか。その数を制限する要因は何か。ファイル数に制限がかかるほど大きな変更のコミットをこれまで試みたことはあるか。緊急の場合に、そのようなコミットを妥当な時間内に行うことは可能だろうか。自分が行ったことのあるコミットで最大のもののサイズは、自分のコードベースの現在のサイズとの比較ではどの程度を占めるか。そのような大きなコード変更はどのようにしてテストするのだろうか。その変更をコミット前にレビューするのにレビュアーは何人要ることになるだろうか。その変更は、実際にコミットされた場合にはロールバックが可能だろうか。以上の質問への答えは、意外なものかもしれない（意外というのは、読者が答えだと思っているものと、読者の組織にとって実際にその答えが結局どういうものになるかの両方だ）。

　社内のコードベースの至るところに影響する広範囲のコード変更を、上述の類のアトミックな大規模変更内で行うという考え方は、Googleではとうの昔に放棄されている。我々が見てきた限りでは、コードベースとその中で作業するエンジニアの数が増大するにつれて、アトミックに行うことが可能な変更の最大サイズは、直感に反して減少する。例えば、コード変更が影響するリポジトリー提出前のチェックとテストを全部実行するのが難しくなり、またリポジトリーへのコード提出の前にコード変更内の全ファイルが最新であるのを保証することすら難しくなるのは言うまでもない。社内のコードベースへ広範な変更を行うことが難しくなってきているため、基盤のインフラストラクチャーを絶えず改善できるようにしたいという一般的志向がGoogleには前提としてある以上、大規模変更が実際には何を行うのかについての新しい解釈法と、そのような解釈法を実装する方法とを開発しなければならなくなっている。 ...