【51CTO.com快譯】將您的開發團隊轉變為持續交付模式是一項比較艱巨工作。正如自動化持續交付過程本身那樣，您應該分階段進行，而不要一次性更改所有的方面。同時您要有回滾方案，以備各種突發問題的出現。雖然此過程***挑戰性，但一旦成功實現，則會使您能夠更快地響應客戶的各種需求，并能使您的產品最終在市場上更具競爭力。

自動化的好處

自動化的諸多好處包括：

• 將上市的時間從按周計算和按月計算，縮短為按天或小時計算。
• 更少的軟件錯誤意味著降低了市場的風險。
• 更少的時間花費在運維上，也減少了軟件開發的成本。
• 更強大的開發團隊。

一旦成功構建了自動化的pipeline，那么在將整個開發環境進行切換之前，您就可以使用此處所羅列的一些***實踐來微調自己的pipeline。

我們在此將***實踐分為三大類：

1. 軟件架構 – 各種服務和產品的整體架構，為您構建pipeline的模式和團隊與之交互的方式定下基調。
2. 自動化模式 - 自動化和各種測試的策略。
3. 公司文化 - 團隊組織、透明度和責任。

1.軟件架構

采用微服務 

為了實現真正的敏捷和自動化pipeline，我們建議您將產品構建為各種微服務。

如果您對為何需要微服務還存有疑問的話，請參閱：《什么是微服務？》，和《從AWS角度介紹微服務》。

除非您是從頭開始創建一個應用程序，否則重新構建整個應用程序將是一項非常艱巨的任務。如果您手頭已有現成的系統，那么***是逐步地切換到微服務之中。例如，您可以采用由Martin Fowler開發strangler模式。該模式保證了將單一的體系結構提升至微服務的過程中，您仍可使用并存的現有業務系統。

在這種模式下，您的關鍵任務系統不但能夠得以維持，并且新的架構也會圍繞著它被構建出來。隨著時間的推移，舊系統會逐漸地被新架構所取代，而非一次性全部轉換過去。

2.自動化模式

實施GitOps

為了優化平均恢復時間（MTTR，Mean Time to Recovery），您應該實施GitOps。

GitOps的運行依靠將Git（譯者注：Git是一個開源的分布式版本控制系統）作為聲明式基礎架構和應用程序的“數據源（source of truth）”。當對于Git的更改發生時，自動化交付的pipeline會將變更部署到您的基礎架構之中。

您的基礎架構和應用程序代碼不僅具有了數據源，而且在發生災難時，您的開發團隊還能夠從Git中快速地恢復基礎架構，從而將MTTR從小時級別降低到分鐘級別。

有關GitOps的更多信息，請參閱《用拉式請求的各種操作》和《GitOps：Kubernetes實現高速持續集成與持續交付（CI/CD）》。

注重安全的自動化

在與大型團隊協作和將各種自動化pipeline連到Kubernetes的時候，您需要重點考慮自己集群里的各種安全憑證。為了能將更新部署到群集之中，您必須將證書保存在某處。在理想情況下，這些證書應該保存在集群的內部。但是如果需要被放在外面的話，它們至少應該被保存在諸如Vault這樣的庫中。

推/拉式模式

由于您的持續集成能從持續交付中分離出來，因此拉式自動化pipeline提供了更好的安全性。如今大多數CI/CD工具都使用的是推送模式。基于推式意味著代碼從CI系統開始經過pipeline，然后需要通過一系列編碼腳本，或手動使用'kubectl'將變更推送到Kubernetes群集之中。總體而言，如果不小心使用的話，CI反而會成為您系統的一個入口。

像Weave Cloud的拉模式就依賴于兩個關鍵的組件：一個是用于監控鏡像注冊表的部署性自動化器（Deploy Automator），另一個是位于群集之中，以維護其狀態的部署性同步器（Deploy Synchronizer）。 

由于Weave Cloud部署針對的是如下方面，因此拉式方法更為安全：

• 基于角色訪問控制（RBAC）的相關策略與安全性，僅執行Kubernetes所允許的操作。信任關系由群集所共享，并非被單獨地掌握。
• 本地綁定所有Kubernetes對象，并獲悉操作是否已完成或需要重試。

不必每次都從頭開始重建鏡像

在通過pipeline去運行各種更新時，為了節省寶貴的時間，您不必每次都去重建鏡像。您只需一次性構建容器的鏡像，然后通過每個測試序列/環境將其“推廣”出去。如果您使用的是GitOps，那么就可以在Git中對各種聲明性配置文件進行更改，或者直接使用Weave Cloud部署的各種操作。

對發布進行解耦部署

在將產品發布給客戶之前，請添加一個部署的階段，以進行冒煙測試，甚至是一些更多類型的測試，如：藍綠部署、金絲雀測試、或A/B測試。

值得注意的是：我們應當在概念上理解“部署”與“發布”之間的區別。部署是指軟件已經通過了測試并被安裝到了特定環境之中；而發布則是將這些更改最終真實地落實并推送到最終用戶的手中。

衡量pipeline的成功

請建立并跟蹤pipeline里的那些關鍵性的指標。您可以將開始自動化之前的情況和之后的結果做比較，主要包括如下方面：

• 部署頻率 - 每天完成的部署數量。
• 變更的交付周期 - 部署一次變更所需要的交付時間。
• 平均恢復時間（MTTR） - 在災難發生時，恢復應用所需要的時間。
• 變更失敗率 - 以正常運行時間的百分比來表示宕機的時間。

3.持續交付的企業文化

創建一種開放且不抱怨的文化

請圍繞著自動化過程增加企業透明度。通過允許開發人員犯錯，從而激勵他們勇于解決和糾正各種過程中所產生的偏差。一旦自動化被建立起來，開發人員需要對pipeline擁有完全的所有權，以便在測試失敗發生時，代碼變更能夠被及時地進行回滾。

每個人都為構建承擔責任

在完全的自動化pipeline模式下，任何人都應該能夠去診斷并解決構建中出現的問題。這不僅能夠產生更多自創的軟件開發流程，還會促進整個組織內產生更好的團隊協作。

***的建議

眾所周知，易于出錯的手動式部署往往會增加軟件發布的風險和成本，同時也會降低公司在其業務領域的競爭力。因此，雖然實施自動化的持續交付pipeline會是一項艱巨的任務，但它最終將被證明是企業值得付出的“陣痛”。

原文標題：Best Practices for Continuous Delivery ，作者：Anita Buehrle 

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】