共有ライブラリの分岐およびバージョン管理戦略

これらの 投稿は関連しているように見えますが、私の脳は溶け始めています：P

私の雇用主はソース管理の使用を開始しました。主に、彼らがより多くの開発者を雇う前に、「リポジトリ」は主に自宅で働く孤独な開発者のハードドライブだったからです。彼が書いた.NETコードはすべてまとめてチェックインされ、多くの重複した（読み取り：コピーアンドペースト）機能があります。現時点では、SCMシステムは栄光のバックアップです。

重複したコードの一部を共有ライブラリに引き込みたいです。元のリポジトリはそのままにしておき、何も壊さないようにします。必要に応じて既存のコードを移動および/またはリファクタリングできます。それで、ライブラリを含む新しいコードのためだけにリポジトリを設定しました。

私の問題は、過度のプロセスに悩まされることなくライブラリをバージョン管理することを中心にしています。ソリューションが生産性に影響を与え始めた場合、うまく落ちます。

私の強迫観念での理想的な解決策は、ライブラリを個別にビルドし、各依存プロジェクトを意図的に選択した互換性のあるバージョンに対してビルドすることです。そのようにして、どのクライアントがどのライブラリのどのバージョンを持っているか、バグをより確実に再現でき、製品とライブラリの独立したリリースブランチを維持でき、共有コードを変更するときに互いのプロジェクトを壊さないようにできます。

これにより、特に自宅で働く開発者にとっては、ライブラリの更新が面倒になります。少なくとも当初は（最終的に）共通部分をまとめると、ライブラリが急速に変化することを期待しています。私はこれを完全に考えすぎている可能性が高く、最新のライブラリコミットに対してすべてを構築するだけで構いませんが、少なくとも一部のコンポーネントを個別にバージョン管理する必要があると判断した日には備えたいと思います配布されました。一部のライブラリをGACにインストールする必要があるという事実により、バージョン管理は特に重要になります。

だから私の質問は：私は何が欠けているのですか？1つのソリューションに固執しているように感じますが、現在、変更をよりスムーズにするバリエーションを見つけようとしています。以前、この種の問題を解決するためにどのような戦略を使用しましたか？この質問はあちこちにあることを理解しています。不確実な点を整理し、明確にするために最善を尽くします。

そして、私はMercurialを使いたいと思っていますが、私たちはすでに集中型商用SCM（Vault）にお金を費やしており、切り替えはオプションではありません。また、ここでの問題は、バージョン管理ツールの選択よりも深くなると思います。

あなたのイニシアチブを称賛します。これにより、これを実装する組織にとって多くの利点が得られます。コードをコピーするのではなく、移動します。コピーがあると、互換性のない変更が発生する可能性が高いため、解決する必要があります。

ライブラリが開発および安定化されると、多少の痛みがあります。それが完了すると、特典が届きます。ライブラリへのインターフェイスは、基本的に、契約で動作するプロジェクトとの契約であることを忘れないでください。古いインターフェイスが使用されているかどうかを判断できるため、古いインターフェイスを削除する利点がある場合があります。

ライブラリが安定している間、新しいライブラリの取得はおそらくコード更新プロセスの一部であるはずです。ライブラリの変更のコミットをスケジュールすることができます。移動中のコードを発表すると、競合する変更を減らすのに役立ちます。

ライブラリは個別のプロジェクトとして扱い、できるだけ早く安定させる必要があります。それらが安定したら（特にインターフェース）、他のプロジェクトと変更を統合するのが簡単になるはずです。新しいライブラリは古いコードで動作するはずです。安定したライブラリリリースに独自のリリースIDをタグ付けします。ライブラリをサードパーティのライブラリと同様に扱うようにしてください。

プロジェクト間で共有されるコードは、それ自体がプロジェクトとして扱われる必要があります。これらは、サードパーティのライブラリと同じ徹底度で処理する必要があります。他に方法はありません。

グループで共有コードの戦略を採用できない場合、MercurialやGITなどの最新のソースコード管理ツールを使用して、自社で公式に使用するSCMでなくても、自分で戦略を採用できます。少し注意して、2つのSCMは、一方の内部ファイルを無視するように一方に指示するだけで、同じ作業ディレクトリを使用できます。1つのSCMを使用して日常業務を処理し、会社のSCMを使用して統合します。

とにかく、他のプロジェクトが共有コードに対して行った変更で作業ディレクトリをいつ更新するかを管理する必要があります。これらは、発生する可能性のある非互換性に対処する準備ができている場合にのみ発生します。そうしないと、実行可能な範囲を超えて作業が不安定になる可能性があります。

それらを個別の「モジュール」プロジェクトに分割できる場合は、そのアプローチを採用します。心配することの1つは、コードの結合です。懸念事項を分割することにより、懸念事項の分離を作成します。これは良い習慣です。

いくつかの利点：

1. 各モジュールの簡単なデバッグ。
2. ビルドサイクルの高速化（変更されていないライブラリの再構築なし）
3. 何かが機能したら、そのモジュールの外側の別の領域を変更することで、それを壊す可能性は低くなります（100％ではなく、チャンスを減らします）。
4. 相互に依存する大きな混乱ではない場合、作業割り当てをより簡単に分割できます。
5. 1つのライブラリを修正するときの小さな断片の高速配布（.dll / .soファイルがある大きな理由）。

この部分について質問が1つあります。

「強迫観念の中で理想的な解決策は、ライブラリを個別にビルドし、各依存プロジェクトを意図的に選択した互換性のあるバージョンに対してビルドすることです。」

プロジェクト全体を静的リンクしますか？その場合、これは次のことにつながります。6.不要なコードの肥大化の削減。

いくつかのネガ：

1. プロジェクトが小さい場合、必要のない場所に複雑さを追加するだけです。
2. 多数のモジュールを分岐すると、非常に大規模なプロジェクトの保守問題になる可能性があります。「Vault」がわからないので、分岐操作が良いか悪いかはわかりません。

現時点では、1つのコードベースが一度に1つのターゲットに組み込まれているように見えます。おそらく、開発者は5人以下です。私は、ライブラリをあまりにも分離するユーティリティを実際には見ていません。ワークフローをコードから変更します->コンパイル->コードに実行->コンパイル-> DLLをコピー->コンパイル->実行... ick

一部の企業（GoogleとAmazon）は、開発に十分なインフラストラクチャを備えているため、多数の個別のライブラリを個別に作成するのは非常に簡単です。簡単にするためのインフラストラクチャには、SCMに存在するライブラリバージョン（おそらくあなたが持っている）を指定する方法、SCMに存在する依存関係バージョンを指定する方法、それを理解し、すべてを適切にコンパイルできるビルドサーバーが含まれます、およびビルドサーバーとローカルワークスペースから適切なビルドアーティファクトを取得する方法。私はあなたがそれを持っているとは思わない。

そのインフラストラクチャがなければ、次のいずれかが当てはまる場合、プロジェクトを分離します。

• このライブラリに応じて、複数の製品または個別のアプリケーションがあります
• 一度に数日間、これらのライブラリでのみ作業します
• ライブラリの機能は、ビジネスに関連するもの（プラットフォーム固有のAPIのラッパーなど）とはまったく別のものです。
• 結合されたプロジェクトのビルド時間が長すぎる

多くのプロジェクトがあり、一部のプロジェクトには専用の開発者と独立したリリースサイクルがある場合、そのインフラストラクチャを構築することを心配します。

あなたは何をすることができますし、必要がある今、信頼性のためのビルドサーバーに設定されているか、再現性を構築し、指定した実行ファイルからソースリビジョンを見つけることができることを確認してください。.NETを使用しているようです。リビジョン番号を含むバージョン文字列を挿入するようにCruiseControl.NETをセットアップするのは非常に簡単です。

ビルドサーバーを作成したら、Vaultでライブラリを移動し、CC.NETで別のターゲットを追加し、結果のDLLをメインプロジェクトのライブラリフォルダーにコピーしてコミットするだけです。日々の開発よりもSCM側で簡単です。

Mercurialには、サブリポジトリと呼ばれる機能があります。最近、Kilnからこのブログを読んで、その仕組みを説明しています。

基本的に、プロジェクトをライブラリリポジトリの特定のリビジョンにリンクします。依存プロジェクトを壊さずに、必要なだけライブラリを更新できます。準備ができたら、ライブラリの新しい機能をプロジェクトに取り込み、破損に対処できます。異なるプロジェクトはライブラリの異なるリビジョンにリンクできるため、すべてが同期して同じライブラリリビジョンを使用する必要はありません。

たぶんVaultにも同様の機能があります。

SCの各モジュールに、依存する他のすべてのモジュールの名前を示すメタデータファイルを追加しました。製品には、製品に必要な各依存​​モジュールのバージョンを示す2番目のメタデータファイルがあります。さらに、メタデータファイルを分析し、必要なモジュールをすべてチェックアウトし、IDEのプロジェクトを生成するツールがあります。

これにより、ビルドが常に再現可能であり、正しいヘッダーファイルが常にコンポーネント間で共有されます。他の複雑さは、ニーズの進展に応じて階層化できます。SCのすべての独立したモジュールにわたって、変更されたソースファイル、チェックインコメント、バージョンコメント、作成者を指定して、製品の2つのビルド間の相違に関するレポートを生成できるツールがあります。コードベースから驚異的な量の再利用が得られます。