為什麼單元測試不是持續交付的唯一答案

為了讓持續整合和持續交付（CI/CD）成為現實，企業必須審查其內部流程，並重新思考如何處理軟體交付生命週期。過去的清單和評論根本不是前進的方向。殘酷的事實是，大多數企業在持續交付的道路上相當落後。對軟體交付過程本身進行根本性的改變與從貨架上取下一些工具這樣的半個步驟是完全不一樣的。

如果目標是對客戶和使用者做出更好的響應，軟體團隊需要專注於軟體交付週期的更快迭代，並圍繞快速響應使用者反饋進行組織。雖然可能有如每月釋出數量這種代理指標，但採用持續交付的最佳衡量標準是跟蹤從反饋到更新軟體的時間。

但是如果只是拼湊性地進行持續交付，將無法達成目標。

人們很容易從漸進的角度來看待一個組織如何從現狀發展到它想駐足的位置。雖然漸進永遠是正確的方法，但目前僅僅邁出第一步的企業不應自欺欺人地認為自己已經走得足夠遠。

不要依賴於CI/CD工具

通常，團隊實行持續交付都是從一些自動化的單元測試來自動化構建過程開始。這是一個很好的開端，但是不要花太多的時間去關注單元測試覆蓋的程式碼行數。相反，企業應該將自動化測試的注意力集中在 驗證核心業務流程、使用者事務和使用者互動上，以確保它們仍然按照預期和業務有效執行所需的方式執行。

CI/CD戰略的下一個複雜層次是傾向於將計劃每季度進行的大量變化打包在一起（如果企業在這一步停留也是一種錯誤）。實際上，CI成為了企業暫停努力的一個點。另一方面，CD則是儘可能頻繁地透過管道和生產進行更改。一旦企業瞭解了程式碼更改對使用者的影響以及自動實現這些更改的實現方式，它就需要鼓起勇氣和付出財力來推動這些更改。

一般來說，即使是正在追求CI/CD的組織，也會存在著將變革視為風險的心態。這就不可避免地導致了這樣一種信念：更改的頻率應該降低。這與持續交付正好相反，它會對企業完全接受CI/CD造成阻礙。

較小的變更本質上會帶來更小的風險，這意味著 高生產率的軟體組織應能夠更快地遷移。 持續交付的概念和前景取決於企業不斷部署微小變更的能力。有必要期望進行頻繁的釋出。

範圍軟體相應更改

那些單純使用傳統思維方式（CI工具、單元測試和驗收測試）進行這項工作的企業仍然沒有獲得任何真正的好處。 企業正在部署的變更範圍應該作為它在軟體開發生命週期中可以承受的質量問題級別的指導方針。

另一個常見的問題是，當一個組織決定將事情分解為一些小的變更，但是仍然需要開一系列的會議，變更控制委員會或者開發團隊必須經過的嚴格的安全檢查。如果您的組織的目標是透過部署較小的變更堆疊來加快進度，那麼在全面重新考慮內部正式的釋出週期方法之前，它不會有任何進展。

在政府機構等嚴格監管部門工作的組織，必須透過對其釋出的產品進行修改和必要的文件化來克服這些挑戰。政府部門以外的組織可以效仿他們的例子，透過對軟體進行更改並描述這些更改將如何影響標記版本內的使用者來克服文件需求。一個很好的例子就是美國政府的cloud.gov團隊如何透過程式設計生成文件，比如他們的系統圖。

想要在CI/CD領域取得成功的企業必須找到一種方法，將這種意見編入某種可以快速完成的自動化測試中，而不是從任何人那裡獲取關於軟體是否應該釋出的意見。否則，這條道路上的每一個手動步驟只會進一步造成交付的延遲。

組織如何解決這個問題

許多企業陷入推行CI/CD至一半的境地——他們有各種各樣的工具來允許一些這樣的實踐，但是內部流程、檢查表或管理許可權下的決定阻止了組織以正常的節奏釋出更新。

大量的開發人員被困在傳統的軟體開發週期中，他們甚至不嘗試CI/CD，或者透過專注於工具、測試和自動化來接受CI/CD的人工版本。

有兩種方法可以解決這個問題。 一種方法是首先使用CI/CD工具，並授權各種開發團隊開始在公司範圍內使用公共構建服務。另一種方法是確定將從較高的開發速度、較小的變更集中獲益最多的開發團隊，並允許從該實踐中獲得的經驗滲透到整個業務中。

後一種模型在大多數情況下會工作得更好，因為所涉及的人員數量被保持在最低限度，而IT組織中更關心遵從性和審計的部分將有更大的靈活性來理解單個應用程式範圍內發生的事情。企業應該更願意在單個應用程式和團隊中推行試驗，而不是試圖推動整個公司一起進行轉變。

CI/CD的目標始終是不斷變化的，這是有意設計的。但是請放心，當所有能夠從更快交付中獲益的團隊都實現了這些結果時，組織將清楚自身已經開始實現CI/CD的目標。