你準備好在CI/CD中實現持續部署的自動化了嗎?

語言: CN / TW / HK

你準備好在CI/CD中實現持續部署自動化了嗎?

實現從持續交付到持續部署的飛躍需要正確的技能、實踐和工具。使用這個五點檢查表來準備啟動。

許多公司都急於實施持續整合和持續交付(CI/CD)管道,以簡化其軟體開發工作流程。而採取額外步驟實現持續部署自動化的公司則少之又少,持續部署是一種使用CI/CD管道將變化持續推送到生產中的做法。這是可以理解的。

一想到每天或每小時將程式碼推送到生產中的頻率,我就感到不寒而慄。事實上,幾年前,我寫過一篇關於持續部署的弊端的文章。另一篇文章"負責任的開發團隊應該在什麼時候增加部署頻率",挑戰了更頻繁的部署是更好的假設。

然而,在過去的幾年裡發生了很多變化,更多的devops團隊正在接受技能、實踐和工具,以實現高質量和可靠部署的自動化。本文解釋了持續交付和持續部署之間的區別,然後提出了devops團隊在CI/CD管道中實現持續部署自動化之前應該做的五件事。

持續交付與持續部署

Capgemini公司的敏捷和devops領導人Kulbir Raina分享了一個定義,幫助我們區分持續交付和持續部署。他說:"持續交付是軟體釋出直至生產的端到端自動化流程,而持續部署是通過預先測試的流程將該流程中的軟體包推入生產後的持續整合的自動化流程"。

生產部署的自動化有更多的風險,因為其結果會影響業務、客戶和終端使用者。如果一個devops團隊決定自動部署,部署過程必須包括持續測試和強大的錯誤處理。否則,部署可能會產生效能問題、不可靠的系統、安全漏洞,以及在生產中發現的缺陷。

SPR的軟體工程總監Mike Saccotelli補充說:"一個組織運營持續交付模式與持續部署模式之間的主要區別在於其構建和部署流程的成熟度和複雜程度"。

Devops團隊可以使用以下檢查表,為升級CI/CD管道以實現持續部署做準備。

1.評估商業利益

持續部署,作為一項原則,可以應用於許多應用程式,甚至可以應用於最規範的行業。Buildkite的聯合創始人兼聯合執行長Tim Lucas說:"持續部署可以在每個專案中採用,最好的組織設定目標,將盡可能多的專案轉移到這種模式。即使在金融和監管行業,大多數專案都可以採用這種模式。我們甚至看到自駕車公司在做持續部署。"

雖然devops團隊可以在許多專案中實施持續部署,但問題是,它在哪些方面能提供強大的商業案例和顯著的技術優勢?頻繁部署功能和修復的專案,以及現代化的架構簡化了自動化的專案,是更有希望過渡到持續部署。

2.為開發團隊做好準備

Lucas分享了一些先決條件,這些條件應該是轉向持續部署模式之前軟體開發過程的一部分。他說,"持續部署是真正的敏捷性,是從程式碼變更到生產的最快方式。它要求始終保持主分支處於可發貨狀態,自動化測試,以及你可以信任和有信心的高質量工具。"

希望實現持續部署自動化的開發人員的一些開發責任和紀律包括:

Saccotelli補充說:"持續部署的前提是開發團隊對高質量的程式碼有一個更成熟的理解,這樣這個過程才能成功。如果程式碼很差或者沒有經過測試,那就會產生一個不可靠的系統,並迅速將錯誤和漏洞推到生產中"。

3.為運營團隊做好準備

因此,CI/CD管道執行並將新程式碼部署到生產中。這是否意味著devops團隊已經脫身,他們的工作已經完成,每個人都可以繼續下一個版本?

不是那麼快。儘管開發人員做了很多工作,以確保構建不會中斷,自動化程式碼測試,並控制在生產中啟用哪些程式碼,但仍然存在一些風險,即部署可能導致生產問題。監控業務服務、應用程式和系統是devops中的一項運營職責,他們支援持續部署的能力在啟用部署自動化之前就已經開始了。最佳實踐包括以下內容:

4.跨團隊和工具整合ITSM和工作流程

我們還沒有完成,即使建立了所有的開發和運營能力。假設devops團隊提交了程式碼,持續部署將變化轉移到生產中,並且應用效能監控工具正在執行。如何快速提醒合適的開發團隊成員,以便他們能夠分流事件,調查根本原因,並迅速解決任何問題?

Lucas分享說,在轉向持續部署時,"不穩定的測試是最大的風險"。他指出,不可靠的CI/CD工具、糟糕的生產監控和隨叫隨到的做法,以及工程和IT之間缺乏真正的夥伴關係是進一步的風險。

如果沒有監控、AIOps、IT服務管理(ITSM)、敏捷和通訊工具之間的工作流程和整合,開發團隊響應和解決問題的時間可能會落後於其部署速度。這種差距會造成壓力,並削弱開發和運營之間的夥伴關係。最好的做法是確保IT工具和工作流程的整合,因此開發團隊可以跟上持續部署所產生的任何問題。

5.定義基於風險的決策門和關鍵績效指標

Copado公司產品營銷總監Kristin Baskett提供了持續部署中需要的一個關鍵因素。她說:"雖然魯莽的自動化會阻礙系統,但正確的自動化可以幫助組織實現他們所需的靈活性和一致性,從而真正從devops中受益。當開發人員能夠自動整合程式碼時,協作就會得到改善。而通過投資測試自動化和質量門,組織可以更快地進行創新,並減少風險"。

除了測試自動化,Baskett提到實施質量門,應該擴充套件到其他風險評估。當構建觸發持續部署時,質量門實施業務規則,以確定哪些部署可以進入生產,哪些可能需要合規性審查或管理層簽字。

其他支援持續部署的最佳管理實踐包括制定devops關鍵績效指標(KPI),正式確定反饋迴路,以及制定溝通策略

持續部署可以產生許多業務和技術上的好處,但有紀律的開發團隊和IT組織應確保在使用自動化來增加部署頻率之前,最佳實踐和工具已經到位。