在我們的項目中，我們將項目二進制文件的快照部署到tomcat/lib目錄。一般來說，POM其提到是否應將SNAPSHOT版本部署到QA和產品
<version>0.2.22-SNAPSHOT</version>
，並部署到QA jar文件的/ dev環境是
my-project-0.2.22-SNAPSHOT.jar
我們正面臨着一些一致性問題，如建立準確沒有發生，一些代碼反映，有些不是後構建，有時它合併的舊+新代碼。
我的問題是，這樣的問題是否可能是因爲我們正在環境中部署快照版本？這也是將快照部署到環境中的好習慣嗎？
謝謝
按照慣例，快照版本是未發佈的版本。這個想法是，在發佈之前我們有一個SNAPSHOT，這個SNAPSHOT代表什麼可能成爲一個發佈。
這裏的一個具體的例子：
T1：啓動dev的週期爲釋放1.0T2：部署和測試該第一1.0-快照T3：部署和測試該第二1.0-快照T4：部署和測試第三個1.0-SNAPSHOTT5：在1.0-SN上取消註銷APSHOTT6：分支，更新版本到1.0T7：部署1.0正式版T8：開始發佈1.1這是，當然，一個簡化但關鍵點是堅實的，即;
X的快照版本基本上意味着a developemnt version of X1.0-SNAPSHOT時，Maven會將該版本擴展爲1.0-yyyMMdd-HHmmSS-i，從而創建一個時間戳特定版本1.0-SNAPSHOT。根據何時解決該依賴關係，您可能會獲得不同版本的1.0-SNAPSHOT。您可以控制Maven在存儲庫配置上使用updatePolicy解決SNAPSHOT依賴性的方式，但中心點仍然存在;你永遠不可能是某些當你依賴SNAPSHOT版本時，你會得到什麼版本。這在開發中很好（實際上它通常是開發中期望的行爲），但是這種缺乏再現性在PROD中是危險的。我覺得上面應該有助於解釋爲什麼您遇到這些問題：
我們正面臨着一些一致性的問題，來樣訂做沒有發生準確，一些代碼反映，有些不是建立
後
一般而言，SNAPSHOTs只能在DEV中使用。在正式的測試環境（如質量保證）和絕對在PROD你不應該部署或依靠SNAPSHOT版本。
需要站在構建的基礎上，能夠準確地說出其中的內容對於PROD和正式測試evns和發佈版本（因爲它們是不可變的意圖）至關重要，旨在讓您相信什麼是在你的構建中是你打算在你的構建中。
對此的簡單回答：永遠不要把SNAPSHOT放到質量檢查中，也不要放在PROD上......如果達到了交付給其他人而不是開發人員發佈的要求... – khmarbaise