gitでは、ダースのライブラリのバージョニングを行う方法がすべて並行して動作しました

私たちはプロジェクトを行っていますが、プロジェクト間で多くのコードを再利用し、共通のコードを含むライブラリをたくさん持っています。新しいプロジェクトを実装するにつれて、一般的なコードを抽出してライブラリに追加する方法が増えています。ライブラリは互いに依存し、プロジェクトはライブラリに依存します。各プロジェクト、およびそのプロジェクトで使用されるすべてのライブラリは、参照しているすべてのライブラリの同じバージョンを使用する必要があります。ソフトウェアをリリースする場合、バグを修正する必要があり、長年、場合によっては数十年にわたって新しい機能を追加する必要があるかもしれません。約12のライブラリがあり、変更は多くの場合2つ以上にまたがり、複数のチームが複数のプロジェクトを並行して作業し、これらすべてのライブラリに同時に変更を加えます。

最近、gitに切り替えて、各ライブラリおよび各プロジェクトのリポジトリを設定しました。stashを共通のリポジトリとして使用し、機能ブランチで新しい作業を行い、プルリクエストを作成し、レビュー後にのみそれらをマージします。

プロジェクトで対処しなければならない問題の多くは、いくつかのライブラリとプロジェクト固有のコードを変更する必要があります。多くの場合、ライブラリインターフェイスの変更が含まれますが、その一部には互換性がありません。（これが怪しいと思うなら、私たちはハードウェアとインターフェイスし、特定のハードウェアを汎用インターフェイスの後ろに隠します。他のベンダーのハードウェアを統合するたびに、現在のインターフェイスが予期しなかったケースに遭遇するため、それらを改良する必要があります。）たとえば、プロジェクトを想像しP1たライブラリを使用してL1、L2とL3。L1また、使用していますL2とL3、とL2用途L3にも。依存関係グラフは次のようになります。

   <-------L1<--+
P1 <----+  ^    |
   <-+  |  |    |
     |  +--L2   |
     |     ^    |
     |     |    |
     +-----L3---+

ここで、このプロジェクトの機能に変更が必要でP1ありL3、のインターフェースを変更することを想像してくださいL3。これらのライブラリを参照するプロジェクトP2をP3ミックスに追加します。それらをすべて新しいインターフェイスに切り替え、すべてのテストを実行し、新しいソフトウェアを展開する余裕はありません。それでは、代替手段は何ですか？

1. 新しいインターフェースを実装する L3
2. プルリクエストをL3してレビューを待ちます
3. 変更をマージする
4. の新しいリリースを作成する L3
5. の新しいリリースをP1参照することで機能の作業を開始し、機能のブランチにL3機能を実装しますP1
6. プルリクエストを行い、これをレビューして、マージします

（私はちょうど私がスイッチに忘れたことに気づいたL1とL2新しいリリースに。そしてそれはと並行して行われる必要があるので、私も、どこでこれを固執するかわかりませんP1...）

これは、この機能を実装するための退屈でエラーが発生しやすい非常に長いプロセスであり、独立したレビューが必要であり（レビューがはるかに困難になります）、スケーリングがまったく行われず、私たちがビジネスを停止する可能性がありますプロセスが行き詰まってしまい、何もできなくなります。

しかし、あまり多くのオーバーヘッドなしで新しいプロジェクトに新しい機能を実装できるプロセスを作成するために、どのように分岐とタグ付けを使用するのでしょうか？

ここで明らかなことを言うようなものですが、言及する価値があるかもしれません。

通常、gitリポジトリは独立している傾向があるため、lib / projectごとに調整されます。プロジェクトを更新しますが、残りは気にしません。それに依存する他のプロジェクトは、適切と思われる場合はいつでもライブラリを更新するだけです。

ただし、ケースは相関コンポーネントに大きく依存しているようであるため、通常は1つの機能がそれらの多くに影響します。そして、全体をバンドルとしてパッケージ化する必要があります。機能/変更/バグを実装するには、多くの異なるライブラリ/プロジェクトを一度に適合させる必要があることが多いため、すべてを同じリポジトリに配置するのが理にかなっています。

これには強力な利点/欠点があります。

利点：

• 追跡可能性：ブランチには、この機能/バグに関連するすべてのプロジェクト/ライブラリで変更されたすべてが表示されます。
• バンドル：タグを選択するだけで、すべてのソースを正しく取得できます。

欠点：

• マージ：...単一のプロジェクトでは既に難しい場合があります。さまざまなチームが共有ブランチで作業しているため、影響に備えて準備を整えてください。
• 危険な「おっと」要因：ある従業員が何らかの間違いをしてリポジトリを台無しにした場合、すべてのプロジェクトとチームに影響を与える可能性があります。

価格にメリットがあるかどうかを知るのはあなた次第です。

編集：

次のように機能します。

• 機能Xを実装する必要があります
• ブランチを作成 feature_x
• 関係するすべての開発者はこのブランチで作業し、おそらくプロジェクト/ライブラリに関連する専用ディレクトリで作業します
• 終わったら、レビュー、テスト、パッケージ化、何でも
• バックマスターでそれをマージ...、これは以来、その間にタフな一部であってもよいfeature_yし、feature_zあまりにも追加されている可能性があります。「クロスチーム」マージになります。これが重大な欠点である理由です。

記録のためだけに：ほとんどの場合、これは悪い考えであり、マージの欠点は通常、依存関係管理/適切な機能の追跡を通じて得られるものよりも大きいため、慎重に行う必要があると思います。

探しているソリューションは、gitサブモジュールと連携した依存関係管理ツールです

次のようなツール：

• メイヴン
• 蟻
• 作曲

これらのツールを使用して、プロジェクトの依存関係を定義できます。

サブモジュールは、少なくともバージョン> 2.xx以上であるか、互換性のあるバージョン範囲= 2.2。*または特定のバージョン<2.2.3未満であることを示すことができます。

パッケージの1つの新しいバージョンをリリースするたびに、バージョン番号でタグを付けることができ、その方法で特定のバージョンのコードを他のすべてのプロジェクトに取り込むことができます

サブモジュール

1つのコメントで示唆されているように、サブモジュールをgitにトライする必要があります。

project P1が3つのサブモジュールを参照する場合L1、L2およびL3は、実際に3つのリポジトリすべてに特定のコミットへの参照を保存します。これらは、そのプロジェクトの各ライブラリの作業バージョンです。

したがって、複数のプロジェクトで複数のサブモジュールを使用できます。プロジェクトが新しいバージョンを使用している間にP1、ライブラリの古いバージョンを参照する場合があります。L1P2

新しいバージョンを配信するとどうなりますL3か？

• 新しいインターフェースを実装する L3
• コミット、テスト、プル要求の作成、レビュー、マージ、...（これを避けることはできません）
• 確保L2作品でL3、コミット...
• L1新しいL2で動作するようにします...
• P1すべてのライブラリの新しいバージョンで動作することを確認します。
  • の内部P1のローカル作業コピーL1、L2およびL3、興味のある変更を取得します。
  • 変更git add L1 L2 L3をコミットし、モジュールへの新しい参照をコミットします
  • プルリクエストP1、テスト、レビュー、プルリクエスト、マージ...

方法論

これは、この機能を実装するための退屈でエラーが発生しやすい非常に長いプロセスであり、独立したレビューが必要であり（レビューがはるかに困難になります）、スケーリングがまったく行われず、私たちがビジネスを停止する可能性がありますプロセスが行き詰まってしまい、何もできなくなります。

はい、変更するため、独立したレビューが必要です。

• 図書館
• それに依存するライブラリ
• 複数のライブラリに依存するプロジェクト

あなたががらくたを出すので、あなたは廃業するでしょうか？（実際にはそうではないかもしれません）。はいの場合、テストを実行して変更を確認する必要があります。

適切なgitツール（偶数gitk）を使用すると、各プロジェクトが使用しているライブラリのバージョンを簡単に確認でき、ニーズに応じてそれらを個別に更新できます。サブモジュールは状況に最適であり、プロセスを遅くすることはありません。

このプロセスの一部を自動化する方法を見つけることができるかもしれませんが、上記の手順のほとんどは人間の脳を必要とします。時間を短縮する最も効果的な方法は、ライブラリとプロジェクトを簡単に進化させることです。コードベースが新しい要件を適切に処理できる場合、コードレビューはより簡単になり、時間はほとんどかかりません。

（編集） 関連するコードレビューをグループ化することも役立ちます。すべての変更をコミットし、それらの変更を使用するすべてのライブラリとプロジェクトにそれらの変更が伝達されるまで待ってから、プル要求をまとめます（またはそれらを処理する前に）。最終的には、依存関係チェーン全体についてより大きなレビューを行うことになります。たぶん、これは各ローカルの変更が小さい場合に時間を節約するのに役立ちます。

だから私が理解しているのは、L3インターフェイスを変更したいが、L3インターフェイスに依存する他のP2とP3をすぐに変更したいP1の場合です。これは、下位互換性の典型的なケースです。この下位互換性の保持に関する素晴らしい記事があります

これを解決する方法はいくつかあります。

• 古いインターフェイスを拡張できる新しいインターフェイスを毎回作成する必要があります。

または

• しばらくして古いインターフェイスを廃止する場合は、いくつかのバージョンのインターフェイスを使用し、すべての依存プロジェクトが移動したら古いインターフェイスを削除します。

私があなたの問題を正しく理解している場合：

• あなたは4つの相互関連モジュール、P1とL1からL3を持っています
• 最終的にL1からL3に影響するP1に変更を加える必要があります
• 4つすべてを一緒に変更する必要がある場合、プロセスの失敗としてカウントされます。
• それらをすべて1つずつ変更する必要がある場合、プロセスの失敗としてカウントされます。
• 変更を加える必要があるチャンクを事前に識別する必要がある場合、プロセスの失敗としてカウントされます。

目標は、P1とL1を一度に実行し、1か月後に別のL2とL3を実行できるようにすることです。

Javaの世界では、これは簡単であり、おそらくデフォルトの動作方法です。

• 関連する分岐の使用なしですべてが1つのリポジトリに格納されます
• モジュールは、すべて同じディレクトリツリーにあるという事実ではなく、バージョン番号に基づいてmavenによってコンパイル+リンクされます。

したがって、L3のローカルディスクに、ディスク上の他のディレクトリにあるP1のコピーに対してコンパイルした場合にコンパイルされないコードを保持できます。幸いなことにそうではありません。物語のコンパイル/リンクはソースコードではなくコンパイルされたjarファイルに対して行われるため、Javaはこれを簡単に行うことができます。

私は、C / C ++の世界でこの問題に対する既存の広く使用されている解決策を知らないので、言語を切り替えたいとは思わないでしょう。しかし、同等のことをするmakeファイルで何かを簡単にハッキングできます。

• インストールされたライブラリ+埋め込みバージョン番号を持つ既知のディレクトリへのヘッダー
• 適切なバージョン番号のディレクトリへのモジュールごとのコンパイラパスの変更

ほとんどのC開発者は、もしそうなら奇妙にあなたを見ますが、あなたはmavenでC / C ++サポートを使用することさえできます...

単純な解決策があります。リポジトリ全体でリリースブランチをカットし、すべての修正をアクティブに出荷されたすべてのリリースにマージします（gitでは簡単にクリアできるはずです）。

すべての選択肢は、時間の経過とともにプロジェクトの成長とともに恐ろしい混乱を生み出します。