これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
前回に続いて、2016年に公開された学術記事「Why Google Stores Billions of Lines of Code in a Single Repository」をもとにして、Google社内で利用されているソースコード管理システムを紹介します。
前回説明したように、Googleでは、ほぼすべてのソースコードが単一のリポジトリで管理されており、すべての開発者が共通のソースコードを利用できるようになっています。今回は、このような仕組みがもたらす利点と課題を説明します。
冒頭の記事では、単一のリポジトリを使用する利点として、次のような点があげられています。
まず、複数バージョンにまたがる依存関係ですが、たとえば、図1左のようなライブラリーの依存関係を考えてみます。アプリケーションAは、内部的に、ライブラリーBとライブラリーCを使用しており、さらに、ライブラリーBとライブラリーCは、どちらも共通のライブラリーDを使用しています。この時、それぞれのライブラリーが別々のリポジトリで独立に管理されているとすると、ライブラリーBとライブラリーCで、前提となるライブラリーDのバージョンが異なる可能性が発生します（図1右）。そうなると、ソフトウェアAをビルドする際は、異なるバージョンのライブラリーDを使い分けないといけなくなります。一般的なビルドツールでは、このような状況は想定されておらず、ソフトウェアAをビルドすることは困難になります。
一方、前回紹介したように、Googleのソースコードリポジトリでは、トランクベースの開発が行われており、開発中のソフトウェアが複数バージョンに枝分かれすることはありません。あるライブラリーのトランクに変更をコミットすると、それを前提とするすべてのソフトウェアに対して、再ビルドの処理が行われて、その変更が即座に反映されます。再ビルドに伴う自動テストによって、あらゆるソフトウェアに対する変更の影響をその場で把握することが可能になり、これにより、ソフトウェアによって前提ライブラリーのバージョンが異なるという問題が発生しなくなります。
図1 ライブラリーの依存関係の例（記事より抜粋）
次の大規模なリファクタリングは、社内の開発者に対して、すべてのソースコードが公開されていることによって得られるメリットです。たとえば、すべてのC++のソースコードに対して、新しい言語仕様に対応した共通の修正を加えて性能改善を図るといった事が可能になります。ソフトウェアごとにリポジトリが分かれている場合、このような変更は、各リポジトリの管理者が個別に行う必要がありますが、この仕組みの場合、専任のチームがすべてのソースコードをまとめて分析した上で、計画的に変更を進めることができます。変更に必要なツールを各チームが個別に開発する必要もありません。
あるいは、性能改善の指標となるデータをまとめて収集することも可能になります。Googleのコンパイラー開発チームでは、定期的に実行される全ソースコードの自動ビルド、および、自動テストの結果を収集することで、コンパイラーの機能改善を図っており、2014年から2015年にかけて、JavaのガーベッジコレクションによるCPU使用率を50%削減することに成功したことが紹介されています。
最後のソースコードの共有については、同じ機能のライブラリーをプロジェクトごとにメンテナンスするという無駄を削減するとともに、プロジェクトチームの再編成を容易にするという効果があります。これも前回に触れた点ですが、すべての開発者は、すべてのソースコードに対して変更を提案することができるので、他のチームが管理するソースコードをフォークして利用するようなことはありません。誰もが同じソースコードを利用しているので、プロジェクトの統合、あるいは、プロジェクト間でのソースコードの管理権限の移行も容易になります。
それでは、このような仕組みに伴う課題には、どのようなものがあるのでしょうか？ これについては、次のような点が指摘されています。
まず、専用の管理ツールですが、前述のように、1つのソースコードの変更をトリガーにして、依存関係のあるすべてのコードの再ビルドと再テストが行われるわけですので、これを実現するための仕組みが必要になります。前回の図1で紹介したように、毎日約4万個ものコミットが行われるため、分散ビルド環境をはじめとする、高いスケーラビリティをもった仕組みが必要となります。また、他のチームが開発するライブラリーを利用する際は、ライブラリーの仕様を確認するために、ドキュメント、あるいは、ソースコードの中身を検索する必要があります。そこで、900万以上にもおよぶソースファイルを効率的に検索する、専用のコード検索システムが用意されています。このような管理ツールの開発・メンテナンスに対する投資が必要不可欠となります。
また、すべての開発者がソースコードを共有することで、必要な際は、誰もがソースコードを見て仕様を確認することができるのですが、実は、これによって発生する問題もあります。ライブラリーの開発チームは、他のチームの開発者に対して、ソースコードから仕様を確認することを期待してしまい、意図した利用方法をドキュメント化するという作業を後回しにしてしまうのです。そのため、ライブラリーの内部実装に依存した、意図しない利用が行われてしまい、ライブラリーのリファクタリングが困難になることがあります。このため、ライブラリーが提供するAPIはデフォルトでprivateに設定しておき、開発チームが明示的に公開したAPIのみを利用可能にするなどの対応が行われています。
最後のコードの不具合は、あらゆるソフトウェア開発に当てはまることですが、特に、Googleのモデルの場合、ソフトウェアの依存関係が複雑になり、不具合の影響範囲が大きくなりやすいという特徴があります。そのため、すべてのソフトウェアの依存関係を探索して、どのAPIがどのソフトウェアから利用されているかを自動的に調べるといった仕組みが用意されています。これにより、APIの変更の影響範囲を適切に把握して、利用されなくなったAPIを削除するなどのメンテナンスが容易になります。
今回は、単一のリポジトリを用いたトランクベースの開発という、Googleのソフトウェア開発の仕組みについて、その利点と課題を説明しました。ちなみに、冒頭の記事によると、オープンソースの世界では、Gitを用いた個別リポジトリでの管理手法が広がっており、Google社内でもGitの採用が検討されたことがあるそうです。AndroidやChromeなど、オープンソースコミュニティとの連携が必要なソフトウェアの開発では、Google社内でもGitが使用されています。しかしながら、既存の巨大なリポジトリをGitに移行するのは容易ではなく、現在の仕組みの利点を考えた上で、Gitへの全面的な移行は見送られることになったそうです。
次回は、Googleが開発した、新しいネットワーク通信の仕組みを解説したいと思います。
Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
