我們無數次聽到這類的抱怨：管理層不會去做、**太過混亂、專案太大、有太多的監管障礙。由此種種，對於許多企業來說，在持續整合/持續部署的道路已步履蹣跚，但不得不說，仍有一部分企業做到了。
下圖是實施持續部署前的狀態：
該項目的壓力很大。皆**於它純手動發布，脆弱的測試，頻繁的宕機以及問題不斷。這個專案團隊大約由16人組成，但他們對修改現有**並沒有什麼信心。
他們知道需要做什麼，所以他們設定了以下目標：
減少問題
減少週期時間
提高生產效率
提高積極性
他們採取的方法是：整體修改，建立乙個**並新增乙個服務，然後不斷地增加服務，直到這個整體被取代。
他們以如下原則來指導這次持續部署之旅：
應用strangler模式
使用api的第乙個方法
為每個domain設定乙個服務
遷移單個頁面
建立負載平衡器後的服務
訪問遺留資料庫
實施持續部署
運用docker
開發前端作為服務
從持續整合開始：開發和構建/測試，每次都產生乙個工件。持續交付：從構建/測試到驗收再到生產; 進入生產階段是乙個手動的過程，但**是可部署的。最後，當整個流程實現自動化時，就達到持續部署的目標了。
關於持續部署的優點有以下幾點：
小步推進
早期反饋
減少迴圈時間
風險減低
實驗室環境
michiel的專案落地後，他總結了幾個實現持續部署的關鍵方面，如下：
直接提交到master。沒有分支。我們都不希望延遲整合，且濫用版本控制功能分離。另外，分支上的所有內容都會增加衝突和延遲整合的風險。
每一次提交都要投入生產。
使用配對編碼進行**審查。這需要約束，但所有的開發人員都需要成對進行，混合搭配有經驗的開發人員。
嚴把質量關。確保大量測試和**覆蓋率。
功能切換和a/b test。確保一部分開發人員可以看到版本資訊，一部分人不能看到，並促進a / b測試。但一定要把人員數量保持在乙個合理的範圍內。
dashboards。顯示是部署的關鍵，通過它我們可以獲取很多資訊，比如kpi、構建時間、頁面載入時間、訪問者數量、a/b test結果，等等。
devops。心態是一種文化；dev和ops之間並無太多隔閡。團隊內部都擁有所有權，但這並不意味著每個人都知道所有事。
自動化可重複的事。如果同樣的事你需要做兩次，那說明你已經浪費了時間。
連續測試。使用單元測試和冒煙測試來檢視服務是否存在，並持續監控。探索性的測試很重要，因為你將繼續測試最關鍵的路徑。
管道作為**。自動化流水線。最後，部署起來是這樣的：
反饋 –及時的反饋很重要，因為devops是在此基礎之上建立的。舉個例子，michiel這個專案上有乙個閃爍的紅光，這表示失敗。所以不管什麼時候，及時反饋都是工作中的第一要事。
michiel的專案時間跨度有一年之久。最終，他們將每個服務的構建時間減少到不到10分鐘，顯著改善了頁面載入時間，同時他們自己也增加了自信心和加快了速度等。明白了團隊需要接受和改變的重要性的真理。同時，他們還了解到，與業務優先順序一致是關鍵，確保擁有一定工作經驗的員工亦是至關重要，限制功能切換同樣至關緊要。
總的來說，michiel和他的團隊實現了持續部署。在他的演講結束時，michiel也提到了他的無奈，想要取代的遺留系統仍在服務中。所以持續部署這條路還很長，但值得去做。
推薦閱讀：
如何為微服務選擇正確的資料庫
為什麼你的devops會失敗？
關於ghostcloud
ghostcloud（中文名：精靈雲）坐落於成都天府軟體園，是成都高新區重點扶持企業，國內首批從事容器虛擬化研發的企業，是西南地區唯一一家基於docker的雲計算服務商，為企業級行業客戶提供針對網際網路化、私有雲管理平台、大資料業務基礎架構的平台服務。
ghostcloud因容器技術而生，以最新容器技術docker為基礎，為適應不同行業客戶需求，全自主研發了一套排程引擎框架newben，且全方位適配kubernetes主流開源排程引擎，也是國內率先實現雙排程引擎的企業，是一流的企業級容器雲服務專家。ghostcloud推出了企業級容器雲paas／caas平台，命名為ecos（enterprisecontainer operation system）。ghostcloud將ecos平台與微服務／devops相融合，運用至企業it系統的全生命週期的開發、測試、運維及發布流程中，致力於為多個領域企業向「網際網路+」轉型提供針對網際網路化、私有雲管理平台、大資料業務基礎架構的平台服務，幫助企業級客戶降低成本、提公升效率、簡化運維及產品部署，並提公升系統的可靠性和安全性。
Coolblue的持續部署
coolblue 的技術開拓者paul de raaij提出，持續部署會得到更強的責任感和更好的部署質量。規範預防 庫混亂，自動化檢查很合適完成冗長而無聊的檢查，人工檢查很合適去檢查 的邏輯和用法實際上是否成立。de raaij 寫了一篇博文 我們軟體的持續部署 在文章中他解釋了coolblue是如...
Instgram的持續部署
我們每天都要在instagram改進後台 30到50次，但工程師們只在極少數的情況下需要將這些修改上傳到主伺服器上進行部署，但大部分情況下 可以自我改進以達到預期的效果，無須人為干涉。這可能聽起來不可思議，但持續部署早已開始應用。這篇文章將講述我們是如何實現持續部署，並讓它協調地執行。為什麼這麼做？...
持續整合 持續交付 持續部署
持續整合 持續整合強調開發人員提交了新 之後，立刻進行構建 單元 測試。根據測試結果，我們可以確定新 和原有 能否正確地整合在一起。持續交付 持續交付在持續整合的基礎上，將整合後的 部署到更貼近真實執行環境的 類生產環境 production like environments 中。比如，我們完成單...