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

Question

背景.我的组织使用Maven,Bamboo和Artifactory来支持持续的集成过程.我们依靠Maven的SNAPSHOT限定符来帮助管理Artifactory中的存储(转出旧的SNAPSHOT构建),并帮助保持跨团队集成的最新状态(Maven在每个构建时自动检查SNAPSHOT依赖项的更新).

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

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

我们考虑过的方法.我们想要用第四个组件标记版本,比如1.8.2.1400,其中第四个组件是Subversion rev.(作为一个附带问题,是否有一个Maven插件或其他自动执行此操作的东西？)但是如果我们这样做,那么基本上我们失去了SNAPSHOT功能,因为Maven和Artifactory认为这些是不同的版本.

我们正在使用Scrum,因此我们很早就部署到测试环境(比如第二天左右).我不认为在开发周期的早期删除SNAPSHOT限定符是有意义的,因为我们再次失去了SNAPSHOT的好处.

很高兴知道其他组织如何解决这个问题.

Answer 1

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

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

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

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