我在採用持續交付的組織中和開發團隊工作一起工作，發現很多開發者認為的正確的敏捷團隊的工作方式，在這裡跑得不是很順暢。我認為傳統敏捷與持續交付的矛盾的根本在於，二者是採用不同的方式把軟體變得“可以釋出“（ready to release）的。

　　軟體交付的演進

　　使軟體變得可以釋出的過程一直在不停進化，下面是一個簡要的介紹：

　　瀑布模型

　　瀑布模型認為，當一個軟體所有的功能都發開完畢的時候（也就是功能完整的時候），才可以釋出。

　　敏捷：

　　敏捷引入的思想是，在整個開發過程中，軟體都應該“可以釋出”。許多敏捷的版本（在這篇文章裡被稱為傳統敏捷）都認為，“可以釋出”應該在固定週期的間隔點上完成。

　　持續交付：

　　持續交付是敏捷的一個子集，在持續交付中團隊會保持軟體在開發過程的所有時間內都可以釋出。它和傳統敏捷不同之處在於，持續交付在開發過程中不會有停下來然後建立釋出版本的過程。

　　持續性交付不是指更短的週期

　　從傳統的敏捷開發流程變成可持續性交付，不是指把軟體釋出的週期變短。每天晚上做釋出版本仍然不是可持續性交付。可持續性交付是說要把”做可以釋出的軟體”這個動作本身從開發過程中去掉，取而代之的是保持軟體在開發的過程中始終是可以釋出的。

　　可以釋出不是意味著真正的釋出

　　有一個普遍的誤解是可持續性交付就是非常頻繁地釋出出產品。而當一些組織把每天數次釋出軟體當作是持續交付的標杆時，就更加深了這一誤解。可持續性交付不是一定要頻繁的釋出，它只是要求在開發過程中的任何一個點上，用非常少的工作，軟體就能夠釋出（可參考Jez Humble的文章，可持續性交付VS可持續性部署）。儘管具備這一能力為更加頻繁的釋出敞開了大門，但是許多團隊還是從持續交付的實踐中，找到了壓倒性的證據，來證明即便釋出不是很頻繁時，持續交付也是有用的。

　　持續交付和傳統敏捷的衝突點

　　我前面講過，有時候持續交付和開發團隊所認為是“正確”的敏捷實踐流程有一些矛盾。

　　衝突點：當有工作沒有完成時，軟體依然是可釋出的

　　其中一個衝突點是，一個迭代結束時，程式碼庫中是否可以包含未完成的使用者故事（user stories）或者bug修復。我在上一篇關於迭代的帖子中做了探討。這個問題主要是源於，傳統敏捷認為在迭代結束時，team停止開發，並且來做準備軟體釋出的一些額外工作，但是，如果團隊採用持續交付，讓軟體可釋出就沒什麼額外的工作需要做。

　　更有甚者，持續交付團隊甚至認為，通過使用功能切換等技術，他們的程式碼即使在還有功能沒有完成也可以釋出成產品。這也從另外一個方面說明，團隊在迭代結束時能夠達到可以釋出的要求，即使有未完成的使用者故事。

　　這可能稍微有點難理解，團隊肯定還是可以要求在迭代結束點上所有的工作都必須完成，但是這容易讓人感覺是團隊原有的正常開發的節奏被隨便打斷了。持續交付不是要求沒有時間盒的迭代，這兩種實踐其實是互補的。

　　衝突點：snapshot（軟體快照）/釋出版本（release build）

　　許多開發團隊把軟體的版本分為“snapshot”版本和“release”版本。這個並不是敏捷所特有的，而是隨著Maven的興起，被深深植入了Java開發中，因為Maven把snapshot的概念放入了它的設計核心中。這種方案把開發週期劃分成兩個階段，在軟體開發過程中使用snapshot，當軟體成為可以釋出狀態時才建立release版本。

　　很明顯，這種釋出週期的劃分和持續交付的“軟體應該總是可以釋出”的理念是相沖突的。持續交付通常採用的方式是隻在開始建立一次版本，然後通過不同階段的測試驗證等一系列序列工作來對版本進行改進，如果使用Maven，要用兩種方式建立版本，這種方式就不行了。