理解
用我們如今的白話來描述最簡單的就是，你提交一行修改某個bug的代碼，發佈系統會按照流程自動化的做完一系列的檢查，然後發佈一個版本到生產環境。這樣用戶在最短的時間內可以拿到修改的結果。
引用CI CD
這裏有一些比較詳盡的解釋。
大概的意思就是從deploy到release之間的頻繁部署交付的能力。
再次理解
敏捷只是一切的最自然的前提，然後是持續集成，伴隨着持續測試，最後纔是持續的交付。
所有的一切都是爲了建立快速的持續反饋機制。這樣市場或者用戶可以更快速的給予反饋，開發和運維纔可以快速的知道對在哪裏和錯在哪裏。
如何應用
敏捷的形自然是很容易建立的，3-3-5-5。角色有了，體系有了，組織結構也有了。需要組織的支持自然有了一半。另一半就需要一整套體系的構建了。
最容易最快的，就是架設一套持續集成工具。加入單元測試，代碼檢查工具，引入Git分佈式管理，建立pipeline的發佈體系。
然後是持續測試，要達到持續測試，首先要做到有測試。我們剛纔講到了有單元測試，那麼如果我們的單元測試可以做到TDD甚至是BDD，那麼我們就越來越與用戶及市場銜接起來了。也可以更有效的UAT抽樣，而不是過去常常費時費力做的全量UAT。當然了，成型的測試策略也是必不可少的。甚至很多時候，測試策略是項目開始時候就需要的內容。有的成熟的團隊，就可以在此加入自動化測試，識別自動化測試的用例。
最後就是持續交付了。需要持續交付，我們很多時候就需要依賴並且藉助於雲平臺了。於是各大廠商都會推陳出新自己的雲平臺。IaaS和PaaS也是目前炒作的很熱門的主題。開發和運維就可以更放心的將精力集中在橫切面的監控和報表上了。從而把過去繁雜的設備運維交給雲平臺進行託管。也有的人習慣於在雲平臺之後再包裝一層自己的平臺，這個很多現在的互聯網廠商也喜歡這麼做。那麼這個就是現今最熱門的DevOps的SaaS平臺了。集成了軟件需求和快速交付的技術以及平臺於一身。
總結
好了，這麼些隻言片語也只是點皮毛。但是希望各位能就此了結持續交付是什麼，並且如何在現實世界運用的。每家公司最後的手段和策略都會有些差異。沒有所謂的統一的做法。也是正是現今devops和敏捷最有魅力的部分。