想要工件可追溯性而不放弃 SNAPSHOT 限定符

Posted 2023-03-05

【中文标题】想要工件可追溯性而不放弃 SNAPSHOT 限定符

【英文标题】：Want artifact traceability without giving up the SNAPSHOT qualifier

【发布时间】：2011-03-30 01:06:54

【问题描述】：

背景。我的组织使用 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 的好处。

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

【参考方案1】：

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

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

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

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

【参考方案2】：

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

另外，您可以使用 buildnumber-maven-plugin 将 subversion buildnumbers 添加到工件中。

【讨论】：

是的，但这不会阻止 Maven 存储库收集旧快照吗？

哦，感谢您对 buildnumber-maven-plugin 的引用。

@Willie - 是的，这是真的。假设您只在很短的时间内（几周左右）使用快照，您可以配置您的 repo 清理以在给定的时间内保留快照，这跨越了它们的用途。

【参考方案3】：

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

例如参见 Using Hudson environment variables to identify your builds 。虽然这篇文章适用于 Jenkins/Hudson，但我相信移植到 Bamboo 是微不足道的。

【讨论】：

我明白了。是的，我们也谈到了这样做，因为从 CI 内部版本号恢复 VCS rev 比反过来更容易。这是你的主要动机还是你有其他想法？

我的动机是想知道我正在测试什么版本。我从未考虑在工件版本号中嵌入任何内容，因为用户无法直接使用它——这是我的主要目标——而且似乎更难实现。