リリースされたバイナリをバージョン管理下に保つにはどうすればよいですか？

リリースされたバイナリをバージョン管理下に保つにはどうすればよいですか？これにより、各リリース間で変更された内容を追跡できます。ソースリポジトリからリリースされたバイナリを分離するつもりです。リリースされたバイナリは、継続的インテグレーションソフトウェアから構築されるか、手動でコンパイルされます。

2つのオプション：

a）しないでください。再現可能な決定論的ビルドがあることを確認してください。つまり、同じ構成で同じソース管理リビジョンをビルドすると、常にまったく同じバイナリが生成されます。

b）ディレクトリを公開ビルドの信頼できるソースとして指定します。展開/配布手順のバイナリ部分をアップロードし、published-buildディレクトリがバックアップ計画でカバーされていることを確認してください。ここではバージョン管理は必要ありません。ビルドはライトワンスです。何か変更する必要がある場合は、新しいビルドを作成します。

いずれにしても、バイナリおよびその他のビルド出力は、さまざまな理由により、ソース管理下にありません。

バージョン管理システムではなく、バイナリ用のアーティファクトリポジトリを使用します。リリースされたバイナリの特定のバージョンは、時間の経過とともに変化することは想定されていません。したがって、ファイルが変更されないため、バージョン管理は意味がありません。

たとえば、Mavenリポジトリをアーカイブ/公開/提供リリースおよび他のバイナリ（ドキュメントなど）のリポジトリとして参照してください。

gitを使用している場合（バイナリを適切にマージしないため、自分で管理する必要があります）またはコミットしすぎている場合（コミットした場合にのみコミットする場合）を除き、問題ありません。ビルドするたびにではなく、出荷する準備ができています）。

ほとんどのSCMのデルタバイナリは非常によく、2MbのリソースdllをSVNに配置していたため、毎回数KBのデルタになりました。

SCMはバイナリ用ではなくソース用であるという多くの議論がありますが、ほとんどのソフトウェアがイメージで構成されていると考えると、これは単なるアイコンファイルであっても明らかに間違っています。それらはバイナリですが、ソースの一部なので、それらを入れて、それについてそれほど独断的ではありません。また、必要に応じてバイナリを再構築することもできますが、これはよくあるケースですが、積極的にサポートされなくなった古いシステムでは多大な時間の浪費になる可能性があります。3年前にバイナリを構築するために使用されたシステムに対応するために、古いサービスパックまたはパッチのみを使用してシステムを再作成する必要がある場合は、そのSCMにビンを追加していただければ幸いです。

SCMにビルドを追加することについて心配する必要があるのは、ビルドサーバープロセスの一部としてビルドを自動的に実行する場合だけです。これはしないでください。SCMを、自分にとってメリットのないビルドで埋めることができます。代わりに、リリースされたときにのみ追加してください。このようにして、顧客が何を持っているかを正確に把握し、顧客が報告した問題を、再構築したものではなく、使用しているバイナリで再現できます（たとえば、コンパイラまたはOSの最新の更新を使用して）。

リリースバイナリをバージョン管理下に置いていません。代わりに、他のツールが検査および使用できるように、それらを適切に定義された場所に公開します。私はJavaで多くの仕事をしているので、ローカルのMavenリポジトリにJarを公開しています。ただし、これらのツールを使用して、リリースごとに何が変更されたかを追跡しません。結局のところ、それらはバイナリであり、ファイル数以外に追跡することはあまりありません。

リリース間の変更を追跡するために、バージョン管理システム内のリリースにリリースのバージョン番号をタグ付けまたはラベル付けします。ただし、これはソースファイルを追跡するためだけであり、バイナリではありません。バイナリはビルドのアーティファクトであり、バージョン管理下にある必要はありません。

最善の解決策は、組織的に重要なすべてのビルド（リリース、リリース候補など）でCIシステムを排他的に使用することです。

これにより、リポジトリに実際にバイナリを保存することなく、リリースされたバイナリがリポジトリコンテンツに体系的に関連付けられます。

たとえば、SVNを使用している場合、ブランチメジャー組織スキームを使用します。/ trunkで日々の開発をすべて行い、準備ができたらリリースごとに/ tagを作成します。

トランクだけでなくタグからもビルドするようにCIシステムを構成し、リポジトリの最上位構造をミラーリングする構造を持つネットワークディレクトリに出力を書き込むようにします。

• / builds / trunk / [rev] [date] [build_id] /
• / builds / tags / release_0_1_3beta4 / [rev] [date] [build_id] /

ビルドシステムは、/ builds / trunk /ディレクトリを循環バッファーのように扱い、最後のn個のビルドを保存し、古いビルドを削除する必要があります。

一方、/ builds / tags /ディレクトリは永続的なストアです。ビルドアーティファクト自体は、次のスキームに従って生成された名前でディレクトリに保存されます。

• [rev] [日付] [build_id]

ここで、[rev]はSVNリビジョンID、[date]はYYYYMMDD形式の日付、[build_id]は3桁の一意のカウンターです。最初のビルド以降、各ビルドディレクトリが一意になります。

上記のプロセスには、次の利点があります。

1. ビルドアーティファクトは、それらを生成したソースに体系的に関連付けられているため、特定のビルドアーティファクトのソースを非常に簡単に見つけることができます（逆も同様です）。

2. これは、リリースの自動化の基礎となります。たとえば、リリース文書などの自動生成...