是否应该使用 Git 来存储持续集成构建？答案

【问题标题】：Should Git be used to store continuous integration builds?是否应该使用 Git 来存储持续集成构建？
【发布时间】：2013-01-07 12:29:56
【问题描述】：

在每天可以创建多个构建（发布候选包）但每个月只有一个升级到生产环境的环境中，我认为将每个构建存储在 Git 中会很浪费，但应该有一个短期位置，最后几个构建发布。

我目前正在将这些发布到共享目录。过去我曾看到 IVY 用于这种二进制发布。 Git 看起来有点矫枉过正，因为它的模型永远不会删除任何东西。

是否有一种公认的标准化方式来管理/发布这些临时构建工件？

【问题讨论】：

为什么要存储工件？可以重新创建构建。
（无论如何，我的意思是在 git 中。难道大多数 CI 服务器不会在可配置的时间内保留构建吗？）
可以重新创建构建，但构建环境有时不能。除非您将整个工具链置于修订控制之下，否则无法确定在大量时间过去后您是否可以构建相同的二进制文件。此外，不可能构建完全相同的二进制文件（嵌入的时间戳会导致不同的文件校验和）。这使得第三方很难信任或认证您的软件，除非他们也从源代码构建它。
是的，使用 CI 服务器是一种选择。我有点认为这与使用目录相同。我想我们会有额外的好处，即在设定的时间间隔后自动清理瞬态构建。嗯。

标签： git build continuous-integration ivy artifactory

【解决方案1】：

我不会将构建工件存储在 git 中，而是考虑从持续集成 (CI) 服务器或专用工件存储库（例如 artifactory 或 nexus）共享构建工件。一般来说，我发现最好避免在所有 SCM 中使用大型二进制文件，因为您无法区分它们或进行增量更新，因此您会发现您的 git 存储库快速增长，因为它会在每次更改时存储完整版本的二进制文件。

大多数持续集成工具（例如 Jenkins）将能够归档最近的 X 构建工件或上个月内制作的所有构建工件。他们还有一些插件，可以帮助支持和自动化推广您认为有帮助的构建的过程（即Jenkins build promotion）。

通过使用工件存储库或 CI 服务器来管理构建工件，您通常还可以通过 API 访问工件，这在您想要自动化部署过程时非常有用，例如您可以调用“getLastSuccesfullBuild”和'getLastPromotedBuild()' 等

【讨论】：

+1 Nexus、Artifactory 或 Archiva 等存储库管理器旨在解决此问题。查看他们的功能。我们使用 Nexus 专业版，这使我们能够“分阶段”发布我们的版本并创建认证工作流程，其中 DEV 创建构建工件，随后在进入生产存储库之前由测试和 QA 批准。