如何理解持續集成、持續交付、持續部署？
在學習精益思想的過程中接觸到了持續部署這個概念，查了下資料還有持續集成與持續交付。
身為沒有技術背景的產品人員，靠自己搜索信息深刻理解這三個概念實在過於痛苦（相反，產品人員對精益是很容易深刻理解且高度認同的，因為越來越明白再好的產品人員、再好的用研意識與方法都無法保證需求的正確性，前期過度的產品設計是浪費的），所以來知乎上求助一下技術達人有沒有現成的總結。如何分辨與理解這三個概念？你所在的技術團隊是否認同與實踐推廣？在實踐推廣的過程中總結出了什麼心得？這類概念是否有必要向產品同事、老闆普及推廣？在普及推廣中有過什麼事情發生？
集成是指軟體個人研發的部分向軟體整體部分交付，以便儘早發現個人開發部分的問題；
部署是代碼儘快向可運行的開發/測試節交付，以便儘早測試；交付是指研發儘快向客戶交付，以便儘早發現生產環境中存在的問題。如果說等到所有東西都完成了才向下個環節交付，導致所有的問題只能再最後才爆發出來，解決成本巨大甚至無法解決。而所謂的持續，就是說每完成一個完整的部分，就向下個環節交付，發現問題可以馬上調整。是的問題不會放大到其他部分和後面的環節。這種做法的核心思想在於：既然事實上難以做到事先完全了解完整的、正確的需求，那麼就乾脆一小塊一小塊的做，並且加快交付的速度和頻率，使得交付物儘早在下個環節得到驗證。早發現問題早返工。
舉個例子，你家裝修廚房，其中一項是鋪地磚，邊角地磚要切割大小。如果一次全切割完再鋪上去，發現尺寸有誤的話浪費和返工時間就大了，不如切一塊鋪一塊。這就是持續集成。裝修廚房有很多部分，每個部分都有檢測手段，如地磚鋪完了要測試漏水與否，線路鋪完了要通電測試電路通順，水管裝好了也要測試冷水熱水。如果全部裝完了再測，出現問題可能會互相影響，比如電路不行可能要把地磚給挖開……。那麼每完成一部分就測試，這是持續部署。全部裝修完了，你去驗收，發現地磚顏色不合意，水池太小，灶台位置不對，返工嗎？所以不如沒完成一部分，你就去用一下試用驗收，這就是持續交付。--------------------補充：從敏捷思想中提出的這三個觀點，還強調一件事：通過技術手段自動化這三個工作。加快交付速度。
最近看了一篇文章 The Product Managers Guide to Continuous Delivery and DevOps 文中對「持續集成（Continuous Integration）」、「持續交付（Continuous Delivery）」和「持續部署（Continuous Deployment）」這三個概念有很詳細的解釋。這裡借用文中的插圖，說一下我對這三個概念的理解。
持續集成
即代碼的零庫存管理，是精益生產的精~精~精~精髓。
- 代碼越早push出去，用戶能越早用到，快就是商業價值；
- 用戶越早用到就越早反饋，團隊越早得到反饋，好壞都是有價值的輸入；
- 用戶不反饋，說明我們做了用戶不想要的東西（通過用例跟蹤）或者marketing沒做好，能幫助產品市場人員調整策略；
- 代碼庫存越是積壓，就越得不到生產檢驗，積壓越多，代碼間交叉感染的概率越大，下個release的複雜度和風險越高；
- 代碼庫存越多，workflow的包袱越重，管理成本越大，說敏捷越可笑。
流水不腐，戶樞不蠹。
職業生涯沒有被要求過要區分這三個概念 ...其實應該是四個詞：持續集成、持續部署、持續交付、持續發布。
咱們把這幾個詞拆解一下：
持續 (Continuous)：不斷的獲取反饋，響應反饋。
集成 (Integration)：編譯、測試、打包；
部署 (Deployment)：應用組件或基本設施的代碼或配置變更在產品環境生效稱為「部署」；
發布 (Release)：具有業務影響的功能變化對最終用戶可見稱為「發布」。
交付 (Delivery)：可以理解為從 Deployment 到 Release 之間的階段，更多的強調的是一種能力。開發有能力頻繁的部署，業務有能力隨時發布。如何從部署到發布？使用 特性開關（Feature Toggle） 或 灰度發布（Dark Launching） 等技巧可以使我們更加頻繁地部署變更到產品環境但並不發布功能。
頻繁部署可以有效降低變更帶來的風險,同時業務負責人仍然能保持何時向最終用戶發布功能的控制。
資料引用：
- FeatureToggle
- Dark Launching https://www.facebook.com/note.php?note_id=96390263919
- https://assets.thoughtworks.com/assets/technology-radar-nov-2015-cn.pdf
1、如何分辨與理解這三個概念？
1）持續集成：集成，就是在一起：代碼commit是集成（代碼在一起），編譯是集成（邏輯在一起）；部署是集成（部署包跟環境在一起），測試是集成（功能在一起），灰度是集成（系統在一起）不斷的做集成和集成結果的修正，就是持續集成；
2）持續交付：交付：就是將最終的產品發布到線上環境，給用戶使用。持續交付描述的軟體開發，是從原始需求識別到最終產品部署到生產環境這個過程中，需求以小批量形式在團隊的各個角色間順暢流動，能夠以較短地周期完成需求的小粒度頻繁交付。頻繁的交付周期帶來了 更迅速的對軟體的反饋，並且在這個過程中，各個角色密切協作，相比於傳統的瀑布式軟體團隊，更少浪費。3）持續部署持續部署：就是持續的將需求部署到目標環境上。2、你所在的技術團隊是否認同與實踐推廣？在實踐推廣的過程中總結出了什麼心得？
我們團隊一直在做持續交付，半年做下來效果很好，每天做自動化構建打包、部署、驗收，每天都會有完成的內容，每個迭代交付的故事點趨勢是穩定向上發展的。在推廣的過程中，需要強調單元測試、功能測試等自動化測試的重要性，只有做好自動化測試，才能建立好保護機制，快速給予反饋，快速修復問題。另外自動化的工具也是必須要做的，現在市面上有不少類似的工具，國外的有Amazon Web Services (AWS)，國內的有CRP持續交付平台持續交付平台。相對來說，國內的要更貼近國內開發者，amazon的學習成本比較高。我們團隊用的是CRP持續交付平台，免費，代碼託管、自動化構建、部署等都做的比較完整。3、這類概念是否有必要向產品同事、老闆普及推廣？在普及推廣中有過什麼事情發生這塊內容是需要不斷的和同事和老闆推廣的，因為持續交付最終的目的是快速迭代、快速反饋，不斷的改進。這樣可以幫助老闆和產品提高交付能力的，也可以幫助研發團隊提高效率。
推廣還是會有困難的，國內能做到持續交付的團隊並不算多，很多都知道好處，但是單元測試和自動化功能測試等內容會需要開發投入不少精力，首先還是需要說服研發的負責人贊同你的觀念哦。在解釋這三個概念之前，我先舉個例子。
譬如說，你開了一家公司，雇了很多碼農在一起寫代碼。
你說，要用 Gitlab 做代碼管理。當一個碼農在自己的開發機上寫好代碼之後，要合併到主分支里，他首先要發起一個 Merge Request（MR），這會在一個特定伺服器上觸發一次對他提交的代碼的檢查，包括代碼格式檢查、依賴關係檢查以及單元測試等一系列檢查，等通過了全部檢查，他就可以將代碼合併到主分支，否則他需要按照錯誤提示進行修改，然後發起新一輪的檢查。然後呢，每天晚上 10 點會有一個定時任務從主分支上拿最新的代碼，進行編譯打包，最後將打包好的程序推送到一個伺服器上保存，這個伺服器叫做 Artifact Repository。
你又說，要每天將當天打包好的程序部署到測試環境上。也就是說，一個碼農晚上 10 點之前提交了代碼，那他第二天就可以在測試環境上看到自己新提交的代碼的效果了。
你還說，每一個月要在生產環境上部署一個穩定的發布版本。
以上三段內容是一個軟體從開發到部署的流程的簡單描述，也分別對應持續集成、持續交付以及持續部署。
1、持續集成（Continuous Integration）
持續集成就是把多個碼農寫的代碼集成到同一個分支，然後經過編譯、測試、打包之後將程序保存到 Artifact Repository 里。
2、持續交付（Continuous Delivery）
持續交付就是定時地、自動地從 Artifact Repository 將最新的程序部署到測試環境里。
3、持續部署（Continuous Deployment）
持續部署就是定時地、自動地將過去一個穩定的發布版本部署到生產環境里。
很明顯，集成、交付和部署是軟體開發到發布流程中的不同階段。那所謂的持續是相對於過去的流程提出的。過去的流程是所有人寫好代碼之後再進行合併，然後再進行測試，最後再發布。這種流程會把風險堆到軟體發布前的最後階段。那持續的概念就是，做一點就馬上遞交給下一個流程，這樣能夠儘早地發現並解決問題。
補充，持續交付和持續部署是不是相同的概念，一直有爭議。不過我認為，只要在你們的團隊內部達成一致就可以了，不用太糾結於是不是同一個概念。
剛好最近在看相關資料，分享一下
持續集成
持續交付、持續部署
將持續集成擴充到部署到生產環境就是持續交付和持續部署的概念，二者的區別，看圖
持續集成的核心思想是切分任務，縮短每次迭代的間隔（對應的是細小任務，同時也是對應的細小時間），然後持續集成的必要條件是要用自動化的方式替代那些重複的勞動，測試，部署，分析等。如果不能做到自動化，持續集成最好還是一個想法，不然會把團隊拖死。
持續集成、持續交付、持續部署。個人理解就是 提前發現系統問題，提前暴露問題，這比在開發後期發現問題處理的成本低很多。很多時候 一開始的需求在開發的過程中會有所變化的，或在需求分析不充分的情況下 也能在開發過程中即時發現問題。
關於這個問題，有一篇文章特別通俗易懂，先上鏈接。轉自阮一峰老師的blog：持續集成是什麼？ - 阮一峰的網路日誌
以下是原文：
互聯網軟體的開發和發布，已經形成了一套標準流程，最重要的組成部分就是持續集成（Continuous integration，簡稱CI）。
本文簡要介紹持續集成的概念和做法。
一、概念
持續集成指的是，頻繁地（一天多次）將代碼集成到主幹。
它的好處主要有兩個。
（1）快速發現錯誤。每完成一點更新，就集成到主幹，可以快速發現錯誤，定位錯誤也比較容易。
（2）防止分支大幅偏離主幹。如果不是經常集成，主幹又在不斷更新，會導致以後集成的難度變大，甚至難以集成。
持續集成的目的，就是讓產品可以快速迭代，同時還能保持高質量。它的核心措施是，代碼集成到主幹之前，必須通過自動化測試。只要有一個測試用例失敗，就不能集成。
Martin Fowler說過，"持續集成並不能消除Bug，而是讓它們非常容易發現和改正。"
與持續集成相關的，還有兩個概念，分別是持續交付和持續部署。
二、持續交付
持續交付（Continuous delivery）指的是，頻繁地將軟體的新版本，交付給質量團隊或者用戶，以供評審。如果評審通過，代碼就進入生產階段。
持續交付可以看作持續集成的下一步。它強調的是，不管怎麼更新，軟體是隨時隨地可以交付的。
三、持續部署
持續部署（continuous deployment）是持續交付的下一步，指的是代碼通過評審以後，自動部署到生產環境。
持續部署的目標是，代碼在任何時刻都是可部署的，可以進入生產階段。
持續部署的前提是能自動化完成測試、構建、部署等步驟。它與持續交付的區別，可以參考下圖。
（圖片來源）
四、流程
根據持續集成的設計，代碼從提交到生產，整個過程有以下幾步。
4.1 提交
流程的第一步，是開發者向代碼倉庫提交代碼。所有後面的步驟都始於本地代碼的一次提交（commit）。
4.2 測試（第一輪）
代碼倉庫對commit操作配置了鉤子（hook），只要提交代碼或者合併進主幹，就會跑自動化測試。
測試有好幾種。
- 單元測試：針對函數或模塊的測試
- 集成測試：針對整體產品的某個功能的測試，又稱功能測試
- 端對端測試：從用戶界面直達資料庫的全鏈路測試
第一輪至少要跑單元測試。
4.3 構建
通過第一輪測試，代碼就可以合併進主幹，就算可以交付了。
交付後，就先進行構建（build），再進入第二輪測試。所謂構建，指的是將源碼轉換為可以運行的實際代碼，比如安裝依賴，配置各種資源（樣式表、JS腳本、圖片）等等。
常用的構建工具如下。
- Jenkins
- Travis
- Codeship
- Strider
Jenkins和Strider是開源軟體，Travis和Codeship對於開源項目可以免費使用。它們都會將構建和測試，在一次運行中執行完成。
4.4 測試（第二輪）
構建完成，就要進行第二輪測試。如果第一輪已經涵蓋了所有測試內容，第二輪可以省略，當然，這時構建步驟也要移到第一輪測試前面。
第二輪是全面測試，單元測試和集成測試都會跑，有條件的話，也要做端對端測試。所有測試以自動化為主，少數無法自動化的測試用例，就要人工跑。
需要強調的是，新版本的每一個更新點都必須測試到。如果測試的覆蓋率不高，進入後面的部署階段後，很可能會出現嚴重的問題。
4.5 部署
通過了第二輪測試，當前代碼就是一個可以直接部署的版本（artifact）。將這個版本的所有文件打包（ tar filename.tar * ）存檔，發到生產伺服器。
生產伺服器將打包文件，解包成本地的一個目錄，再將運行路徑的符號鏈接（symlink）指向這個目錄，然後重新啟動應用。這方面的部署工具有Ansible，Chef，Puppet等。
4.6 回滾
一旦當前版本發生問題，就要回滾到上一個版本的構建結果。最簡單的做法就是修改一下符號鏈接，指向上一個版本的目錄。
五、參考鏈接
- Gergely Nemeth, Continuous Deployment of Node.js Applications
- Codeship, Continuous Integration Essentials
（完）
一個效率雲的研發工具文章，裡面提到了持續集成和交付iPipe。原文在這裡，有興趣的可以看看。https://mp.weixin.qq.com/s?__biz=MzIxMzExMjU0MQ==mid=2880080540idx=1sn=a509c62eff3a9530c165a716c9f7e9e4scene=1srcid=0423m0iulU9BOAz4zAFgZ3xLpass_ticket=lGgFOwz9LpwqSYiOvoeQuPoFz4qs3C8mFHcUQfQmxJuAgP88pi%2F%2FZw%2FuROkDwO66#rd
就是在 任何時候，對外都能提供可以分發、安裝、使用的新版本
這要求：1、系統的總體框架、主幹 成熟、穩定、簡潔2、更新、發布、安裝、運行、重置 簡單方便3、任何改進、改動都在獨立分支進行，並能快速合併回主版本4、重新生成發布包 能隨時、自動、快速進行舉一個具體例子：如果必須有客戶端，必須是綠色的，而且能自動根據後台設置進行自我更新與後台的交互通過 服務端的IP+埠 進行訪問，協議最好是http(s)如果涉及資料庫，不能直接連接，而是通過應用伺服器（web app）中轉另外一個可以增強團隊信心，據說facebook 的工程師就為他們的這種能力驕傲
持續交付是在用戶與產品團隊(包括客戶或者Product Owner)之間建立緊密的反饋環，即:通
過持續交付新的軟體版本，驗證新的想法和軟體的改動，並能衡量這些改動對收入的影響。持續交付(Continuous Delivery)是一系列的開發實踐方法，用來確保讓代碼能夠快速、安全的部
署到產品環境中。它通過將每一次改動都提交到一個模擬產品環境中，使用嚴格的自動化測試，確保業務應用和服務能符合預期。因為使用完全的自動化過程來把每個變更自動的提交到測試環境中，所以當業務開發完成時，你有信心只需要按一次按鈕就能將應用安全的部署到產品環境中。關於持續集成的講座現在也越來越多，京東的大牛也在線直播傳授經驗，所有搞測試的小夥伴可以借鑒經驗。
主題：
1.從0到1實現持續集成；
2.持續集成工具建設實踐；
3.持續集成落地及應用。
內容要點：
業務量成倍的增長，軟體測試和質量人員工資量成倍增長。為了實現快速迭代，敏捷軟體開發理論已經深入人心。
在不斷迭代的業務開發周期中，如何來保障系統質量和提升研發測試效率呢？
持續集成是個很好的實踐，能夠通過自動化的流程把質量內置到軟體研發的各個節點。
推薦閱讀：