持續(xù)交付是指團隊能夠快速、安全、可持續(xù)地按需發(fā)布各類變更。對于希望提升 CI/CD 能力、優(yōu)化軟件交付流程、降低發(fā)布風(fēng)險的團隊來說持續(xù)交付不是簡單地“更頻繁發(fā)布”而是讓軟件始終保持可部署狀態(tài)。實踐持續(xù)交付的團隊可以隨時以低風(fēng)險方式發(fā)布軟件并對生產(chǎn)環(huán)境進行變更包括在正常工作時間內(nèi)完成發(fā)布而不會影響用戶。持續(xù)交付的原則和實踐適用于各種軟件場景包括在復(fù)雜分布式系統(tǒng)中更新服務(wù)升級大型機軟件修改基礎(chǔ)設(shè)施配置變更數(shù)據(jù)庫架構(gòu)自動更新固件發(fā)布移動應(yīng)用的新版本。當(dāng)團隊真正實踐持續(xù)交付時應(yīng)該能夠?qū)σ韵聠栴}回答“是”我們的軟件在整個生命周期內(nèi)是否始終處于可部署狀態(tài)相比開發(fā)新功能我們是否會優(yōu)先保證軟件的可部署性團隊中的每個人是否都能快速獲得關(guān)于系統(tǒng)質(zhì)量和可部署性的反饋當(dāng)我們收到系統(tǒng)無法部署的反饋例如構(gòu)建失敗或測試失敗時是否會把解決這些問題作為首要任務(wù)我們是否能夠隨時按需將系統(tǒng)部署到生產(chǎn)環(huán)境或交付給最終用戶持續(xù)交付與持續(xù)部署的區(qū)別持續(xù)交付經(jīng)常與持續(xù)部署混淆但二者是不同的實踐。持續(xù)部署是指團隊盡可能快地將每一次代碼變更部署到生產(chǎn)環(huán)境。持續(xù)部署適用于 Web 服務(wù)但并不適用于固件、移動應(yīng)用等所有軟件類型。持續(xù)交付則適用于所有類型的軟件包括固件、大型機系統(tǒng)以及高度監(jiān)管的環(huán)境。即使團隊從未打算采用持續(xù)部署也可以而且應(yīng)該從持續(xù)交付開始。持續(xù)交付和持續(xù)部署常常被誤認為風(fēng)險較高不適用于受監(jiān)管或安全要求極高的領(lǐng)域。事實上持續(xù)交付的目標恰恰是降低軟件風(fēng)險。DORA 的研究也持續(xù)表明高績效團隊通常能夠?qū)崿F(xiàn)更高的可靠性和可用性。推動持續(xù)交付的技術(shù)實踐例如持續(xù)測試、安全左移、全面測試和可觀測性在高度監(jiān)管和安全關(guān)鍵領(lǐng)域尤其重要。持續(xù)交付已經(jīng)在金融服務(wù)、政府等高度監(jiān)管領(lǐng)域多次成功落地。持續(xù)交付能帶來哪些價值盡管持續(xù)交付適用于各種軟件類型但它并不容易實現(xiàn)。不過它能帶來顯著收益。DORA 的研究表明做好持續(xù)交付可以帶來以下好處提升軟件交付績效和可用性這可以通過四個關(guān)鍵指標進行衡量提升質(zhì)量水平具體可以通過團隊花在返工或計劃外工作上的時間占比來衡量降低職業(yè)倦怠水平提升工作滿意度并改善組織文化減少部署痛苦也就是降低部署過程中的破壞性、壓力感以及工程師和技術(shù)人員在將代碼推送到生產(chǎn)環(huán)境時感受到的恐懼和焦慮影響企業(yè)文化提升心理安全感并形成更具使命感的組織文化。持續(xù)交付只是實現(xiàn)上述成果的關(guān)鍵組成部分之一雖然它非常重要。DORA 研究中提到的其他文化能力和組織能力也會共同影響這些結(jié)果。團隊可以通過實施本文所描述的技術(shù)實踐逐步實現(xiàn)持續(xù)交付。如何實施持續(xù)交付DORA 的研究發(fā)現(xiàn)以下技術(shù)能力是實現(xiàn)持續(xù)交付的關(guān)鍵驅(qū)動因素。組織內(nèi)部的變革型領(lǐng)導(dǎo)力也會推動這些技術(shù)能力的落地。為了幫助團隊實現(xiàn)更高吞吐量和更低風(fēng)險的發(fā)布可以重點實施以下持續(xù)交付實踐。測試自動化。指使用一套綜合性的自動化測試套件這些測試主要由開發(fā)人員創(chuàng)建和維護。有效的測試套件應(yīng)該是可靠的也就是說測試能夠發(fā)現(xiàn)真實故障并且只有可發(fā)布代碼才能通過測試。部署自動化。指部署流程在多大程度上實現(xiàn)了完全自動化并且不需要人工干預(yù)?；谥鞲傻拈_發(fā)。其特征包括代碼庫中的活躍分支少于三個分支和 fork 分支的生命周期非常短例如不超過一天隨后就會合并回主線應(yīng)用團隊很少或幾乎沒有代碼鎖定期也就是不會因為合并沖突、代碼凍結(jié)或穩(wěn)定階段而禁止提交代碼或發(fā)起拉取請求。安全左移。指將安全融入軟件開發(fā)過程的設(shè)計和測試階段。具體做法包括對應(yīng)用進行安全評審讓信息安全團隊參與應(yīng)用設(shè)計和演示過程使用預(yù)先批準的安全庫和軟件包并將安全功能納入自動化測試套件。松耦合團隊。指一種組織結(jié)構(gòu)使團隊能夠按需測試和部署應(yīng)用而不需要與其他服務(wù)或團隊進行復(fù)雜協(xié)調(diào)。團隊結(jié)構(gòu)和技術(shù)架構(gòu)高度相關(guān)松耦合架構(gòu)能夠讓團隊獨立工作減少對其他團隊支持和服務(wù)的依賴從而提升效率并為組織創(chuàng)造價值。DORA 研究顯示松耦合架構(gòu)是持續(xù)交付成功的重要預(yù)測因素之一達到可靠性目標的高績效團隊采用這類架構(gòu)的可能性明顯高于低績效團隊。賦予團隊選擇工具的權(quán)力。能夠自主選擇工具的團隊在持續(xù)交付方面往往表現(xiàn)更好。沒有人比一線實踐者更清楚自己需要哪些工具才能高效完成工作。持續(xù)集成。持續(xù)集成是一種開發(fā)實踐要求團隊定期提交代碼每次提交都會觸發(fā)一組快速測試以發(fā)現(xiàn)回歸問題開發(fā)人員也會立即修復(fù)這些問題。CI 流程會生成標準化構(gòu)建產(chǎn)物和軟件包供后續(xù)部署和發(fā)布使用。持續(xù)測試。指測試貫穿整個軟件交付生命周期而不是在開發(fā)完成后才進入一個獨立測試階段。通過持續(xù)測試開發(fā)人員和測試人員可以并肩工作。優(yōu)秀開發(fā)人員通常會實踐測試驅(qū)動開發(fā)在十分鐘內(nèi)獲得測試反饋并持續(xù)審查和改進測試套件例如提升缺陷發(fā)現(xiàn)能力并控制測試復(fù)雜度。版本控制。指使用版本控制系統(tǒng)管理所有生產(chǎn)工件包括應(yīng)用代碼、應(yīng)用配置、系統(tǒng)配置以及用于自動化構(gòu)建和環(huán)境配置的腳本。測試數(shù)據(jù)管理。有效的測試數(shù)據(jù)管理實踐包括擁有足夠的測試數(shù)據(jù)來運行測試套件能夠按需獲取所需數(shù)據(jù)數(shù)據(jù)量不會限制測試運行數(shù)量。我們建議團隊盡可能減少運行自動化測試所需的測試數(shù)據(jù)量。全面監(jiān)控和可觀測性。指讓團隊能夠理解系統(tǒng)運行狀況。有效的監(jiān)控與可觀測性方案可以幫助團隊監(jiān)控預(yù)先定義的指標包括用戶實際體驗到的系統(tǒng)狀態(tài)同時也允許工程師以交互方式調(diào)試系統(tǒng)探索系統(tǒng)屬性和運行中涌現(xiàn)出的模式。主動通知。指持續(xù)監(jiān)控系統(tǒng)運行狀況使團隊能夠提前發(fā)現(xiàn)并緩解問題。數(shù)據(jù)庫變更管理。如果團隊遵循一些關(guān)鍵實踐數(shù)據(jù)庫變更就不會拖慢交付速度。這些實踐包括將數(shù)據(jù)庫變更以腳本形式存儲在版本控制中并以與生產(chǎn)應(yīng)用變更相同的方式管理這些變更讓軟件交付生命周期中的每個角色包括工程師都能看到數(shù)據(jù)庫變更當(dāng)應(yīng)用變更需要數(shù)據(jù)庫變更時及時與所有相關(guān)方溝通。代碼可維護性。指通過系統(tǒng)和工具使開發(fā)人員能夠輕松修改他人維護的代碼在代碼庫中找到示例復(fù)用他人的代碼并在添加、升級或遷移依賴項時避免破壞已有代碼。雖然持續(xù)交付通常與持續(xù)集成一起出現(xiàn)被統(tǒng)稱為 CI/CD但研究表明持續(xù)集成只是實現(xiàn)持續(xù)交付的一個要素。要實現(xiàn)可靠、低風(fēng)險的發(fā)布需要軟件交付流程中所有參與者緊密協(xié)作而不僅僅是軟件開發(fā)人員參與。同時團隊也需要采用新的工作方式并學(xué)習(xí)新的技能。在實際落地時持續(xù)交付還需要把目標、需求、開發(fā)、測試、發(fā)布、監(jiān)控和復(fù)盤連接成一條可追蹤的研發(fā)鏈路。借助PingCode這類研發(fā)管理工具團隊可以將需求清理、評審排期、開發(fā)任務(wù)、測試驗證、發(fā)布上線和 Wiki 知識沉淀串聯(lián)起來并與代碼倉庫、CI/CD 等研發(fā)工具打通讓持續(xù)交付不只是流水線自動化而是貫穿整個軟件交付生命周期的協(xié)作機制。實施持續(xù)交付的常見陷阱有些組織誤以為只要更頻繁地執(zhí)行現(xiàn)有部署流程就能實現(xiàn)持續(xù)交付。然而真正實現(xiàn)持續(xù)交付所需的技術(shù)能力通常需要團隊對流程和架構(gòu)進行重大調(diào)整。如果流程和架構(gòu)沒有改進僅僅提高部署頻率很可能會導(dǎo)致更高的失敗率并讓團隊筋疲力盡。許多關(guān)于持續(xù)交付的討論都集中在工具和模式上例如如何通過部署流水線將變更從版本控制系統(tǒng)部署到生產(chǎn)環(huán)境。然而如果沒有落實本文中提到的必要技術(shù)實踐和流程變更僅僅引入現(xiàn)代工具并不能產(chǎn)生預(yù)期效果。DORA 研究發(fā)現(xiàn)轉(zhuǎn)型項目中常常會出現(xiàn)典型的 J 型曲線。為了走出 J 型曲線底部團隊需要同時考慮流程重設(shè)計與簡化、架構(gòu)改進、能力和技能發(fā)展以及自動化和工具化建設(shè)。典型的 J 型曲線通常包含以下階段在轉(zhuǎn)型初期團隊開始轉(zhuǎn)型并尋找能夠快速見效的方法。在初步改進階段自動化可以幫助低績效團隊提升到中等績效水平。在效率下降階段也就是 J 型曲線底部自動化會增加測試需求而這些測試仍然需要人工處理大量技術(shù)債務(wù)也會阻礙進展。隨著團隊逐漸走出困境技術(shù)債務(wù)和不斷增長的系統(tǒng)復(fù)雜性會導(dǎo)致變更過程中出現(xiàn)額外的手動控制和多層流程從而拖慢工作速度。在達到高績效階段后持續(xù)不斷的改進工作才能真正帶來卓越表現(xiàn)。優(yōu)秀團隊能夠充分利用自身專業(yè)知識并從周圍環(huán)境中持續(xù)學(xué)習(xí)從而提升生產(chǎn)力。緩解 J 型曲線影響的一種有效方式是開展價值流圖分析以發(fā)現(xiàn)并預(yù)測瓶頸的影響。在價值流圖分析中團隊需要觀察單個變更從版本控制進入生產(chǎn)環(huán)境的完整過程考慮每次變更必須經(jīng)歷的各種流程例如自動化測試、手動測試、安全審查、變更管理以及發(fā)布到生產(chǎn)環(huán)境測量變更從進入版本控制到發(fā)布所需的總時間針對每個流程測量實際耗時和增值時間。實際耗時是端到端流程所消耗的時間增值時間則是真正完成有價值工作的時間記錄工作因為第一次沒有正確完成而被退回的比例。這個指標通常被稱為完成準確率也就是 %C/A。價值流圖的目的是幫助團隊發(fā)現(xiàn)流程中的低效環(huán)節(jié)。團隊需要共同繪制一張價值流圖描述六個月后理想的價值流狀態(tài)并預(yù)留資源去實現(xiàn)這一目標。隨后團隊?wèi)?yīng)找出并消除那些流程耗時過長尤其是相對于價值創(chuàng)造時間過長或者完成準確率較低的障礙。通常在實施部署流水線時需要對流程和架構(gòu)進行重大重設(shè)計。由于部署流水線覆蓋從代碼提交到發(fā)布的完整過程并連接多個團隊因此所有相關(guān)團隊的代表都必須參與價值流圖繪制并就通用工具鏈和流程達成共識。例如團隊需要共同確定部署到測試環(huán)境和生產(chǎn)環(huán)境的流程這些都應(yīng)成為未來目標狀態(tài)的一部分。持續(xù)交付的實施是一個持續(xù)的、日常的改進過程其指導(dǎo)原則是實現(xiàn)預(yù)期結(jié)果。工具和模式固然重要但它們只能服務(wù)于這項關(guān)鍵的改進工作。如何衡量持續(xù)交付效果持續(xù)交付的最終目標是確保團隊能夠在正常工作時間內(nèi)以低風(fēng)險方式執(zhí)行發(fā)布。理想情況下不應(yīng)該要求任何人在正常工作時間之外完成部署或發(fā)布。因此對這一點進行衡量非常重要。持續(xù)交付的成效最終體現(xiàn)在成果上。你可以通過 DORA 快速評估查看團隊在關(guān)鍵持續(xù)交付指標上的表現(xiàn)常規(guī)變更和緊急變更的前置時間都很短理想狀態(tài)是能夠使用常規(guī)流程處理緊急變更變更失敗率較低發(fā)生故障或服務(wù)降級時可以在較短時間內(nèi)恢復(fù)服務(wù)發(fā)布頻率能夠確保高優(yōu)先級功能和錯誤修復(fù)及時交付。正如本文開頭所討論的實施持續(xù)交付還應(yīng)該降低返工率減少部署痛苦并減少團隊花在返工和計劃外工作上的時間。歸根結(jié)底持續(xù)交付不是簡單地“更頻繁發(fā)布”也不是只搭建一條 CI/CD 流水線。它要求團隊持續(xù)保持軟件可部署狀態(tài)通過自動化測試、部署自動化、主干開發(fā)、安全左移、可觀測性和低耦合架構(gòu)降低交付風(fēng)險。只有當(dāng)這些技術(shù)實踐與團隊協(xié)作方式、組織能力建設(shè)和持續(xù)改進機制結(jié)合起來持續(xù)交付才能真正提升軟件交付績效和組織可靠性。