リリースした実行バイナリの保管とソースコードとの整合性を維持する方法

Question

聞きたいこと

バイナリリリースするうえで、リリース物として管理を行いたいが、git等に乗せてしまうと、サイズが肥大化し、clone等に時間がかかってしまうため、何か良い方法はありますでしょうか。
"こんな方法"が素晴らしかった　や、試した手順での改善点等あれば教えていただけると幸いです。

背景

受託開発で複数回リリース(納品)がある案件の管理を行っています。
リリース管理を行うにあたり、バイナリをどこかに保存しておく必要がありました。

対象となったプロジェクトの言語等

• .NET Framework 4.5 (C#) Windows-forms/WPF application
• Spring framework 4.x target: war
• Android project (gradle, java)

バイナリをコミットする理由は、(内部のファイルはタイムスタンプ等を持っているため、)ビルドしても前回と全く同じデータにならないためです。

試したこと1

対応:
バイナリリリース用ブランチを用意してリリースビルドの都度、マージコミットとバイナリをコミットする。
結果:
リポジトリが肥大化し、pullに時間がかかるようになってしまった。

試したこと2

対応:
CIでビルドを行い、別リポジトリへコミットする。
結果:
どれが最終リリースなのかわかりにくくなった。
ビルド時間等から類推することができるが、ソースの特定や紐づけに時間がかかるようになった。
また、リリース対象外のバイナリの間引きが難しかった。

Answer 1

一般に最終生成物であるbinaryはrepoには含めません。一度でも含めると永遠と肥大化したままなので、当該履歴をrebase or filterしてして取り除き、新たにremoteにrepoを作り直してpushする必要があります。

最終生成物はGithubならGithub Releaseに置くのが一般的です。その他、適当なFTP/httpサーバーに置くことが多いと思います。

とにかくでかいファイルを含めないことが肝要です。

最終生成物以外ででかいファイルを含める必要がある場合は、git-lfsの利用を検討してください。

Comments

[testset]

適当なFTP/HTTPサーバーに置くというときは、TAG名等と一致させた名前を配置するということでしょうか。
オンプレミスであるgitサーバー(gitbucket)なので、git-lfsに対応できません...とコメントしようと思いましたが、知らぬ間に対応されたみたい (https://qiita.com/hikaruworld@github/items/c523d0d994aeee7038d6) ですので、検討いたします。

[yumetodo]

>適当なFTP/HTTPサーバーに置くというときは、TAG名等と一致させた名前を配置するということでしょうか。
Yes。これはGithub Releaseに置くときも。

>gitbucket
あれ、
https://github.com/gitbucket/gitbucket/commit/fd30facd8f561a66123c476f9d252943b7b5a21a
でGithub Release相当の機能追加されてますよ。

[testset]

その手もありましたか。redmine+gitbucketだったので、意識していませんでした。
保存場所を確認して移行してみようと思います。
(まるごとリリース物を突っ込むことを考えています。連携できる方法も考えてみます。)
※Gitbucketでgithub release相当の機能はv4.21.0でリリースされるようです。(会社の環境は4.1xだった...)