Git の次に来るものは

East River Source Control は1年以上前から存在していますが、私たちが何に取り組んできたかについてはあまり公に話していませんでした。まだ何も発表するわけではありませんが、間もなく発表します。しかし、バージョン管理に関する私たちの考えと、今後の方向性について共有したいと思います。 ソフトウェア開発は今や異なります ソフトウェア開発は根本的に共同作業です。プロジェクトはささやかな始まりから始まり、信じられないほど巨大で複雑なシステムへと成長します。しかし、Cargoが生成するものは、数十億行のモノレポに含まれるものと同じです。ソースコードです。このコードを安全かつ確実に保存し、時間の経過とともにどのように変更されるかを管理し、開発者が利用できるようにすることは、あらゆるテクノロジー組織の最も重要な機能の一部です。 昔は、コードが置かれている共有サーバーがあったかもしれません。学術界、そして産業界は、現在ソース管理（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ストレージエンジン ERSCの構築方法 pretty similar looks! It is also simplified, for example, there is a GraphQL API interface not shown in this diagram at all. But the difference is important: while you still connect to our storage with your regular git client and it uses the git protocol, we don’t store git repositories on our servers. Instead, we have a custom storage engine. それは似ています！単純化しすぎている部分もあります。例えば、この図には表示されていないGraphQL APIインターフェースがあります。しかし、違いは重要です。通常のGitクライアントでストレージに接続し、Gitプロトコルを使用しても、サーバーにGitリポジトリを保存しません。代わりに、カスタムストレージエンジンを使用しています。 Gitは未来のために作られていない 率直に言って、私たちはGitがソース管理の未来であるとは考えていません。Gitは何年も開発者に役立ってきましたが、2025年、ましてや2035年ではなく、2005年の制約に基づいて設計されました。例えば、Linuxカーネルのために作られました。オープンソースは私たちの業界にとって信じられないほど重要ですが、これはオープンソースではない組織にとって便利な主要機能が欠けていることを意味します。また、Linuxカーネルは小さなリポジトリではありませんが、7.2で約4300万行のコードがありますが、業界の主要企業は数年前にすでに数十億行のコードで測定されるモノレポを持っていました。この規模では、選択は本当に重要です。 同時に、別のバージョン管理システムの使用を検討するのは困難です。Gitは私たちのツールの多くに組み込まれています。それはGitOpsであり、SvnOpsではありません！多くのものが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クライアント jjクライアント Gitブリッジ ネイティブプロトコルブリッジ（将来） 非Gitストレージエンジン 1つのストレージエンジンで2つのプロトコル これはバージョン管理の未来へのスムーズな道を開きます。通常の古いGitから始めて、信頼性が高くスケーラブルなソース管理管理を楽しむことができます。個々の開発者は自分のペースでjjを採用することを選択でき、準備ができたときにjjは同じ基盤エンジンに対して別のプロトコルを話すことができます。 これに関する重要な注意点：これは将来の作業であり、まだ利用できません。アップストリームには今日「jjネイティブ」プロトコルはなく、私たちがそれを構築していると主張するものではありません。これがアップストリームがサポートしたいアップストリームの機能として有用であれば、コミュニティと協力して取り組みます。そして、プロトコルは十分に文書化され、それをサポートするためのクライアントの変更はオープンソースになります。私たちがそのようなものを作成したからといって、アップストリームがそれを使用したいと想定するわけではありません。Gitプロトコルは、今日のほとんどのユーザーのニーズを満たすために機能しています。私たちは、それが最終的にどのようになるにしても、jjエコシステムで良いプレイヤーになることにコミットしています。 多くのピースの最初の1つ ストレージソリューションは、チームがコードを中心に共同作業するために必要なすべての一部にすぎません。コードレビュー、CI、課題追跡など、リストは続きます。従来のソフトウェアフォージはすべてを1つの統合されたパッケージで提供してきましたが、私たちはソフトウェアのカスタマイズ性が高まる時代に入っていると信じています。そのため、私たちの製品は...