在Caylent[1]，我們相信成功實施DevOps的關鍵之一就是持續交付（CD）和持續部署都可以完全自動化。在你的IT團隊中實現完整的CD可以讓你感受到DevOps生態系統所提供的許多優勢，同時可以確保你的團隊可以快速迭代、快速釋出程式碼並減少錯誤。
透過2017年DevOps狀態報告[2]的調查結果，我們可以看到：憑藉CD和DevOps的強大功能，高效IT團隊可以比低效團隊更頻繁部署程式碼（差距約46倍）。此外，你還將獲得如下優勢：
CD旨在透過快速，可持續，小批次地部署高質量的程式碼來顯著降低上線釋出風險。這個概念符合持續整合（Continuous Integration）的原則，重點在於幫助你的團隊輕鬆應對部署。
一個非常有趣的理論是CD也被證明能夠積極地提升你團隊的幸福感和敬業度。
簡而言之，更好的工作流程=高質量的程式碼=高質量的產品=開心的客戶=開心的IT團隊。
兩者之間的差異很小，而且通常這些術語可以互換使用。只有在進行分級或預生產時才進行持續交付的手動驗收測試。此時，產品所有者將手動merge程式碼並將程式碼推送到生產。
Docker使我們能夠構建和分發不可變的元件，以便透過測試，預生產和生產來保留完全相同的構建元件。與Chef、Puppet或其他通用伺服器構建器相比，Docker允許使用者先構建然後推送到伺服器，而Chef和Puppet使用者必須實時構建和修改伺服器。一旦構建完成，Docker允許你完整地移動管道中的元件。
這種優勢提高了元件的穩健性，降低了生產流水線中故障和堵塞的風險。構建一個不可改變的元件還允許我們在本地、QA、預釋出或生產環境重覆測試映象。回滾只需幾秒鐘，而不是幾分鐘，部署工作快速簡單。最重要的一點是，Docker進一步將伺服器配置從應用程式部署中分離出來——程式碼與配置解耦。
那麼如何使用Docker來增強CD呢？Caylent的最佳實踐可以分解為以下5個步驟：
-
在可能的情況下，儘量一次性構建你的軟體包。然後透過你的CD管道移動你的不變的元件，從一個倉庫到另一個倉庫進行測試。在遷移過程中，利用Docker的標記系統來管理你的映象，從而獲得最高的部署穩定性。
-
將程式碼、資料庫遷移和基礎架構更改解耦為各自獨立推送。保持它們分開，同時也讓你的程式碼塊盡可能小。
-
在每個環境中以完全相同的方式執行你的部署型別，並至少在一個與生產映象相同的環境中執行。使用Docker中的環境引數併在執行時傳遞環境變數，這樣不會大幅改變元件。考慮將這些更改視為基礎架構級別的更改。
-
作為容器構建過程的一部分——執行測試，並自動執行所有部署的測試，旨在將構建和測試結合在一起，以保持日誌檔案的完整性和易讀性。如果構建失敗，它將保留在迴圈中，而不是被push到下一個環境。
-
保持你的stacks和環境類似。如果你正在生產站點上執行大量的Web stacks，這可能在開發和staging過程中會遇到困難，但是你的內容交付網路（CDN）、代理和快取等內容都應該在staging中進行複製。
雖然Docker可以很容易地使用CD部署程式碼，但重要的是要遵循這些最佳實踐來正確構建、測試和部署，而不是隨心所欲，想怎麼來怎麼來。
在下篇部落格中，我們將介紹Docker持續釋出的四種主要部署型別。
-
http://caylent.com/
-
https://puppet.com/blog/2017-state-devops-report-here
原文連結：http://caylent.com/a-5-step-guide-to-good-continuous-delivery/
本次培訓包含：Kubernetes核心概念；Kubernetes叢集的安裝配置、運維管理、架構規劃；Kubernetes元件、監控、網路；針對於Kubernetes API介面的二次開發；DevOps基本理念；微服務架構；微服務的容器化等，點選識別下方二維碼加微信好友瞭解具體培訓內容。
長按二維碼向我轉賬
![]()
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球