应该使用Git来存储持续集成构建？

在一个可以每天创建多个构建版本（发布候选版本包）的环境中，每月只有一个版本升级到生产版本，我认为将每个版本存储在Git中都是浪费的，但应该有一个短期地点，即最后几个版本已出版。应该使用Git来存储持续集成构建？

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

是否有一种协议的，标准化的方式来管理/发布这些瞬态构建工件？

2013-01-23 Syndrome

你为什么要存储神器？构建可以被重新创建。 –

（无论如何，我的意思是在git中，大多数CI服务器都不会将构建版本保持在可配置的时间范围内） –

构建可以重新创建，但构建环境有时不能。不管您是否将整个工具链保持在修订版控制之下，您无法确定在大量时间过后可以构建相同的二进制文件。此外，不可能构建完全相同的二进制文件（嵌入式时间戳导致不同的文件校验和）。这使得第三方难以信任或认证您的软件，除非他们也从源头上构建软件。 –

我不会存储在git的生成工件，而是看，无论是从连续型集成（CI）服务器或专用神器库如artifactory或nexus共享构建构件。总的来说，我发现最好避免所有SCM中的大型二进制文件，因为你无法区分它们或进行增量更新，所以你会发现你的git repo快速增长，因为它在每次更改时都存储完整版本的二进制文件。

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

通过使用神器库或CI服务器来管理构建构件也可以通常通过时要自动部署过程，例如，你可以像“getLastSuccesfullBuild”电话这进来非常有用的API访问文物和'getLastPromotedBuild（）'等。

来源

2013-01-23 22:23:44

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

应该使用Git来存储持续集成构建？

回答

相关问题