9

背景。我的组织使用 Maven、Bamboo 和 Artifactory 来支持持续集成过程。我们依靠 Maven 的 SNAPSHOT 限定符来帮助管理 Artifactory 中的存储（轮换旧的 SNAPSHOT 构建）并帮助保持跨团队集成的最新状态（Maven 在每次构建时自动检查对 SNAPSHOT 依赖项的更新）。

问题。我们面临的挑战之一是在继续使用 SNAPSHOT 的同时正确地在不同环境之间推广构建。假设测试人员将版本 1.8.2-SNAPSHOT 部署到功能测试环境，它在 Subversion 中的版本为 1400。假设它通过了功能测试。当测试人员决定将 1.8.2-SNAPSHOT 从 Artifactory 拉到性能测试环境中时，开发人员可能已经提交了对 Subversion 的更改，因此 Artifactory 中的实际二进制文件处于不同的版本。在使用 SNAPSHOT 构建时，我们如何确保 rev 不会从我们下面改变？

约束。我们显然不想在不知不觉中部署不同的构建。我们也不想从源代码重建，因为我们想在性能测试中测试我们在功能测试中测试的确切二进制文件。

我们考虑过的方法。我们的想法是我们想用第四个组件标记版本，例如 1.8.2.1400，其中第四个组件是 Subversion rev。（作为一个附带问题，是否有 Maven 插件或其他自动执行此操作的工具？）但是如果我们这样做，那么本质上我们将失去 SNAPSHOT 功能，因为 Maven 和 Artifactory 认为它们是不同的版本。

我们正在使用 Scrum，所以我们很早就部署到了测试环境（比如第二天左右）。我认为在开发周期的早期删除 SNAPSHOT 限定符是没有意义的，因为我们再次失去了 SNAPSHOT 的好处。

希望知道其他组织如何解决此问题。

4

3 回答 3

3

回到这个话题，我想分享我们正在做的事情。

基本上，我们将像 1.8.2-SNAPSHOT 这样的快照构建部署到开发环境中。没有其他团队需要使用这些构建，因此可以将 -SNAPSHOT 留在它们上。

但是我们部署到测试环境（例如功能测试、系统测试）或生产环境中的任何构建都必须包含修订；例如，1.8.2.1400。我们称这些为“四边形”。在测试中坚持使用四边形的原因是我们可以将问题（功能、错误修复等）附加到特定的修订版中，以便测试人员知道要测试什么。对于生产来说，这实际上只是因为我们想要部署与我们测试过的完全相同的工件，所以这意味着我们正在部署一个 quad。

无论如何希望这些信息对某人有用。

于 2011-07-01T08:34:32.097 回答
1

如果您为快照构建启用“uniqueVersion”，则部署的每个快照都将具有唯一的 ID。您可以使用它来确保跨环境部署正确的升级版本。

并且，作为旁注，您可以使用 buildnumber-maven-plugin 将 subversion buildnumbers 添加到工件。

于 2011-03-30T02:35:34.730 回答
1

我们没有将 VCS 版本的内部版本号嵌入到工件的版本中，而是将 CI 内部版本号嵌入到META-INF/MANIFEST-MF文件中。

See for instance Using Hudson environment variables to identify your builds . Although the article is applicable to Jenkins/Hudson I believe it is trivial to port to Bamboo.

于 2011-07-01T10:29:06.497 回答