一、問題產生
我們來思考下持續交付的原則。每次構建的結果可能是一個潛在的發行版本；消除手動瓶頸；儘可能自動化。這三點正是我們想要實現的，但是在實現之前，我們先來看下在典型的Maven發佈流程和經典方式版本號管理上的具體問題。
1）沒有自動化
通常來說，一次提交會觸發一個快照構建，然後生成一個快照構件（“8.1.2-SNAPSHOP”）。當開發者感覺軟件到達穩定狀態後，他會觸發一次專用發佈構建。因此，他預先分配版本號（“8.2.0”）。人員必須分配版本號然後觸發發佈構建。這種方式有什麼缺點：（1）我們需要手動觸發專用的發佈工作流程；（2）版本號需要人爲手動分配；（3）看版本號“8.2.0”並不清晰，比如這個版本號的構件中包含了哪些提交(代碼)。我們需要一個Git標籤。
2）任意快照
此外，快照引起了許多問題。不清晰的內容變動。（1）不可追蹤。我們不能說，有哪些提交包含在了當前的快照構件中；（3）不可靠。快照構件可以很快速的修改。這樣很容易引起問題。（3）易出錯。不過不注意，很容易覆蓋一個快照（比如：當創建Git分支的時候，忘記修改POM文件中的版本號。從Git分支上構建會覆蓋之前的快照）。
3）Maven發佈插件的缺陷
最後，Maven的發佈插件也引起了許多問題：（1）開銷。Maven發佈插件運行3次完整的構件和測試周期，展開POM文件兩次和創建三次Git修訂（Git revisions）；（2）不具有隔離性。當其他人在發佈版本期間提交更改時，插件可能容易陷入混亂；（3）不具有原子性。如果最後一步出現問題（比如：在構件上傳期間），突然發現緊急Bug。我們必須清理創建的Git