世界最大のGitリポジトリ

「Git Virtual File System」と呼ばれるイニシアチブで、非常に大規模なプロジェクト向けにGitをスケーリングする試みに関する最初の記事を公​​開してから3か月が経ちました。 思い出させてください：GVFSとGitのいくつかの編集を組み合わせることで、非常に大きなリポジトリを操作し、.gitフォルダーと作業ディレクトリの両方を仮想化できます。 リポジトリ全体をダウンロードしてすべてのファイルをチェックする代わりに、このツールは必要なフラグメントのみを動的にダウンロードし、これまでの作業に基づいてそれらを識別します。



この間に多くのことが起こりました。あなたとニュースを共有したいと思います。 3か月前、GVFSは単なる夢でした。 それが存在しなかったという意味ではなく-私たちはすぐに実装できましたが-それはまだビジネスでそれ自体を見せていなかったという事実で。 大規模なリポジトリでテストしましたが、かなりの数の開発者向けにワークフローに実装することができませんでした。 したがって、私たちはすべてがうまくいくと推測しているだけでした。 これで確認できました。









今日、私は結果を発表したかったです。 さらに、GVFSを開発するために計画している次の手順をユーザーに発表します。特に、当社、パートナー、顧客のニーズに応じて、オープンソースに貢献する機能を追加し、機能を改善します。

Git上のWindows：ライブストリーミング

この3か月の間に、MicrosoftでWindowsを使用するチームのためのGit / GVFSの実装をほぼ完了しました。



簡単に言うと、Windowsコードベースは350万のファイルで構成されています。 Gitにアップロードすると、サイズが約300ギガバイトのリポジトリが取得されます。 さらに、同社は約4,000人のエンジニアを雇用しています。 エンジニアリングシステムは、ビルド検証のプルリクエストに加えて、毎日440のブランチで1,760のビルドを生成します。 これらの3つの状況（ファイルの数、リポジトリのサイズ、作業のペース）はすべて、個々の問題を非常に複雑にし、一緒に考えると、ポジティブな体験を提供することが非常に困難なタスクになります。 Gitに切り替える前は、Source Depotを使用し、コードは40以上のリポジトリに分散されていました。さらに、操作を管理するための特別なツールもありました。



3か月前の最初の記事のリリース時には、すべてのコードが1つのGitリポジトリに格納されていました。これは数百人のプログラマーによって使用され、ごくわずかなビルド（10％未満）を処理していました。 それ以来、複数の段階でエンジニアリングチーム全体のプロジェクトを展開しました。



最初の、そして最も大規模な飛躍は3月22日に発生し、Windows OneCoreチーム全体を約2,000人の新しいシステムに移行しました。 これらの2000人のエンジニアは金曜日にSource Depotで働いていましたが、週末の後にオフィスに戻ったとき、Gitの根本的に新しい経験を待っていることを発見しました。 週末を通して、私のチームは指を交差させて座り、月曜日にすべての作業が滞ったエンジニアの怒った群衆に引き裂かれることがないように祈りました。 実際、Windowsチームは、何か問題が発生した場合のバックアップ計画を非常によく考えました。 幸いなことに、それらに頼る必要はありませんでした。



しかし、すべてが予想外にスムーズに進み、開発者は最初の日から生産性を損なうことなく新しい条件に順応することができました。正直なところ、私は驚きさえしました。 もちろん、困難が生じました。 たとえば、Windowsチームは、そのサイズと作業の詳細のために、非常に大きなブランチをマージする必要がありました（数万の変更と数千の競合について話している）。 すでに最初の週に、プルリクエストとマージの競合を解決するためのインターフェイスが、このような大規模な変更に適していないことが明らかになりました。 インターフェイスをハングさせないように、リストを緊急に仮想化し、段階的にフェッチコマンドでデータを受信する必要がありました。 数日後、私たちはこれに対処し、一般的に、週は予想よりも前向きなメモを通過しました。



イベント全体の成功を評価するために使用した方法の1つは、エンジニアの調査です。 私たちが彼らに尋ねた主な質問は、「満足していますか？」でした。もちろん、詳細について尋ねることを忘れていませんでした。 最初の調査は、プロジェクトの開始から数週間後に行われ、次の結果が示されました。









（完全に満足：54;

やや満足：126;

むしろ不満：54;

非常に不満：17）



指標は喜びのためにジャンプするようなものではありませんが、チームが世界をひっくり返したばかりであることを考えると、彼らは新しいスキームに従って働くことを学ばなければならず、まだ移行の過程にありました-結果はかなりまともなようでした。 はい、2,000人の従業員のうち251人しか回答しませんでしたが、調査に参加してもらいたい人の世界へようこそ。



成功の測定に使用した別の方法は、エンジニアの活動を追跡して、必要な量の作業が行われているかどうかを確認することでした。 たとえば、すべての公式ユニットの塗りつぶされたコードフラグメントの数を修正しました。 もちろん、会社の半分はまだSource Depotに残っており、後半はすでにGitに切り替えていたため、測定値には結果の混合が反映されていました。 以下のチャートでは、Source Depotでアップロードされたファイルの数が著しく減少し、Gitでプルリクエストが顕著に増加していますが、合計数はセグメント全体でほぼ同じです。 これらのデータに基づいて結論を出すことができると判断しました。システムは機能し、使用するのに大きな障害はありません。









4月22日に、さらに1000人のエンジニア向けに製品を展開しました。 少し遅れて、5月12日-次の300-400まで。 その後の各ウェーブアダプテーションは、前のパターンと同じパターンに従って行われ、現在、4000人のWindowsエンジニアのうち3500人がGitに切り替えました。 残りのチームは現在、プロジェクトを完了させており、移行に最適な時期を決定しようとしていますが、月末までにすべての従業員がカバーされると思います。



システムが使用するデータの量は膨大です。 特定の数字を見てみましょう。

• 合計で、リポジトリが存在してから4か月間で、250,000を超えるGitコミットがコミットされました。
• 1日あたり8,421回のプッシュ。
• 平均して1営業日あたり2,500件のプルリクエストと6,600件のコード検査。
• 4,352のアクティブなブランチ。
• 1日あたり1,760個の公式ビルド。

ご覧のとおり、これは非常に広範なコードベースでの膨大な数の操作です。

大規模プロジェクトでの作業時のGVFSパフォーマンス

調査結果によると、すべての人が現状に満足しているわけではありません。 このテーマに関する多くのデータを収集しましたが、その理由は非常に異なります。すべてのツールがGitをサポートしているわけではないという事実から、新しいことを学ばなければならないという悔しさまで。 しかし、主な問題はパフォーマンスであり、徹底的に解析したいと思います。 Gitを展開するとき、パフォーマンスの観点からはまだ未完成であることがわかり、実装プロセスで多くのことを学びました。 多くの主要な操作のパフォーマンスを追跡します。 GVFSを使用する3,500人のエンジニアの作業でテレメトリーシステムが収集したデータを以下に示します。









ここに「目標」が表示されています（許容値の中で最悪の値として計算しました-目標ではなく、システムがまったく機能しないようにしきい値を下回ることはできません）。 また、過去7日間の80パーセンタイルの結果と前週の結果との差も示されています。 （ご覧のとおり、すべてが遅くなっています。これについては後で詳しく説明します）。



比較するために、これを言います。「クラシックGit」で作業を始める前に同様のことを行おうとした場合、コマンドの多くは30分から数時間実行され、一部は実行されません。最後に達しました。 ほとんどが20秒以下で処理されるようになったことは大きな前進です。ただし、一定の10〜15秒の待機間隔では確かに良いことはありません。



プロジェクトを展開したばかりのとき、結果はずっと良くなりました。 これは私たちの主な発見の1つになりました。 GFVSの概要を紹介する紹介記事を読むと、リポジトリ内のファイルの総数ではなく、「読み取り」ファイルの数に比例する多数の操作を行うためにGitとGVFSに取り組んだ方法について説明しています。 時間が経つにつれて、エンジニアはコードベースを巡回し、ますます多くのファイルに触れるようになり、これが「過剰な水分補給」と呼ばれる問題につながります。 その結果、誰かが一度触れたファイルの束がありますが、その後は使用せず、間違いなく変更を加えませんでした。 その結果、パフォーマンスが低下します。 エントリリストは「クリーンアップ」できますが、これは余分な混乱であり、誰もそれを行わず、システムの動作が遅くなり、遅くなります。



これにより、「O（modified）」と呼ばれるパフォーマンスを改善する次の一連の変更を強制的に実行し、多くのキーコマンドを変更し、変更されたファイルの数に比例させます（まだコミットされていない変更があるという意味で）。 その週にこれらの変更をメインバージョンに追加するため、まだ静的データはありませんが、パイロットバージョンのテストでは良い結果が得られました。



まだすべての値がありませんが、たとえば上の表からいくつかのフィールドを選択し、O（水和）列に対応する数字を挿入しました。 追加されたO（変更済み）列では、最適化されたバージョンを使用して同じコマンドで得られた結果を提示しました。これは来週公開されます。 ここと秒の測定単位。 全体的に見ても全体的に見ても明らかな進歩が見られます。どこかで速度がわずかに増加し、どこかで-2倍、どこでも-5倍になりました。 これらの改善には大きな期待があり、ユーザーエクスペリエンスを定性的に変えることを期待しています。 私は完全に満足していません（ステータスが1秒未満になるまで落ち着きません）が、それでも大きな進歩を遂げています。









前の投稿で触れなかったパフォーマンスのもう1つの重要な領域は、チームの地理的分布です。 Windowsエンジニアは、米国、ヨーロッパ、中央アジア、インド、中国など世界中に散らばっています。 多くの場合、理想からかけ離れた帯域幅で、長距離にわたって大量のデータをプルすることは深刻な問題です。 これに対処するために、Git for GVFSでプロキシソリューションを作成しました。これにより、出力でGitのデータをキャッシュできます。 また、プロキシを使用して、Visual Studio Team Servicesのメインサービスから非常に大量のトラフィック（ビルドサーバーなど）をアンロードし、負荷が最大の時間でもユーザーエクスペリエンスが損なわれないようにしました。 合計で、世界中に20のGitプロキシがあります（ちなみに、これは単に既存のTeam Foundation Server Proxyに組み込まれています）。



これによる効果をよりよく理解するために、例を挙げましょう。 Windows Team Servicesアカウントは、米国西海岸のAzureデータセンターにあります。 上記で指摘したように、Windowsエンジニアの場合、80パーセンタイルクローニング操作には127秒かかります。 ほとんどのエンジニアはレドモンドで働いているため、この値は主に彼らに関連しています。 ノースカロライナのオフィスでテストを実施しました。このオフィスは、センターからさらに離れており、帯域幅が少なくなっています。 プロキシなしでは、同じ操作に約25分かかりました。 構成および更新されたプロキシにより、時間は70秒に短縮されました（つまり、レドモンドブランチよりも高速です。チームはそこでプロキシを使用せず、数百マイルのインターネットケーブルをAzureから分離しています）。 70秒対25分は、ほぼ95％の改善です。



一般に、GVFSを備えたGitはすぐに使用でき、信じられないほどの規模のプロジェクトに適用できます。 結果は、エンジニアの生産性が損なわれないことを示しています。 ただし、システムが改善されるまでにはまだ多くの作業が必要なので、従業員は満足しています。 O（変更済み）で行われる作業（来週公開予定）は、この方向への大きな一歩になりますが、必要なすべてが行われたと良心をもって言うには、さらに数か月の追加の改善が必要です。



Gitのスケールアップと良好なレベルのパフォーマンスの確保で発生した技術的な問題について詳しく知りたい場合は、Saeed NoursalehiのGitとGVFSのスケーリングに関する一連の記事をお勧めします 。 非常にエキサイティングな読書。

自分でGVFSを試してください

GVFSはオープンソースプロジェクトであり、私たちはすべての人にそれを試してみることを勧めます。 必要なのは、それをダウンロードしてインストールし、Gitリポジトリを使用してVisual Studio Team Servicesにアカウントを作成するだけです。その後、続行できます。 GVFSの最初の公開以来、私たちは大きな進歩を遂げました。 最も重要な変更点は次のとおりです。



1.コードベースの定期的な更新を開始し、徐々に「オープン」な開発モデルに移行しました。 現時点では、すべての最新の変更（O（変更済み）に対して行われたすべてを含む）が公開されており、今後定期的に更新をダウンロードする予定です。



2.最初の公開時点では、サードパーティの開発者からの入力を受け入れる準備ができていませんでした。 今日、私たちはこの慣行に対してオープンであると公式に宣言できる段階に達しました。 基本的なインフラストラクチャはすでに十分に確立されており、人々がそれを利用して開発する機会を与えているようです。 誰かが接続して支援したい場合、私たちは幸せになります。



3. GVFSは、GVFltと呼ばれるWindowsファイルシステムに依存しています。 これまで、アクセスを提供したドライバーは署名されていませんでした（まだ作業中だったため）。 明らかに、これはそれを試してみたい人の生活を非常に複雑にしました。 GVFltの署名バージョンをリリースしました。これにより、すべての粗さが解消されました（したがって、インストールのためにBitLockerを無効にする必要はなくなりました）。 ただし、署名済みのGVFltドライバーはありますが、これは一時的な解決策にすぎません。 Windowsの将来のバージョンに適切な機能を実装する予定であり、現在詳細に取り組んでいます。



4. Git Mergeカンファレンスで講演した後、Gitのスケーリングのニュアンス、特にGVFSについて、このトピックに関心のある幅広い専門家と積極的に議論し始めました。 同じ困難に直面している他の大企業（Google、Facebook）と非常に生産的に話し合い、経験とアプローチを共有し始めました。 また、いくつかの人気のあるGitクライアントと連携して、GVFSとの互換性を確保しました。 これらに含まれるもの：

• Atlassian SourceTree-SourceTreeは、GVFS互換性について検証された最初のツールでした。 よりスムーズなワークフローのためにいくつかの変更が導入されたアップデートがすでにリリースされています。
• Tower-Towerチームは、WindowsバージョンのアプリケーションへのGVFSサポートの追加に取り組んでいると発表しました。 近い将来、対応する機能は無料のアップデートで利用可能になります。
• Visual Studio-単独で、私たち自身のVisual Studio GitがGVFSで正常に動作した場合、それは素晴らしいでしょう。 バージョン2017.3でGVFSサポートを実装します。その最初のプレビュー（サポートに必要なものすべてを含む）は6月上旬にリリースされます。
• Git on Windows-Gitのスケールアップの取り組みの一環として、GVFSのサポートを含む、Windows上のGit（たとえば、Gitコマンドライン）にいくつかの変更を加えました。 これで、Git上のWindows用の特別なブランチを作成しましたが、時間の経過とともに、すべてをメインバージョンのコードに移行したいと思います。

上記の要約

Microsoftの大規模なチームと大規模なコードベースに合わせて、Gitのスケーリングに引き続き取り組んでいきます。 3か月前にこのプロジェクトについて話し始めて以来、多くのことが起こりました。 特に、私たちは：

• 3,500人のエンジニア向けのプロジェクトの実装に成功しました。
• 接続されたプロキシと生産性の向上。
• オープンソースコードを更新し、他のユーザーに編集/貢献の機会を与えました。
• サービスを使いやすくするために、署名されたGVFltドライバーを提供しました。
• SourceTree、Tower、Visual Studioなど、一般的なツールでサポートを実装するために他のチームと協力し始めました。
• 技術的な観点から、 GitとGVFSのスケーリングへのアプローチが詳細に議論されているいくつかの記事を公開しました。

これはマイクロソフトにとってエキサイティングな経験であり、私のチームとWindowsチームにとって重大な挑戦でした。 私たちがすでに達成したことは嬉しいですが、まだ残っている仕事の量を過小評価するつもりはありません。 非常に大規模なコードベースで作業しなければならないが、心を込めてGitに切り替えたいという状況によく気づく場合は、GVFSを試してみることをお勧めします。 現時点では、Visual Studioは、すべての革新的なGVFSプロトコルをサポートする唯一のバックエンドソリューションです。 将来、プロジェクトに需要がある場合は、Team Foundation ServerでもGVFSのサポートを追加します。 また、他のGitサービスとも交渉しました。Gitサービスの作成者は、将来互換性を確保する可能性を検討しています。