為了讓持續集成和持續交付（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的目標。

*該文為翻譯文章，原文鏈接：https://thenewstack.io/how-to-avoid-pit-stops-on-the-road-to-...