2/13/2017

Googleでのソフトウェア・エンジニアリング (2.1)

Googleでのソフトウェア・エンジニアリング」と題する論文の2.1節、ソース・リポジトリ。

2. ソフトウェア開発


2.1. ソース・リポジトリ

Googleのコードの大部分は一つにまとめられたソースコード・リポジトリに保存されており、Googleの全てのソフトウェア・エンジニアがアクセスできる。明らかな例外に、特別に独立したオープンソースのリポジトリを使用する2つの巨大なオープンソース・プロジェクトChromeとAndroidがある、分かれたオープンソース・リポジトリを使用し、読み取りアクセスがより緊密にロックされている高価値あるいはセキュリティ的に重要なコードの一部である。しかし、ほとんどのGoogleプロジェクトは同じレポジトリを共有している。2015年1月時点、10億のファイルを含む86テラバイトのレポジトリには、900万以上のソースコードファイル、合計20億行のソースコードが含まれており、3500万のコミット履歴と1日当たり4万コミットの変更がある[18]。リポジトリへの書き込みアクセス権は制御されている: リポジトリの各サブツリーのリストされている所有者のみがサブツリーへの変更を承認できる。しかし、一般的にどのエンジニアもコードの一部にアクセスでき、チェックアウトしてビルドでき、ローカルに変更でき、テストでき、コードの所有者によってレビューのための変更を送ることができる。文化的には、エンジニアはプロジェクトの境界を問わず、壊れたものを確認して修正し、修正方法を知ることが奨励されている。これはエンジニアに自信を持たせ、それを使用する人のニーズを満たす高品質のインフラにつながっている。

ほとんど全ての開発はブランチではなく、リポジトリのヘッドで行われている。これが、 統合の問題を初期に特定し、必要なマージ作業量を最小限に抑えるのに役立つ。セキュリティ修正をより簡単かつ迅速に行うこともできる。

これは常に実行されるわけではないが、しばしばテストの推移的依存関係(transitive dependencies)にあるファイルを変更した後で、自動化されたシステムは高い頻度でテストが実行される。これらのシステムは一般的に数分以内に、テストが失敗した変更の作成者やレビュアーに自動的に通知される。ほとんどのチームは、ビルドの現状を派手なディスプレイあるいは色分けされたライト(ビルドに成功して全てのテストを通過するとグリーン、いくつかのテストに失敗するとレッド、壊れたビルドはブラック)を持つスカルプチャーで人目につくようにする。これは、エンジニアにビルドグリーンを維持するよう集中させるのに役立つ。ほとんどの大規模チームは、ヘッドでテストを通過し続けることを確実にすることに対して責任のある「ビルドコップ(ビルドお巡り)」も置き(ビルドコップの役割は通常、チーム間あるいはより経験のあるメンバー間で持ち回りで担当する。)、問題を素早く修正する、あるいは問題となる変更をロールバックするため、問題のある変更の作成者と一緒に取り組んでいる。ビルドグリーンを維持することに集中することは、非常に大きなチームであっても実際に役立つ開発ができる。

コードの所有権。リポジトリの各サブツリーに、サブツリーの所有者のユーザIDを列挙するファイルを置くことができる。サブディレクトリは親ディレクトリから所有者を継承するが、任意で省略可能である。各サブツリーの所有者はサブツリーへの書き込みアクセス権を制御するが、後のコードレビュー節で説明する。各サブツリーは少なくとも2人の所有者が必要であるが、通常は、特に地理的に分散されたチームではそれ以上存在する。所有者ファイルに列挙されるのがチーム全体にとって一般的である。サブツリーの変更はGoogleの誰でも、所有者ではない人も行うことができるが、所有者によって承認されなければならない。これにより、全ての変更は、修正されたソフトウェアを理解しているエンジニアによってレビューされることを保証する。

Googleのソースコード・リポジトリの詳細については、[17, 18, 21]を調べて欲しい。また、他の大企業が同じ課題をどのように処理しているかについては[19]を調べて欲しい。