Git の次に来るものは

Gitの次に来るものは何か

East River Source Controlは1年以上前から存在していますが、私たちはこれまで公に作業内容についてあまり語ってきませんでした。まだ何も発表するわけではありませんが、まもなく発表します。しかし、バージョン管理とその将来について、私たちの考えを共有したいと思います。

ソフトウェア開発は変化した

ソフトウェア開発は本質的に共同作業です。プロジェクトはささやかな始まりから、信じられないほど大規模で複雑なシステムへと成長します。しかし、cargo newが生成するものと、数十億行のモノレポに含まれるものは同じ、ソースコードです。このコードを安全かつ確実に保存し、時間の経過とともにどのように変更されるかを管理し、開発者が利用できることを保証することは、あらゆるテクノロジー組織の最も重要な機能の一部です。

昔は、コードが置かれている共有サーバーがあったかもしれません。学術界、そして産業界は、現在ソース管理システム（SCM）およびバージョン管理システム（VCS）と呼ばれるものを開発しました。VCSの分野でさえ、長年にわたり多くのツールを見てきました。CVS、SVN、Gitはオープンソース分野を支配したツールですが、他にも多くのツールがありました。Perforce、ClearCase、Fossil、Mercurial、SCSS、Monotone、BitKeeperなど、その他多数です。これらのツールは、コードを保存し、チームが変更を共同で行うための標準的な方法となりました。

エージェント開発の台頭は、ソフトウェア開発の方法に多くの変化をもたらしましたが、バージョン管理システムに特に負担をかけています。チームはかつてないほど迅速に、より多くのコードを生成しており、リポジトリサイズは肥大化し、アクティブなブランチの数は増加し、新しい作業のマージで大きな競合が生じています。エージェントはモノレポとうまく連携します。なぜなら、より多くのコンテキストに、より簡単にアクセスできるからです。これにより、これらの問題はさらに悪化します。開発環境をクラウドに移行し、分離された環境を使用しているため、高速なクローン時間が必要になります。これらの問題はかつて大企業だけの領域でしたが、エージェントは私たち全員に大企業の問題をもたらしています。

私たちは、組織が野心をスケールアップし続けるにつれて、次世代のVCSツールが必要になると信じています。しかし、この分野で新しいツールを採用することには、当然ながらある程度の保守性があります。前述したように、ソースコードは組織が持つ最も貴重な資産の一つであり、変更にはリスクと報酬の両方があります。私たちはこれらの懸念を深く理解しており、現在から未来への橋を架けています。

ストレージは基盤

多くのGitサーバーは存在しますが、何が私たちを特別にしているのでしょうか？

大まかに言うと、ほとんどのGitリポジトリホスティングサービスは次のような仕組みになっています。

サーバー
  Gitプロトコル
  Gitクライアント
  Gitサービングレイヤー
  Gitリポジトリストレージ

ほとんどのGitホストの構築方法

• サーバー：Gitサービングレイヤー、Gitリポジトリストレージ
• Gitサービングレイヤー → Gitリポジトリストレージ
• Gitクライアント → Gitサービングレイヤー：Gitプロトコル

あなたのgitクライアントは、Gitプロトコルを介してサービスに接続します。サービス内部では、リポジトリはディスクに保存され、それらを接続するサービスレイヤーがあります。

これは少し単純化しすぎています。実際には多くのサーバーと、リポジトリの前面にある複雑なサービスレイヤーが存在します。ストレージは複製され、さまざまな処理が行われています。ここでは全体的なアーキテクチャに焦点を当てていますが、図の単純さをシステムの単純さと混同しないでください。ここでは多くのことが行われていますが、現時点ではそれらの詳細は重要ではありません。

その精神で、私たちの仕組みの図を示します。

サーバー
  Gitプロトコル
  Gitクライアント
  Gitブリッジ
  非Gitストレージエンジン

ERSCの構築方法

• サーバー：Gitブリッジ、非Gitストレージエンジン
• Gitブリッジ → 非Gitストレージエンジン
• Gitクライアント → Gitブリッジ：Gitプロトコル

見た目はかなり似ています！これも単純化されています。例えば、図には表示されていませんが、GraphQL APIインターフェースもあります。しかし、違いは重要です。通常のgitクライアントで私たちのストレージに接続し、Gitプロトコルを使用する点は同じですが、サーバーにGitリポジトリを保存しているわけではありません。代わりに、カスタムストレージエンジンを持っています。

Gitは未来のために作られていない

率直に言って、私たちはGitがソース管理の未来だとは考えていません。Gitは何年もの間開発者に役立ってきましたが、2025年、ましてや2035年ではなく、2005年の制約に基づいて設計されました。例えば、Linuxカーネルのために構築されました。オープンソースは私たちの業界にとって信じられないほど重要ですが、これは、コードをすべての人と共有しない組織にとって有用な主要機能が欠けていることを意味します。また、Linuxカーネルは小さなリポジトリではありませんが、約4300万行のコードで7.2に達していますが、業界の主要企業は数年前にすでに数十億行のコードで測定されるモノレポを持っていました。この規模では、選択が本当に重要になります。

同時に、別のバージョン管理システムの使用を検討するのは困難です。Gitは私たちのツールの多くに組み込まれています。それはSvnOpsではなく、GitOpsです！非常に多くのものがGitを話すため、代替手段を検討するのは困難です。Gitが作成されたとき、MercurialやBazaarなど、いくつかの他のプロジェクトが同時に開始されました。しかし、ネットワーク効果により、Gitは事実上すべての人によって使用されるようになりました。

では、どうすればよいでしょうか？Gitプロトコルを話しながら、ストレージレイヤーの仕組みを変更します。これは将来のすべての問題を解決するわけではありませんが、役立ちます。私たちのシステムは、Gitリポジトリを真実の源とするシステムとは異なり、水平方向にスケーラブルです。そして、これはグローバルで統一されたプラットフォームではないため、他の企業の利用はあなたに影響しません。それらは個別のデプロイメントだからです。これにより、信頼性と制御が得られます。これらはインフラストラクチャについて話す際に重要なことです。

採用のためのエンジニアリング

では、将来の可能性はどうでしょうか？Gitプロトコルが提供するものを超えてスケールする必要がある場合、またはGitが提供しない機能が必要な場合はどうでしょうか？このプロトコルを話す戦略には利点があります。複数のプロトコルを話すことができます。

ここでJujutsuが登場します。私たちはERSCでjjの大ファンであり、その一部として、段階的に採用しやすいテクノロジーの例であるjjが大好きです。jjは独自のバージョン管理システムですが、複数の異なるバックエンドと通信する能力があります。ほとんどの開発者は、ローカルのGitリポジトリと直接連携するためにGitバックエンドでjjを使用しますが、Googleは独自のPiperバージョン管理システム用のバックエンドも持っています。これにより、個々の開発者は職場でjjを使用することを選択できます。たとえ同僚がまだ通常のGitクライアントを使用している場合でも、サーバーにとっては、Gitプロトコルの別のユーザーにすぎません。私たちはこの戦略をサーバー側でミラーリングします。

サーバー
  Gitプロトコル
  Gitクライアント
  Gitブリッジ
  ネイティブプロトコル（将来）

  Gitプロトコル
  jjクライアント
  Gitブリッジ
  ネイティブプロトコルブリッジ（将来）
  非Gitストレージエンジン

1つのストレージエンジンで2つのプロトコル

• サーバー：Gitブリッジ、ネイティブプロトコルブリッジ（将来）、非Gitストレージエンジン
• Gitブリッジ → 非Gitストレージエンジン
• ネイティブプロトコルブリッジ（将来） → 非Gitストレージエンジン
• Gitクライアント → Gitブリッジ：Gitプロトコル
• jjクライアント → Gitブリッジ：Gitプロトコル
• jjクライアント → ネイティブプロトコルブリッジ（将来）：ネイティブプロトコル（将来）

これにより、バージョン管理の未来へのスムーズな道が開かれます。通常の古いgitを使用して、信頼性が高くスケーラブルなソース管理を利用することから始めることができます。個々の開発者は自分のペースでjjを採用することを選択でき、準備ができたときにjjは同じ基盤となるエンジンに対して異なるプロトコルを話すことができます。

これに関する重要な注意点：これは将来の作業であり、まだ利用できません。アップストリームには、今日の「jjネイティブ」プロトコルはありません。そして、これが私たちが構築しているものだと主張するつもりはありません。これがアップストリームがサポートしたいアップストリームの機能として有用であれば、コミュニティと協力します。プロトコルは十分に文書化され、それをサポートするためのクライアントの変更はオープンソースになります。私たちがそのようなものを作成したからといって、アップストリームがそれを使用したいと思うとは限りません。Gitプロトコルは、今日のほとんどのユーザーのニーズを満たすために機能しているからです。私たちは、それが最終的にどのようになるかにかかわらず、jjエコシステムの良いプレイヤーであり続けることを約束します。

最初の多くのピースの1つ

ストレージソリューションは、チームがコードを中心に共同作業するために必要なすべての一部にすぎません。コードレビュー、CI、課題追跡など、リストは延々と続きます。従来のソフトウェアフォージはすべてを1つの統合されたパッケージで提供してきましたが、私たちはソフトウェアのカスタマイズ性が高まる時代に入っていると信じています。そのため、私たちの製品提供は、単一のフォージというよりは、ビルディングブロックのようになります。ストレージは基盤であり、したがって、最初に登場します。しかし、私たちのストレージソリューションが、あなたのソフトウェアスタックの残り全体と連携するようにしたいと考えています。私たちはVCS分野で複数の製品を提供しますが、スタックの残りの部分のために独自のソフトウェアを持参したい場合は、それを行うことができます。または、私たちのファーストパーティのコンポーネントの一部を採用し、独自のコンポーネントの一部を持参したい場合でも、それは素晴らしいことです。

これらはまだ利用できませんが、まもなく公開します。それまでの間、来週のJJ Conでお会いしましょう！