マルチコンポーネントプロジェクトをバージョン管理する最良の方法は何ですか

5つの主要なコンポーネントで構築されたプログラムがあります。各コンポーネントのバージョンを確認したいので、標準のバージョン番号は制限が多すぎると思います。

誰かが個別にリストする以外に、これを行う簡単な方法を見つけた人はいますか？

私たちの製品でもまったく同じ問題があり、コンポーネントごとに個別のバージョン番号を付けることにしました。製品バージョンは、特定のリビジョンのさまざまなコンポーネントで構成されるマーケティングバージョンにすぎません。

「システムリリースバージョン」があります。これは、コンポーネントの特定の構成を説明する標準バージョン番号です。次に、その特定のシステムリリースの個々のコンポーネントバージョンを別のファイルにリストします。顧客は5.2.1と言っていますが、必要に応じて個々のビルドを調べることができます。通常、メジャーリリースでは、すべての個別バージョンを同期するため、同じブランチ番号からすべてが再びビルドされます。

バージョン管理は、コンポーネントベースのアプリケーション開発とは別の問題です。各コンポーネントをバージョン管理するか、アプリケーション全体をバージョン管理するかのどちらかです。

バージョン管理のよく知られたパターンはMicrosoftからのものです。

major version.minor version.build number.revision

たとえば、.NETプラットフォームのDLLファイルで、2.0.3600.1などのバージョンを確認できます。

そのため、まずシステム全体またはそのコンポーネントのバージョンを付けるかどうかを決定することをお勧めします。システム全体をバージョン管理する場合は、統合のたびにプロジェクト全体をビルドし、ビルド番号の部分を増やします。そうでない場合は、ビルド時に各コンポーネントをバージョン管理するだけです。

バージョン管理に注意してください。それはあなたを殺すかもしれません:-)物事を複雑にしすぎないようにしてください。

次のアプローチが役立つと思います。

必要なバージョン管理スキーマを使用して、各コンポーネントを個別にバージョン管理します。あなたのコメントから、VCSを導入していることがわかりました。また、各コンポーネントには、バージョンが保存されているファイルがあると思います（そうですか？）。1日1回/週に1回（チームに適している方）、VCSの最新のリビジョンの1つにタグを追加し、そのリビジョンを最新の公式リビジョンとしてマークします（オプションでスーパーリビジョン番号をインクリメントします）。これで、VCSにそのタグが付いたリビジョンを照会し、その公式ビルドでコンポーネントのバージョンを探すことができます。

ローカルにしたいだけの場合は、コードが格納されている場所から各コンポーネントのバージョンを集約する小さなスクリプトを記述します。

さらに洗練させたい場合は、タグ付けを行うと、特定のコンポーネントに属するファイルを識別できることを考慮して、各コンポーネントに属するファイルを確認できます。変更されている場合は、その特定のコンポーネントのバージョンを増やします。別の方法は、これを手動で行うことです。別の方法は、分岐とマージとバージョン追跡の組み合わせです。

ほとんどのバージョン番号は、マーケティングによって推進されるメジャーリビジョンとマイナーリビジョンを使用しているため、個々のコンポーネントバージョンの追跡には使用できません。つまり、個々のコンポーネントのバージョンを追跡するために使用できるバージョンの他の部分を見つけ、パッケージ全体を追跡するためにメジャーバージョン番号とマイナーバージョン番号を予約する必要があります。

Microsoftパターンに似たものをフォローしている場合：

major-version.minor-version.build-number.revision

通常の方法で、.revisionを使用して個々のコンポーネントのバージョンを追跡し、マイナーおよびメジャーのリビジョン番号を使用して製品の完全な変更を追跡できます。

次のようなパターンに従っている場合：

Major-Version.Minor-Version.Build-Number

個々のコンポーネントのバージョンを追跡するには、ビルド番号を使用する必要があります。

本はすべてバージョン管理ソフトウェアについて書かれています。

ここに私が使用するアプローチがあります。

各パーツには、次の形式のバージョンがあります。

メジャー。マイナー。開発

これらはそれぞれ0から始まる番号です。

正式リリース（つまり、顧客向け）の場合、ポリシーの問題として、開発部分は常に0でなければなりません。

Majorは、マーケティングの決定によって増加します。

マイナーは、リリースされる機能セットによって増加します。

例：

• 新しいコンポーネントの開発を開始したので、バージョン番号は0.0.1になります。たとえば社内テストのために自分の机から同僚に向けてリリースすると、開発数は0.0.2、0.0.3などに増えます。

• 私はこの新しいものを1.0.0として市場にリリースします。開発の終わりからリリースへの唯一の許可された変更は、バージョン番号を変更することでした（たとえば、0.0.43-> 1.0.0）。

• いくつかの新機能が追加されます。1.0.0ベースラインで作業を開始し、これらの機能を追加します。したがって、テストのために同僚にリリースするバージョンは1.0.1、1.0.2などです。

• 次の機能は1.1.0としてリリースされます。

• マーケティングは、次の大きなものは本当に大きくなると判断するため、2.0.0として出荷されます。私は1.1.1で作業を開始し、1.1.xまで進み、2.0.0としてリリースします。

そして、このサイクルが繰り返されます。

このアプローチは、コンポーネントごとに、祖先のトレーサビリティを提供します。

ソース（およびオブジェクト）リビジョン管理システムの内部では、ブランチとタグ（ラベル、その日の用語が何であれ）を使用して開発を管理します。

リビジョンコントロールは、各コンポーネントを完全に個別に管理し、それぞれに開発ブランチとラベル/タグを付けます。または、それらをまとめてバンドルすることもできます。その場合は、作業パッケージごとに分岐することをお勧めします。ただし、必ず各コンポーネントのリリースごとにラベル/タグを付けてください（そうするときは、コンポーネント。これにより、その時点でのすべての状態のスナップショットが得られます。

リリースプロセスは慎重に検討する必要があります。このアプローチを使用すると、いくつかの手動の手順が含まれますが、これは望ましくない場合があります。これはすべて、ビルドシステムがバージョン番号を最終オブジェクトにどのように挿入するかに依存します。バージョン番号が単なる名前付きの多くの埋め込みコード（たとえば、Cコードで定義された＃）の場合は、とにかくすべて手動で行う以外に選択肢はほとんどありません。優れたGUIを備えたデスクトッププラットフォームは、多くの場合これを非常に親しみやすくします。

概要

私にとって、ソフトウェアをバージョン管理する唯一の信頼できる方法は、バージョン管理システムからのハッシュまたはチェンジセット識別子を使用することです。

全体的なビルドバージョン番号は便利ですが、ビルドサーバーがある場合や各リリースに署名する場合にのみ、一意であることが実際に保証されます。しかし、私たちの多くにとって、これは単に現実的ではありません。

プロジェクトが複数のバージョン管理リポジトリに分割されている場合は、ユーザーインターフェイスが各依存リポジトリにクエリを実行し、そのハッシュをユーザーに報告できるメカニズムを構築する必要もあります。

個人的な経験からの例

以前の雇用主のプロジェクトで、（内部の）顧客修正ソフトウェアに問題があり、それを再コンパイルしていたので、水銀のハッシュを各アプリケーションとライブラリにコンパイルするプロセスを開始しました。ソフトウェアが起動するたびに、すべてのソフトウェアコンポーネントにクエリを実行して、リビジョン文字列が作成されました。

このリビジョン文字列は、Aboutページに移動したときに表示され、アプリケーションが起動されるたびにログファイルに書き込まれました。それは次の形式でした：

Application name     (6a72e7c61f54)
    Library1         (b672a13a41e1)
        Library2     (9cc35769b23a)
    Library2         (9cc35769b23a)
    Library3         (4e9f56a0186a+)
        Library2     (9cc35769b23a)
    Library4         (2e3b08c4ac76)
        Library1     (b672a13a41e1)
            Library2 (9cc35769b23a)

このことから、Library3が変更され、それらの変更がリポジトリにコミットされていないため、制御されていないコードを使用していることが簡単にわかりました。ハッシュを現在のテストシステムと比較することもできます。そのため、それらがLibrary1を古いバージョンに戻した（たとえば）ことを確認できる場合があります。

これは、彼らがバグを報告するときはいつでも、問題が発生したときに使用していたコードを常に正確に再構築できること、または少なくともセットアップを再現できなかったことを確信できることを意味しました。

私が使用したビルドシステムの詳細、これをどのように達成したか、どのような問題があり、人々がそれらを回避するために提案したことについては、スタックオーバーフローの質問を参照してください。

注：このシステムは、特定の作業ディレクトリにファイルの混合物が含まれている可能性がある場合に、特定のハッシュが作業ディレクトリ（gitとmercurialなど）に同じファイルセットになることが保証されているリビジョン管理システムを使用する場合にのみ実際に実行可能です。いくつかのリビジョンのディレクトリ（例：svn）の場合、作業ディレクトリの状態に関してすべての賭けが無効になり、このメソッドはまったく機能しません。