歡迎光臨
每天分享高質量文章

五步走戰略建立良好的持續交付流程

在Caylent[1],我們相信成功實施DevOps的關鍵之一就是持續交付(CD)和持續部署都可以完全自動化。在你的IT團隊中實現完整的CD可以讓你感受到DevOps生態系統所提供的許多優勢,同時可以確保你的團隊可以快速迭代、快速發佈代碼並減少錯誤。
通過2017年DevOps狀態報告[2]的調查結果,我們可以看到:憑藉CD和DevOps的強大功能,高效IT團隊可以比低效團隊更頻繁部署代碼(差距約46倍)。此外,你還將獲得如下優勢:
  • 更快的恢復:快24倍(較之於低效團隊)

  • 更快的交付時間:從開始code到交付的時間更短(較之於低效團隊)

  • 更低的故障率:只有0-15%的出錯概率(較之於低效團隊的31-45%)


為什麼需要持續交付?

CD旨在通過快速,可持續,小批量地部署高質量的代碼來顯著降低上線發佈風險。這個概念符合持續集成(Continuous Integration)的原則,重點在於幫助你的團隊輕鬆應對部署。
一個非常有趣的理論是CD也被證明能夠積極地提升你團隊的幸福感和敬業度。
簡而言之,更好的工作流程=高質量的代碼=高質量的產品=開心的客戶=開心的IT團隊。
持續交付 VS 持續部署

兩者之間的差異很小,而且通常這些術語可以互換使用。只有在進行分級或預生產時才進行持續交付的手動驗收測試。此時,產品所有者將手動merge代碼並將代碼推送到生產。


Docker是如何改進CD的?

Docker使我們能夠構建和分發不可變的組件,以便通過測試,預生產和生產來保留完全相同的構建組件。與Chef、Puppet或其他通用服務器構建器相比,Docker允許用戶先構建然後推送到服務器,而Chef和Puppet用戶必須實時構建和修改服務器。一旦構建完成,Docker允許你完整地移動管道中的組件。
這種優勢提高了組件的穩健性,降低了生產流水線中故障和堵塞的風險。構建一個不可改變的組件還允許我們在本地、QA、預發佈或生產環境重覆測試鏡像。回滾只需幾秒鐘,而不是幾分鐘,部署工作快速簡單。最重要的一點是,Docker進一步將服務器配置從應用程式部署中分離出來——代碼與配置解耦。


5個步驟

那麼如何使用Docker來增強CD呢?Caylent的最佳實踐可以分解為以下5個步驟:
  1. 在可能的情況下,儘量一次性構建你的軟體包。然後通過你的CD管道移動你的不變的組件,從一個倉庫到另一個倉庫進行測試。在遷移過程中,利用Docker的標記系統來管理你的鏡像,從而獲得最高的部署穩定性。

  2. 將代碼、資料庫遷移和基礎架構更改解耦為各自獨立推送。保持它們分開,同時也讓你的代碼塊盡可能小。

  3. 在每個環境中以完全相同的方式運行你的部署型別,並至少在一個與生產鏡像相同的環境中運行。使用Docker中的環境引數併在運行時傳遞環境變數,這樣不會大幅改變組件。考慮將這些更改視為基礎架構級別的更改。

  4. 作為容器構建過程的一部分——運行測試,並自動執行所有部署的測試,旨在將構建和測試結合在一起,以保持日誌檔案的完整性和易讀性。如果構建失敗,它將保留在迴圈中,而不是被push到下一個環境。

  5. 保持你的stacks和環境類似。如果你正在生產站點上運行大量的Web stacks,這可能在開發和staging過程中會遇到困難,但是你的內容交付網絡(CDN)、代理和快取等內容都應該在staging中進行複製。

雖然Docker可以很容易地使用CD部署代碼,但重要的是要遵循這些最佳實踐來正確構建、測試和部署,而不是隨心所欲,想怎麼來怎麼來。
在下篇博客中,我們將介紹Docker持續發佈的四種主要部署型別。
相關鏈接:
  1. http://caylent.com/

  2. https://puppet.com/blog/2017-state-devops-report-here

原文鏈接:http://caylent.com/a-5-step-guide-to-good-continuous-delivery/

基於Kubernetes的DevOps實踐培訓

本次培訓包含:Kubernetes核心概念;Kubernetes集群的安裝配置、運維管理、架構規劃;Kubernetes組件、監控、網絡;針對於Kubernetes API接口的二次開發;DevOps基本理念;微服務架構;微服務的容器化等,點擊識別下方二維碼加微信好友瞭解具體培訓內容

2月1日正式開課,點擊閱讀原文鏈接即可報名。
赞(0)

分享創造快樂