共有ライブラリの分岐およびバージョン管理戦略
これら投稿 関連しているように見えますが、私の脳は溶け始めており、：P
私の雇用主は、ソース管理の使用を始めたばかりです。主な理由は、より多くの開発者を雇う前は、「リポジトリ」は、主に自宅で作業している唯一の開発者のハードドライブだったからです。彼が書いたすべての.NETコードはen masseでチェックインされ、複製（読み取り：コピー貼り付け）機能がたくさんあります。現在、私たちのSCMシステムは栄光のバックアップです。
重複したコードの一部を共有ライブラリにプルしたいのですが。元のリポジトリはそのままにしておき、何も壊さないようにします。必要に応じて、既存のコードを移動またはリファクタリングできます。そこで、ライブラリを含む新しいコードのためにリポジトリを設定しました。
私の問題は、過度のプロセスで私たちを惑わすことなくライブラリのバージョン管理を中心に展開します。より一貫性のあるアプローチが必要であることを認め、より多くの開発者が非常に類似したコードを記述し、管理および他の開発者が物事を再編成することにオープンですが、おそらくそれは不可能ですソリューションが生産性に影響を及ぼし始めたら、十分に下げます。
私の強迫観念における理想的な解決策は、ライブラリを個別にビルドすることです。各依存プロジェクトは、意図的に選択された互換バージョンのライブラリに対してビルドされます。このようにして、どのクライアントがどのライブラリのどのバージョンを持っているかを正確に把握し、バグをより確実に再現し、製品とライブラリの独立したリリースブランチを維持し、共有コードを変更するときに互いのプロジェクトを壊さないようにします。
ただし、これにより、特に自宅で作業する開発者にとって、ライブラリの更新が面倒になります。少なくとも最初は（最終的に）共通ビットをまとめるので、ライブラリはすぐに変更されることを期待しています。私がこれを完全に考えすぎている可能性は十分あり、最新のライブラリコミットに対してすべてをビルドするだけで問題ありませんが、少なくとも準備をしたいです一部のコンポーネントは個別にバージョン管理および配布する必要があると判断した日。一部のライブラリをGACにインストールする必要があるため、バージョン管理が特に重要になります。
だから私の質問は：何が欠けているのですか？私は1つのソリューションにこだわり、今では変更をよりスムーズにするバリエーションを見つけようとしています。この種の問題を解決するために、どのような戦略を以前に使用しましたか？この質問はいたるところにあります。不確実な点があれば片付け、明確にするために最善を尽くします。
そして、私がMercurialを使用したいのと同じくらい、私たちはすでに集中型の商用SCM（Vault）にお金を費やしており、切り替えはオプションではありません。さらに、ここでの問題は、バージョン管理ツールの選択よりも深いと思います。
あなたのイニシアチブを称賛します。これは、これを実装するときに、組織に多くのメリットをもたらすはずです。コードをコピーするのではなく、移動します。コピーがあると、互換性のない変更が発生し、解決する必要があります。
ライブラリが開発され、安定化されると、多少の痛みが生じます。それが完了すると、メリットが得られます。ライブラリへのインターフェースは、基本的に、コントラクトを操作するプロジェクトとのコントラクトであることを覚えておいてください。古いインターフェースが使用されているかどうかを判別できる可能性があるため、古いインターフェースを削除できるという利点があります。
ライブラリーは安定していますが、新しいライブラリーの取得は、おそらくコード更新プロセスの一部です。ライブラリ変更のコミットをスケジュールすることもできます。移動されるコードを発表すると、競合する変更を減らすのに役立つ場合があります。
ライブラリは個別のプロジェクトとして扱い、できるだけ早く安定させる必要があります。それらが安定したら（特にインターフェース）、変更を他のプロジェクトに統合するのが簡単になります。新しいライブラリは古いコードで動作するはずです。安定したライブラリリリースに独自のリリースIDでタグ付けします。サードパーティのライブラリと同じようにライブラリを扱うようにしてください。
プロジェクト間で共有されるコードは、それ自体でプロジェクトとして扱う必要があります。それらは、サードパーティのライブラリと同じように徹底的に処理する必要があります。他に方法はありません。
グループで共有コードの戦略を採用できない場合は、MercurialやGITなどの最新のソースコード管理ツールを使用して、自分で採用することができます。ただし、会社が正式に使用するSCMはどちらでもありません。少し注意すると、2つのSCMは、一方に他方の内部ファイルを無視するように指示するだけで、同じ作業ディレクトリを使用できます。 1つのSCMを使用して毎日を処理し、会社のSCMを使用して統合します。
いずれにせよ、他のプロジェクトが共有コードに対して行った変更で作業ディレクトリをいつ更新するかを担当する必要があります。これらは、発生する可能性のある非互換性に対処する準備ができている場合にのみ発生します。さもなければ、あなたの仕事は実行できないほど不安定になるかもしれません。
それらを別々の「モジュール」プロジェクトに分割する能力があれば、私はそのアプローチを取るでしょう。気になるのは、コードの結合です。 懸念の分離 を分割することで作成します。これは良い方法です。
いくつかの利点：
- 各モジュールのより簡単なデバッグ。
- ビルドサイクルの高速化（変更されていないライブラリの再ビルドなし）
- 何かがうまくいったら、そのモジュールの外側の別の領域を変更することでそれを壊す可能性は低くなります（100％ではありませんが、可能性は減ります）。
- 相互に依存する大きな混乱ではない場合、作業の割り当てを分割するのが簡単になります。
- 1つのライブラリを修正すると、小さな断片の配布が速くなります（.dll/.soファイルがある大きな理由）。
この部分について1つ質問があります。
「私の強迫観念における理想的な解決策は、ライブラリーを個別にビルドすることです。各依存プロジェクトは、意図的に選択された互換性のあるバージョンに対してビルドされます。」
プロジェクト全体を静的リンクしますか？もしそうなら、これは以下につながるでしょう：6.不要なコード膨張の減少。
いくつかの否定的事項：
- プロジェクトが小さい場合は、不要な場所に複雑さを追加するだけです。
- 大量のモジュールを分岐すると、非常に大規模なプロジェクトのメンテナンスの問題になる可能性があります。 「Vault」がわからないので、分岐操作の良し悪しはわかりません。
現時点では、1つのコードベースが一度に1つのターゲットにビルドされているようです。おそらく5人以下の開発者しかいません。ライブラリを分離することの有用性はあまりわかりません。ワークフローをコードから変更します->コンパイル->実行してコード->コンパイル->コピーDLL->コンパイル->実行...
一部の企業（GoogleおよびAmazon）には、開発のための十分なインフラストラクチャーがあり、個別に多数のライブラリーを構築するのはかなり簡単です。それを無痛にするインフラストラクチャには、SCM（おそらく持っている）に存在するライブラリバージョンを指定する方法、SCMに存在する依存バージョンを指定する方法、それを理解してすべてを適切にコンパイルできるビルドサーバーが含まれます。 、およびビルドサーバーとローカルワークスペースから適切なビルドアーティファクトを取得する方法。あなたはそれを持っていると思います。
そのインフラストラクチャがなければ、次のいずれかに該当する場合はプロジェクトを分離します。
- このライブラリに応じて、複数の製品または異なるアプリケーションがあります
- 一度に数日間、これらのライブラリで排他的に作業します
- ライブラリの機能は、ビジネス関連のもの（たとえば、プラットフォーム固有のAPIのラッパー）から非常に分離されています。
- 結合されたプロジェクトのビルド時間が大きくなりすぎます
多くのプロジェクトがあり、一部には専用の開発者と独立したリリースサイクルがある場合、そのインフラストラクチャの構築について心配します。
canとshouldで実行することは、信頼性が高く反復可能なビルド用のビルドサーバーをセットアップし、特定の実行可能ファイルからソースリビジョンを見つけられることを確認します。 .NETを使用しているようです。リビジョン番号を含むバージョン文字列を挿入するようにCruiseControl.NETを設定するのは非常に簡単です。
ビルドサーバーを作成したら、ライブラリを分割することは、ほとんどそれをVaultに移動し、CC.NETに別のターゲットを追加し、結果のDLLをメインプロジェクトのライブラリにコピーすることです。フォルダーを作成してコミットするSCM側では、日々の開発よりも簡単です。
Mercurialにはサブリポジトリと呼ばれる機能があります。私は最近これを読みました ブログ キルンから、それらがどのように機能するかを説明します。
基本的に、プロジェクトをライブラリリポジトリの特定のリビジョンにリンクします。依存プロジェクトを壊すことなく、ライブラリを好きなだけ更新できます。準備ができたら、ライブラリの新機能をプロジェクトに取り込んで、破損に対処できます。異なるプロジェクトはライブラリの異なるリビジョンにリンクできるため、それらすべてが同期して同じライブラリリビジョンを使用する必要はありません。
Vaultにも同様の機能があるのかもしれません。
SCの各モジュールにメタデータファイルを追加しました。これは、依存する他のすべてのモジュールの名前を示します。製品には、各依存モジュールのバージョンを示す2番目のメタデータファイルがあります。これに加えて、メタデータファイルを分析し、必要なモジュールをすべてチェックアウトし、IDEのプロジェクトを生成するためのツールがあります。
これにより、ビルドが常に再現可能であり、正しいヘッダーファイルが常にコンポーネント間で共有されます。必要に応じて、他の複雑さをさらに重ねることができます。 SCのすべての独立モジュールにわたって、変更されたソースファイル、チェックインコメント、バージョンコメント、作成者を指定して、製品の任意の2つのビルドの違いに関するレポートを生成できるツールがあります。コードベースから驚異的な量の再利用が可能です。