現在、ビルドにはTeam FoundationServerを使用しています。ビルドを一定期間保持するか、無期限に保持するようにTFSに指示できることはわかっています。何らかの理由でビルドに戻る必要がある場合に備えて、ビルドの一部またはすべてを無期限に保持したい場合はどうなりますか?ソース管理を使用してビルドを保存したり、ある種のファイルサーバーを使用して、将来の取得のためにビルドをファイルサーバーに保持したりしますか?チームビルドディレクトリ内にビルドを保存すると、そのディレクトリがすぐに乱雑になります。
もちろん、いつでも古いチェンジセットを分岐してその分岐のビルド定義を作成できますが、ソース管理やファイルサーバーからビルドを取得するよりも時間がかかります。
たぶん、私たちがやろうとしていることは、悪い考えです。
ビルドは繰り返し可能でなければならないことに明確に同意します。ただし、何らかの理由で正確な結果を表示する必要がある場合もあります。
ここではTeamCityを使用しており、「ピン留め」と呼ばれる機能があります。基本的に、任意のビルドをピン留めできます。つまり、永久に保持されます。これはすべてのリリースで行いますが、そこに到達した1000程度のビルドは固定されていません。
TFSに同様の機能があるかどうかはわかりません。
あなたが疑っているように、あなたがしていることは悪い考えだと思います。
理想的には、完全なパッケージを自動的に構築できる必要があります。その時点で、ビルドを維持する必要はありません。先月リリースしたものが必要な場合は、ソース管理のタグから自動的にビルドします。
それでも不十分な場合は、ビルドプロセスが適切に自動化されていないため、修正が必要な問題です。
私が最後にいた場所では、各ビルドをCDに書き込みました。 CDには、実行可能ファイル、インストーラー、およびそのビルドを作成したすべてのソースコードが含まれていました。これは内部ビルド用であり、明らかに、製品を出荷したCDに対してまったく異なる手順がありました(たとえば、明らかにソースコードなしで)。 CDのビルド番号をマーカーで書き、古いビルドのスピンドルをビルドマシンの隣に置きました。ローテクでオールドスクールですが、オーバーヘッドが少なく効果的です。
デスクトップまたはクライアントでホストされるアプリケーションを扱っていると思います。セルフホストのWebアプリが以前のバージョンを気にするのは珍しいことです。
複数のリリースがいつでも実際に使用される可能性のある製品に取り組んでいたとき、リリースごとにバージョン管理(git)に個別のブランチを作成すると、完全なビルドの結果が得られるため、非常に便利であることがわかりました。各ブランチにチェックインしました。
メリットは複数あります。