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

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

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

持續(xù)交付與持續(xù)部署

Capgemini的敏捷和開發(fā)運營負責人KulbirRaina分享了一個有助于我們區(qū)分持續(xù)交付和持續(xù)部署的定義。他說：“持續(xù)交付是軟件發(fā)布到生產(chǎn)的端到端自動化流程，而持續(xù)部署是通過預(yù)先測試的流程將流程中的軟件包推送到生產(chǎn)后持續(xù)集成的自動化流程?！?/p>

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

SPR軟件工程總監(jiān)MikeSaccotelli補充說：“運行持續(xù)交付模型與持續(xù)部署模型的組織之間的主要區(qū)別在于其構(gòu)建和部署過程的成熟度和復(fù)雜程度。”

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

1. 評估商業(yè)利益

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

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

2. 準備開發(fā)團隊

Lucas分享了在遷移到持續(xù)部署模型之前應(yīng)該成為軟件開發(fā)過程一部分的一些先決條件。他說：“持續(xù)部署是真正的敏捷性，是從代碼更改到生產(chǎn)的最快方式。它需要始終將主分支保持在可交付狀態(tài)、自動化測試以及您可以信任和有信心的高質(zhì)量工具?！?/p>

希望自動化持續(xù)部署的開發(fā)人員的一些開發(fā)職責和規(guī)則包括：

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

Saccotelli補充說：“持續(xù)部署的前提是開發(fā)團隊對質(zhì)量代碼有更成熟的理解，這樣這個過程才能成功。如果代碼很差或未經(jīng)測試，那將創(chuàng)建一個不可靠的系統(tǒng)，并迅速將錯誤和漏洞推向生產(chǎn)環(huán)境?！?/p>

3.準備運營團隊

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

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

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

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

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

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

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

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

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

除了測試自動化之外，Baskett還提到了實施應(yīng)該擴展到其他風險評估的質(zhì)量門。當構(gòu)建觸發(fā)持續(xù)部署時，質(zhì)量門會實施業(yè)務(wù)規(guī)則，以確定哪些部署可以投入生產(chǎn)，哪些可能需要合規(guī)審查或管理簽字。

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

持續(xù)部署可以產(chǎn)生許多業(yè)務(wù)和技術(shù)優(yōu)勢，但紀律嚴明的DevOps團隊和IT組織應(yīng)確保在使用自動化提高部署頻率之前擁有最佳實踐和工具。?