背景。我的组织使用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的好处。
很高兴知道其他组织如何解决这个问题。
答案 0 :(得分：3)
为了回顾这一点，我想分享我们正在做的事情。
基本上我们将1.8.2-SNAPSHOT等快照构建部署到开发环境中。没有其他团队需要使用这些构建，因此可以在它们上留下-SNAPSHOT。
但是我们部署到测试环境（例如功能测试，系统测试）或生产的任何构建都必须包含修订版;例如，1.8.2.1400。我们称之为“四边形”。在测试中坚持四边形的原因是我们可以将问题（功能，错误修正等）附加到特定修订版本，以便测试人员知道要测试的内容。对于生产而言，这只是因为我们想要部署与我们测试的完全相同的工件，这意味着我们正在部署四元组。
无论如何希望信息对某人有用。
答案 1 :(得分：1)
如果为快照构建启用“uniqueVersion”，则部署的每个快照都将具有唯一ID。您可以使用它来确保在不同环境中部署正确的升级版本。
并且，作为旁注，您可以使用buildnumber-maven-plugin将subversion buildnumbers添加到工件中。
答案 2 :(得分：1)
我们不是在工件版本中嵌入VCS版本号，而是将CI版本号嵌入META-INF/MANIFEST-MF文件中。
例如参见Using Hudson environment variables to identify your builds。虽然这篇文章适用于Jenkins / Hudson，但我认为移植到Bamboo是微不足道的。