爲什麽單元測試不是持續交付的唯一答案
本篇目錄
如果目標是對客戶和用戶做出更好的響應，軟件團隊需要專注于軟件交付周期的更快叠代，並圍繞快速響應用戶反饋進行組織。雖然可能有如每月發布數量這種代理指標，但采用持續交付的最佳衡量標准是跟蹤從反饋到更新軟件的時間。
但是如果只是拼湊性地進行持續交付，將無法達成目標。
不要依賴于CI/CD工具
通常，團隊實行持續交付都是從一些自動化的單元測試來自動化構建過程開始。這是一個很好的開端，但是不要花太多的時間去關注單元測試覆蓋的代碼行數。相反，企業應該將自動化測試的注意力集中在 驗證核心業務流程、用戶事務和用戶交互上，以確保它們仍然按照預期和業務有效運行所需的方式運行。
一般來說，即使是正在追求CI/CD的組織，也會存在著將變革視爲風險的心態。這就不可避免地導致了這樣一種信念：更改的頻率應該降低。這與持續交付正好相反，它會對企業完全接受CI/CD造成阻礙。
較小的變更本質上會帶來更小的風險，這意味著 高生産率的軟件組織應能夠更快地遷移。 持续交付的概念和前景取决于企业不断部署微小变更的能力。有必要期望进行频繁的发布。
範圍軟件相應更改
那些單純使用傳統思維方式（CI工具、單元測試和驗收測試）進行這項工作的企業仍然沒有獲得任何真正的好處。 企業正在部署的變更範圍應該作爲它在軟件開發生命周期中可以承受的質量問題級別的指導方針。另一個常見的問題是，當一個組織決定將事情分解爲一些小的變更，但是仍然需要開一系列的會議，變更控制委員會或者開發團隊必須經過的嚴格的安全檢查。如果您的組織的目標是通過部署較小的變更堆棧來加快進度，那麽在全面重新考慮內部正式的發布周期方法之前，它不會有任何進展。
在政府机构等严格监管部门工作的组织，必须通过对其发布的産品进行修改和必要的文档化来克服这些挑战。政府部门以外的组织可以效仿他们的例子，通过对软件进行更改并描述这些更改将如何影响标记版本内的用户来克服文档需求。一个很好的例子就是美国政府的cloud.gov团队如何通过编程生成文档，比如他们的系统图。
組織如何解決這個問題
許多企業陷入推行CI/CD至一半的境地——他們有各種各樣的工具來允許一些這樣的實踐，但是內部流程、檢查表或管理權限下的決定阻止了組織以正常的節奏發布更新。大量的開發人員被困在傳統的軟件開發周期中，他們甚至不嘗試CI/CD，或者通過專注于工具、測試和自動化來接受CI/CD的人工版本。
有兩種方法可以解決這個問題。 一種方法是首先使用CI/CD工具，並授權各種開發團隊開始在公司範圍內使用公共構建服務。另一種方法是確定將從較高的開發速度、較小的變更集中獲益最多的開發團隊，並允許從該實踐中獲得的經驗滲透到整個業務中。
後一種模型在大多數情況下會工作得更好，因爲所涉及的人員數量被保持在最低限度，而IT組織中更關心遵從性和審計的部分將有更大的靈活性來理解單個應用程序範圍內發生的事情。企業應該更願意在單個應用程序和團隊中推行試驗，而不是試圖推動整個公司一起進行轉變。
