?許多公司都爭先恐后地實施持續集成和持續交付(CI/CD)管道，以簡化他們的軟件開發工作流程。很少有人采取額外的步驟來自動化持續部署，這是一種使用CI/CD管道將更改持續推送到生產中的做法。可以理解的。

每天或每小時頻繁地將代碼推送到生產環境的想法讓我不寒而栗。

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

持續交付與持續部署

Capgemini的敏捷和開發運營負責人KulbirRaina分享了一個有助于我們區分持續交付和持續部署的定義。他說：“持續交付是軟件發布到生產的端到端自動化流程，而持續部署是通過預先測試的流程將流程中的軟件包推送到生產后持續集成的自動化流程。”

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

SPR軟件工程總監MikeSaccotelli補充說：“運行持續交付模型與持續部署模型的組織之間的主要區別在于其構建和部署過程的成熟度和復雜程度。”

Devops團隊可以使用以下清單來準備升級CI/CD管道以進行持續部署。

1. 評估商業利益

作為一項原則，持續部署可以應用于許多應用程序，甚至可以應用于最受監管的行業。Buildkite的聯合創始人兼聯合首席執行官TimLucas說：“每個項目都可以采用持續部署，最好的組織設定目標，將盡可能多的項目轉移到這種模式。即使在金融和受監管的行業，大多數項目都可以采用這種模式。我們甚至看到自動駕駛汽車公司進行持續部署。”

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

2. 準備開發團隊

Lucas分享了在遷移到持續部署模型之前應該成為軟件開發過程一部分的一些先決條件。他說：“持續部署是真正的敏捷性，是從代碼更改到生產的最快方式。它需要始終將主分支保持在可交付狀態、自動化測試以及您可以信任和有信心的高質量工具。”

希望自動化持續部署的開發人員的一些開發職責和規則包括：

• 使用足夠的代碼覆蓋率進行持續測試，以確保更改不會產生新的缺陷。
• 用于測試安全性、性能和其他代碼質量問題的靜態和動態代碼分析工具。
• 對左移安全實踐的承諾，包括圍繞API安全的最佳實踐。
• 圍繞應用程序和微服務的可觀察性標準。
• 功能標記，以便可以打開和關閉新功能，或控制給部分用戶。

Saccotelli補充說：“持續部署的前提是開發團隊對質量代碼有更成熟的理解，這樣這個過程才能成功。如果代碼很差或未經測試，那將創建一個不可靠的系統，并迅速將錯誤和漏洞推向生產環境。”

3.準備運營團隊

因此CI/CD管道運行并將新代碼部署到生產環境。這是否意味著devops團隊很清楚，他們的工作已經完成，每個人都可以進入下一個版本？

沒那么快。盡管開發人員為確保構建不會中斷、自動化代碼測試以及控制在生產中啟用哪些代碼所做的所有工作，但仍然存在一些部署可能導致生產問題的風險。監控業務服務、應用程序和系統是devops中的一項運營職責，他們支持持續部署的能力早在啟用部署自動化之前就開始了。最佳實踐包括以下內容：

• 使用基礎架構即代碼和容器來確保開發、測試、生產和其他環境之間的基礎架構配置一致。
• 使用應用程序和系統級別的監控工具，這些工具還可以加載和分析由應用程序和微服務創建的可觀察性數據。
• 選擇一個AIOps平臺，該平臺在從應用程序到微服務和數據存儲的整個堆棧中集成監控、警報和可觀察性數據，并將事件關聯到可管理的事件中。
• 設置金絲雀版本以控制新部署的切換和流量，并降低更難的切換策略的風險。
• 擁有一套強大的安全工具，包括API網關、Web應用程序防火墻、容器安全、威脅監控和敏感數據監控，以降低高度動態應用環境中的風險。

4. 跨團隊和工具集成ITSM和工作流

即使已經建立了所有開發和運營能力，我們還沒有完成。假設devops團隊提交代碼，持續部署將更改轉移到生產中，并且應用程序性能監控工具正在運行。正確的devops團隊成員多久會收到警報，以便他們可以對事件進行分類、調查根本原因并快速解決任何問題？

Lucas分享說，在轉向持續部署時，“不穩定的測試是第一大風險”。他列舉了不可靠的CI/CD工具、糟糕的生產監控和隨叫隨到的做法，以及工程和IT之間缺乏真正的合作伙伴關系作為進一步的風險。

如果沒有監控、AIOps、IT服務管理(ITSM)、敏捷和通信工具之間的工作流和集成，devops團隊響應和解決問題的時間可能會落后于其部署速度。這種差距可能會造成壓力，并削弱開發和運營之間的伙伴關系。最佳實踐是確保集成IT工具和工作流程，以便開發運維團隊能夠跟上持續部署產生的任何問題。

5. 定義基于風險的決策門和KPI

Copado產品營銷總監KristinBaskett提供了持續部署所需的一個關鍵要素。她說：“雖然魯莽的自動化可能會阻礙系統，但正確的自動化可以幫助組織實現真正從devops中受益所需的靈活性和一致性。當開發人員可以自動集成代碼時，協作就會得到改善。通過投資于測試自動化和質量門控，組織可以更快地進行創新，同時降低風險。”

除了測試自動化之外，Baskett還提到了實施應該擴展到其他風險評估的質量門。當構建觸發持續部署時，質量門會實施業務規則，以確定哪些部署可以投入生產，哪些可能需要合規審查或管理簽字。

支持持續部署的其他最佳管理實踐包括開發devops關鍵績效指標(KPI)、形式化反饋循環和制定溝通策略。

持續部署可以產生許多業務和技術優勢，但紀律嚴明的DevOps團隊和IT組織應確保在使用自動化提高部署頻率之前擁有最佳實踐和工具。?