リリースされたバイナリをバージョン管理下でどのように維持しますか？
リリースされたバイナリをバージョン管理下でどのように維持しますか？これにより、各リリース間で変更されたものを追跡できます。リリースされたバイナリをソースリポジトリから分離することを意味します。リリースされたバイナリは、継続的インテグレーションソフトウェアからビルドされるか、手動でコンパイルされます。
2つのオプション：
a）しないでください。再現可能な確定的ビルドがあることを確認してください。つまり、同じ構成で同じソース管理リビジョンをビルドすると、常にまったく同じバイナリが生成されます。
b）公開されたビルドの信頼できるソースとして、ディレクトリをどこかに指定します。バイナリのアップロードをデプロイメント/配送手順の一部にし、published-buildディレクトリがバックアップ計画の対象であることを確認します。ここではバージョン管理は必要ありません。ビルドは追記型であり、何かを変更する必要がある場合は、新しいビルドを作成します。
いずれにせよ、バイナリやその他のビルド出力は、さまざまな理由でソース管理下にありません。
バージョン管理システムではなく、バイナリのアーティファクトリポジトリを使用します。リリースされたバイナリの特定のバージョンは、時間の経過とともに変化することは想定されていないため、ファイルは変更されないため、バージョン管理は意味がありません。
たとえば、リリースやその他のバイナリ（ドキュメントなど）をアーカイブ/公開/提供するリポジトリとして、Mavenリポジトリを参照してください。
それらを入れるだけです。gitを使用している場合（バイナリをうまくマージできないため、自分で管理する必要がある場合）、またはそれらを何度もコミットしている場合（つまり、出荷する準備ができており、組み立てるたびに出荷されるわけではありません）。
ほとんどのSCMのデルタバイナリは非常にうまく機能します。以前は2MbのリソースdllをSVNに入れていましたが、毎回数KBにデルタしていました。
SCMはバイナリではなくソース用であるという多くの議論を耳にしますが、ほとんどのソフトウェアが単なるアイコンファイルであっても、イメージで構成されていると考えると、これは明らかに誤りです。それらはバイナリですが、ソースの一部なので、それらを入れて、それについてそれほど独断的ではありません。また、必要に応じてバイナリを再構築することもできると聞きました。多くの場合、これが当てはまりますが、アクティブにサポートされなくなった古いシステムでは、多大な時間の浪費となる可能性があります。 3年前にバイナリをビルドするために使用されたシステムに対応するために、古いサービスパックまたはパッチのみを使用してシステムを再作成する必要がある場合は、当時のSCMにビンを追加できてうれしいです。
SCMへのビルドの追加について心配する必要があるのは、ビルドサーバープロセスの一部として自動的に追加する場合のみです-これは行わないでください。 SCMは、何のメリットもないビルドで満たされます。代わりに、リリースされたときにのみ追加してください。このようにして、顧客が何を持っているかを正確に把握し、顧客が報告した問題を、使用しているバイナリで再現できます（コンパイラやOSの最新アップデートなどを使用して再構築したものではありません）。
リリースバイナリをバージョン管理下に置いていません。代わりに、それらを明確に定義された場所に公開して、他のツールや検査して使用できるようにします。私はJavaで多くの作業を行っているので、JarをローカルのMavenリポジトリーに公開しています。ただし、リリースごとに何が変更されたかを追跡するためにこれらのツールを使用しません。結局のところ、これらはバイナリであり、ファイル数以外に追跡することはほとんどありません。
リリース間の変更を追跡するために、バージョン管理システムのリリースにリリースのバージョン番号をタグ付けまたはラベル付けします。ただし、これはソースファイルを追跡するためだけのものであり、バイナリを追跡するためのものではありません。バイナリはビルドの成果物であり、バージョン管理下にある必要はありません。
最善の解決策は、組織的に重要なすべてのビルド（リリース、リリース候補など）に対して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] [date] [build_id]
ここで、[rev]はSVNリビジョンID、[date]はYYYYMMDD形式の日付、そして[build_id]は3桁の数字です一意のカウンター。最初のビルドから増加し、各ビルドディレクトリを一意にします。
上記のプロセスには、次の利点があります。
ビルドアーティファクトは、それらを生成したソースに体系的に関連付けられているため、特定のビルドアーティファクトのソースを非常に簡単に見つけることができます（逆も同様です）。
これは、さらなるリリース自動化の基礎を形成します。たとえば、リリースドキュメントの自動生成など...