数年前、マイクロソフトは社内全体で開発システムを復元するための長いプロセスを開始することを決定しました。 私たちは多くのチームを持つ大企業です。各チームには独自の製品、優先順位、プロセス、ツールがあります。 「一般的な」ツールはいくつかありますが、多くの異なるツールがあり、社内で開発された非常に多数の使い捨てツールがあります（チームによってユニット、つまり数千人のエンジニア）。



これには欠点があります：

1. 同様のツールを開発するチームへの過剰投資。
2. 「クリティカルマス」に対してツールキットの資金を調達できない。
3. さまざまなツールとプロセスが原因で会社内を移動する従業員の難しさ。
4. 組織間でコードを交換するのが難しい。
5. MSのみのツールが豊富にあるため、作業開始時の新人との意見の相違。
6. など...

「One Engineering System」または略して1ESと呼ばれるイニシアチブを思いつきました。 ちょうど昨日、1ESの日がありました。何千人ものエンジニアが集まって進捗状況を記録し、現状を調べ、計画について話し合いました。 それは驚くほど良い出来事でした。



トピックから少し脱線します...質問することができます-ねえ、MicrosoftがTeam Foundation Serverを使用していることを長年にわたって教えてくれました。 いいえ、嘘をつきませんでした。 5万人以上がTFSを定期的に使用していますが、必ずしもすべての作業にTFSを使用しているわけではありません。 一部はすべてに適用されます。 一部は作業トピックの追跡専用です。 一部はバージョン管理専用です。 アセンブリ用の一部... TFSが行うほぼすべての内部バージョン（および多くの場合、複数）があり、誰かがそれらをすべてどこかで使用しています。 ここには少し混乱がありますが、まったく正直です。 しかし、組み合わせて計量すると、TFSには他のどのツールセットよりも多くのユーザーがいると自信を持って言えます。



また、「エンジニアリングシステム」と言うときは、非常に広く用語を使用します。 含まれていますが、次のものに限定されません。

1. ソースコード管理
2. 作業管理
3. 組立
4. リリース
5. テスト中
6. パッケージ管理
7. テレメトリー
8. インシデント管理
9. ローカリゼーション
10. セキュリティスキャン
11. 在庫状況
12. コンプライアンス管理
13. コード署名
14. 静的解析
15. そして、はるかに

それでは、話に戻りましょう。 私たちがこの道に着手したとき、私たちがどこへ行くのか、何を主なものとすべきかなどについて、激しい議論がありました。ご存じのように、開発者は意見を持ちません。 :)失敗することなくすぐにすべてを解決する方法はなかったので、3つの問題から始めることに同意しました。

• 作業計画
• ソース管理
• 組立

これらは基本原則であり、さらに多くがそれらに統合され、それらに基づいているという事実以外に、詳細に詳しく説明したくないので、これらの3つの問題だけを選択するのは理にかなっています。 また、製品のサイズが原因でビルド時間と信頼性に大きな問題が発生したことにも注意してください。一部のプログラムは数億行のコードで構成されています。



時間が経つにつれて、これら3つの主要なトピックは成長し、さまざまな程度の1ESイニシアチブが開発プロセスのほぼすべての側面に影響を与えました。



面白い賭けをしました。 それらの中には：



未来はクラウドを超えています -インフラストラクチャとツールのほとんどはローカルでホストされています（TFSを含む）。 モビリティ、管理、進化、弾力性、思い浮かぶすべての理由-未来はクラウドにあることに同意しました。 数年前、それは非常に物議をかもしました。 マイクロソフトはすべての知的財産をクラウドにどのように譲渡できますか？ パフォーマンスはどうですか？ セキュリティはどうですか？ 信頼性？ 法的規範と管理の遵守？ どうでしょう...時間がかかりましたが、最終的にはそのアイデアに同意した人々の批判的な塊が蓄積されました。 長年にわたって、この決定はますます理解しやすくなり、今ではクラウドへの移行に誰もが喜んでいます。



ファーストパーソン==サードパーソン -この式（ファーストパーティ==サードパーティ）は、内部的に使用します。 これは、私たちが使用する製品を販売するために、商用製品を使用するために可能な限り最大限に努力することを意味します。 それは常に100％を解決するわけではなく、これは常に並列プロセスではありませんが、これは移動の方向です-他の方法で行う十分な理由があるまで、デフォルトの仮定です。



Visual Studio Team Servicesが中核です -基盤としてTeam Servicesに依存しています。 開発システム全体、つまりすべてを学び、すべてを達成するための中心的なハブをまとめるファブリックが必要です。 ハブは、近代的で、豊富で、拡張可能などである必要があります。各グループは、開発システムへの特別な貢献を提供および共有できる必要があります。 チームサービスはこの役割に最適です。 過去1年間で、Microsoftのこれらのサービスの視聴者は、数千人から50,000人以上の忠実なユーザーに成長しました。 TFSと同様に、すべてのグループが可能なすべての目的でそれらを使用するわけではありませんが、この方向の勢いは強いです。



Team Servicesの計画-Team Servicesを選択したので、適切な計画オプションを選択するのはかなり自然でした。 何千ものユーザーと何百万ものワークアイテムを持つWindowsグループのようなグループを単一のTeam Servicesアカウントにダウンロードしました。 それを機能させるには、パフォーマンスとスケーリングに関して多くの作業を行う必要がありました。 現時点では、Microsoftのほぼすべてのグループがこの移行を行っており、すべての開発はTeam Servicesによって管理されています。



オーケストレーションチームサービスビルドとCloudBuild-このトピックは深く掘り下げません。それ自体が巨大だからです。 アセンブリ操作を調整するシステムとしてTeam Services Buildを選択し、ユーザーインターフェイスとしてTeam Services Buildを選択した結果についてのみ言うことができます。 また、いくつかの最大のコードベース用の新しい「メイクエンジン」（まだリリースされていない）を開発しました。大規模、並列実行、増分、つまり段階的実行での微調整されたキャッシングをサポートします。 組み立てにかかる時間が何分かになることもありました。 これについては、今後の記事で詳しく説明します。



素晴らしい背景の後-最も重要なこと。

ソースコード管理用のGit

おそらく、ソースコード管理システムに関して私たちが下した最も議論の多い決定です。 Source Depotと呼ばれる内部システムがありましたが、これは2000年代初頭には絶対に誰もが使用していました。 時間が経つにつれて、TFSとそのTeam Foundation Version Controlソリューションは会社で人気を博しましたが、WindowsやOfficeなどの最大の開発グループに浸透することはできませんでした。 多くの理由があると思います。 その1つは、このような大規模なチームの場合、移行価格は非常に高く、2つのシステム（ソースデポとTFS）はそれほど正当なものではなかったということです。



しかし、バージョン管理システムは、他のどの開発ツールよりも強力な忠誠心を生み出します。 したがって、TFVC、Source Depot、Git、Mercurialなどのサポーター間の戦いは激しく、正直なところ、コンセンサスに達することなく選択を行いました。 多くの理由でGitで標準を作成することにしました。 時間が経つにつれて、この決定はますます多くの支持者を受け入れました。



Gitの選択には多くの議論がありましたが、最も強化されたコンクリートはスケーリングでした。 私たちの規模のコードベースを持つ会社は多くありません。 特に、WindowsとOffice（他にもあります）のサイズは非常に大きくなっています。 数千の開発者、数百万のファイル、数千のビルドマシンが常に動作しています。 正直なところ、これは驚くべきことです。 明確にするために、ここでWindowsについて言及する場合、すべてのバージョンを意味します-これらはWindows for PC、モバイル、サーバー、HoloLens、Xbox、IOTなどです。 また、Gitは分散バージョン管理システム（DVCS）です。 リポジトリ全体とその履歴全体をローカルマシンにコピーします。 Windowsプロジェクトでこれを行うのはばかげているでしょう（そして、最初はたくさん笑いました）。 TFVCとSource Depotは、大規模なコードベースと特定の開発チーム向けに慎重に調整および最適化されています。 Gitはそのようなタスクに使用されることはなく （または同じ桁の範囲内でさえ）、システムは決して機能しないと多くの人が主張しました。



最初の大きな議論は、会社全体に1つ、または小さなコンポーネントごとに1つ、開始するリポジトリの数です。 素晴らしい範囲。 Gitは、非常に多くの控えめなリポジトリで非常に優れたパフォーマンスを発揮しているため、大きなコードベースを中程度のサイズのリポジトリに分割することについて多くの時間を費やしました。 うーん 20年間、巨大なコードベースを使用したことがありますか？ その後、戻って小さなリポジトリに分割しようとしたことがありますか？ 私たちがどのような答えになったのか推測できます。 このコードは解析が非常に困難です。 価格が高すぎます。 このレベルの混乱からのリスクは巨大になります。 そして、非常に大量のコードで根本的な変更を行う必要があるのは、唯一のエンジニアが必要なシナリオです。 これを数百のリポジトリ間で調整することは非常に問題が多いでしょう。



手をひねった後、私たちの戦略は「コードの性質に応じて、リポジトリの正しい数」であると決定しました。 一部のコードは区別でき（マイクロサービスなど）、分離されたリポジトリに最適です。 一部のコードは（Windowsカーネルのように）部分に分割できず、単一のリポジトリとして理解する必要があります。 そして、ポイントはコードを部分に分割する複雑さだけではないことを強調したいと思います。 相互に接続された大規模なコードベースでは、このコードベースを全体的に把握する方が良い場合があります。 いつか、Bingの主要なプラットフォームのコンポーネントを個別のパッケージに分割しようとするBingグループの試みと、彼らが遭遇したバージョン管理の問題について話をするでしょう。 現在、彼らはこの戦略から遠ざかっています。



したがって、数百ギガバイトの数百万のファイルを持ち、数千の開発者が使用するコードベースで動作するようにGitのスケーリングを開始する必要がありました。 ちなみに、Source Depotでさえ、Windowsコードベース全体に拡張されることはありませんでした。 スケーリングできるように、40以上のリポジトリに分割されました。 しかし、レイヤーは最上部に構築されたため、ほとんどの場合、コードベースは全体として認識されます。 このような抽象化は理想的ではなく、間違いなく論争を引き起こしました。



少なくとも2つの方法でGitのスケーリングを開始できませんでした。 おそらく最も重要なのは、Gitサブモジュールを使用して、多くのリポジトリを1つの「スーパーリポジトリ」にまとめる試みでした。 詳細は説明しませんが、プロジェクトに6か月取り組んだ後、機能しなくなることに気付きました。境界の状況が多すぎて、複雑さが高く、プロジェクトが脆弱すぎます。 ほとんどすべてのGitツールで十分にサポートされている、実績のある信頼できるソリューションが必要でした。



ほぼ1年前、最初に戻って、実際にGitをWindowsコードベース全体（成長と履歴のグレードを含む）を含む単一のリポジトリにスケールする方法、およびすべての開発者をサポートし、マシンを構築する方法の問題に焦点を当てました。



Gitの「仮想化」を試みました。 通常、Gitは複製時にすべてをダウンロードします 。 しかし、そうでない場合はどうでしょうか？ 適切な部分のみをダウンロードするようにストレージ仮想化を行うとどうなりますか。 したがって、300 GBの大きなリポジトリのクローン作成は非常に高速になります。 自分の場所で読み取り/書き込みコマンドを入力すると、システムはいつの間にかクラウドからコンテンツをロードします（そして、ローカルに保存し、将来データがローカルにアクセスされるようにします）。 ここでの唯一の欠点は、オフライン作業のサポートが失われることです。 これを行うには、ローカル作業のためにマニフェストを残すためにすべてを「タッチ」する必要があります。 巨大なコードベースでは、このような仮想化オプションは受け入れられました。



これは有望なアプローチであり、プロトタイプの開発を開始しました。 Git Virtual File SystemまたはGVFSプロジェクトと呼ばれます。 git.exeに最小限の変更を加えるという目標を設定しました。 もちろん、Gitをフォークしたくありませんでした-これは災害になります。 そして、コミュニティがこれらの変更を受け入れないように、彼らはそれを変更したくありませんでした。 そこで、仮想ファイルシステムドライバーで、最大数の変更がGitの「下」で行われる中間パスを選択しました。



仮想ファイルシステムドライバーは、基本的に2つのことを仮想化します。

1. すべてのバッチファイル、履歴などが保存される.gitフォルダーこれはすべてのデフォルトフォルダーです。 必要なファイルのみを抽出し、必要な場合にのみ抽出するように仮想化しました。
2. 「作業ディレクトリ」は、ソースコードの実際の編集、コンパイルなどを行う場所です。GVFSは作業ディレクトリを監視し、タッチするすべてのファイルを自動的に「チェック」し、すべてのファイルが実際に存在するという印象を与えます。ただし、特定のファイルへのアクセスを実際に要求するまでリソースは必要ありません。

あなたが想像できるように、あなたが私たちの仕事を進めるにつれて、私たちは多くを学びました。 とりわけ、Gitサーバーはスマートでなければならないことを学びました。 クライアントに実際に必要以上に送信しないように、Gitファイルを最適な方法でパックする必要があります。これをリンクのローカリティを最適化することを想像してください。 そのため、Team Services / TFS Gitサーバーに多くの改善を加えました。 また、Gitが触れてはいけないファイルに触れるとき、Gitには多くのシナリオがあることがわかりました。 以前は、すべてがローカルに保存されており、Gitは中規模のリポジトリで使用されていたため、問題にはなりませんでしたが、非常に迅速に動作しました-しかし、すべてに触れる場合、サーバーからダウンロードするか、6,000,000個のファイルをスキャンする必要がありますが、これは冗談ではありません。 そのため、Gitのパフォーマンスの最適化に多くの時間を費やしました。 私たちが行った最適化の多くは、ある程度「通常の」リポジトリに利益をもたらしますが、これらの最適化はメガリポジトリにとって重要です。 これらの改善点の多くをGit OSSプロジェクトに送信し、それらとの良いコラボレーションを楽しみました。



だから、今日に早送りします。 すべてが機能します！ 40を超えるWindows Source Depotサーバーのすべてのコードを、VS Team Servicesでホストされている単一のGitリポジトリに配置しました。 数分で参加（参加）し、通常のGit操作をすべて数秒で実行できます。 そして、あらゆる意味で、それは透過的なサービスです。 ちょうどgit。 開発者は、使用したツールを使用して、作業を続けます。 ビルドは機能するだけです。それは驚くべきことです。 魔法！



付随する効果として、このアプローチは大きなバイナリファイルによく反映されます。 LFSのように新しいメカニズムでGitを拡張することはなく、「割り当て」などもありません。 他のファイルと同様に大きなバイナリファイルを操作できますが、影響を受けたブロブのみがダウンロードされます。

Gitマージ

ブリュッセルで開催されたGit Mergeカンファレンスで、Saeed Noursalehiは、私たちがしていることを、世界の人々と共有しました。 同時に、すべての作業をオープンソースに入れました。 また、導入する必要のある追加のサーバープロトコルも含めました。 GVFSプロジェクトおよびGit.exeに加えられたすべての変更は、Microsoft GitHubリポジトリで見つけることができます。 GVFSは新しいWindowsフィルタードライバー（Linux FUSEドライバーに相当するもの）に依存しており、GVFSを試すことができるように、Windowsチームと協力してこのドライバーを早期にリリースしました。 詳細および追加リソースへのリンクについては、 Saidの投稿を参照してください。 あなたはそれらを学ぶことができます。 GVFSをインストールして試すこともできます。



私はGVFSのパフォーマンスに注目していますが、まだやるべきことがたくさんあることを強調したいと思います。 終わりではありません。 私たちはこのコンセプトを証明したと思いますが、まだそれを実現するために多くの仕事があります。 公式発表を行い、ソースコードを公開して、コミュニティが協力するよう呼びかけます。 一緒に、最大のコードベースに合わせてGitを拡張できます。



長い投稿で申し訳ありませんが、それが面白かったと思います。 マイクロソフトの1ESイニシアチブの一部として、およびGitのスケーリングの両方で行われた作業に満足しています。