Question

在我们的项目中，我们将项目二进制文件的快照部署到tomcat / lib目录。一般来说，在pom中提到它

<version>0.2.22-SNAPSHOT</version>

在qa / dev环境中部署的jar文件是

my-project-0.2.22-SNAPSHOT.jar

我们正面临着一些一致性问题，比如构建不准确，有些代码反映，有些代码不是在构建之后，有时是合并的旧+新代码。

我的问题是，这样的问题是否可以因为我们在环境中部署快照版本？这也是将快照部署到环境中的好习惯吗？

由于

Answer 1

按照惯例，快照版本是未发布的版本。我们的想法是，在发布之前我们有一个SNAPSHOT，而这个SNAPSHOT代表了什么可能成为一个版本。

这是一个具体的例子：

这当然是一种简化，但关键点是可靠的，即;

在任何版本存在之前，该版本有一个SNAPSHOT版本
版本X的SNAPSHOT版本基本上代表a developemnt version of X
随着开发周期的进展，SNAPSHOT版本应该越来越接近最终的RELEASE版本
通常，SNAPSHOT版本仅在开发期间存在，并且RELEASE版本不应对SNAPSHOT具有任何依赖性。
可以更新SNAPSHOT版本，而RELEASE版本是不可变的。因此，今天下载1.0-SNAPSHOT可以为您提供与昨天下载1.0-SNAPSHOT时所获得的文件不同的文件。在Maven下偷看一点点;当您安装或部署1.0-SNAPSHOT时，Maven会将该版本扩展为1.0-yyyMMdd-HHmmSS-i，从而创建1.0-SNAPSHOT的时间戳特定版本。根据您何时解决该依赖关系，您可能会获得1.0-SNAPSHOT的不同版本。您可以使用存储库配置中的updatePolicy来控制Maven解析SNAPSHOT依赖关系的方式，但中心点仍然存在;当你依赖SNAPSHOT版本时，你永远不会某种你会得到什么版本。这在开发中很好（实际上它通常是开发人员所希望的行为），但这种重现性的缺乏在PROD中是危险的。

我认为上述内容应该有助于解释您遇到这些问题的原因：

我们正面临一些一致性问题，例如构建不准确，一些代码反映，一些不构建后

通常，SNAPSHOT应仅在DEV中使用。在PROD中的正式测试环境（例如QA）和肯定中，您不应该部署或依赖SNAPSHOT版本。

需要站在构建上，能够准确地说出其中的内容在PROD和正式测试版本和发布版本中是必不可少的（因为它们是不可变的意图）旨在让您相信什么在你的构建是你打算在你的构建中。