釋放還是不釋放？就是那個問題。但是，通常是根據(jù)直覺而不是具體數(shù)據(jù)做出決定。有權訪問數(shù)據(jù)以及結構化的部署過程可以幫助避免發(fā)布故障軟件。

坦白說：您的公司在發(fā)布軟件更新時使用什么標準？如果您沒有明確的答案，那么您并不孤單。太多的團隊沒有明確的標準來定義何時可以發(fā)布更新。但是在DevOps和CI / CD時代，開發(fā)人員和項目經理應該定義清晰的決策流程，并就統(tǒng)一的發(fā)布標準達成共識。如果沒有明確的流程來決定何時發(fā)布軟件版本，則公司可能會遇到生產中的嚴重錯誤。

流程因公司類型而異

各個公司的處理軟件版本的方式差異很大。具有龐大用戶群，幾乎無限資源和基礎架構的公司能夠快速發(fā)布，并在必要時撤回發(fā)布。這樣，可以以較高的頻率向一小部分用戶提供更新，并且系統(tǒng)會自動檢測何時出現(xiàn)問題，以便可以使用以前的版本。這樣的公司由于采用這種方法可能承擔更多的風險，但它們也需要數(shù)量驚人的基礎架構，DevOps托管和大量客戶。另一方面，更多的傳統(tǒng)公司傾向于規(guī)避風險，并遵循結構化的小規(guī)模流程進行質量保證。有產生很少的趨勢，使用經典開發(fā)方法構建的全面且經過測試的發(fā)行版。但是，在競爭激烈的市場中保持競爭力所需的敏捷性受到了影響。

因此，規(guī)避風險和承擔風險的方法均不適用于所有公司。因此，開發(fā)和工程團隊必須全面建立結構化的部署流程，并優(yōu)化發(fā)布流程。

測試范圍

關于此優(yōu)化，重點主要放在測試范圍上。在這里，有必要權衡利弊：必須滿足哪些先決條件才能確保產品或服務盡可能無差錯？當然，特別重要的軟件功能必須繼續(xù)平穩(wěn)運行，并且不得受到更新的負面影響。同時，必須根據(jù)時間和金錢來評估測試所需的資源。例如，單元測試通常僅單獨檢查幾行代碼，例如正確執(zhí)行文本輸入規(guī)范。在此之上的一個級別，集成測試用于測試網(wǎng)絡中的多個組件。這些對于使副作用風險最小化很重要。而且在系統(tǒng)級別的測試甚至更加復雜且耗時。

但是，除了這些標準測試之外，包括其他測試類型也可能有用。例如，探索性測試，其中的功能不是在腳本之后進行測試，而是由試圖“破壞”體驗的測試人員進行。

通常建議在過程的早期進行盡可能廣泛的測試。這減少了單個測試的運行時間，并且可以增加頻率。但是，為了不僅從開發(fā)人員的角度進行測試，而且從不同的角度進行測試，也應使用代表實際用戶的測試人員進行探索性測試。

構建部署流程的技巧

自動化和手動測試的混合使產品經理更難確定合適的發(fā)布時間。構建流程可以幫助節(jié)省時間和金錢。以下措施支持這一點：

質量門流程（QGP）：將項目分為多個階段，并在每個階段的末尾設置質量門。與里程碑相反，這些質量門始終設置統(tǒng)一，以確保在整個項目中始終保持相同的正式質量保證流程。要檢查的方面記錄在明確定義的檢查表中，以確保一致性。根據(jù)評估結果，決定如何進一步進行：“執(zhí)行” –過渡到下一階段；“保持” –在階段中需要改進，因為并非所有方面都得到滿足；和“停止” –必須澄清是否必須中止該項目，或者是否有可能進行大量改進以維持該項目。

非自動化測試的時間限制：探索性測試至關重要，因為如果該錯誤是由客戶在發(fā)布后發(fā)現(xiàn)的，那就太遲了。但是，為了使此類測試的范圍保持在限制范圍內，公司可以使用項目管理方法。例如，時間框定義了可以進行這種探索性測試的時間范圍。目標是在給定的時間內進行盡可能多的測試，然后嚴格完成測試-無論您走了多遠。如果明顯的方面仍未解決，則必須將其移至下一階段的時間框。

錯誤分類：無論您準備的多么充分，在一定程度上都是不可避免的錯誤。因此，應該定義一個可以進行錯誤評估的過程。“分類”（Triage）就是確定最重要的錯誤，然后立即修復它們-即作為修補程序。緊急程度較低的錯誤應根據(jù)它們對整體體驗的重要性來權衡。但是，團隊應始終保持最小的積壓，以免日后出現(xiàn)回歸錯誤。

基于數(shù)據(jù)的決策支持

開發(fā)團隊承受著巨大的壓力，因為管理層和外部利益相關者通常會推動敏捷，快速的軟件開發(fā)以實現(xiàn)高質量。為了使項目經理決定“繼續(xù)”發(fā)布，可以使用諸如掌聲質量評分（AQS）之類的質量評分?；跉v史數(shù)據(jù)和當前指標，可以使軟件質量可衡量。此類指標包括例如測試范圍和覆蓋范圍，錯誤頻率和錯誤嚴重性。統(tǒng)一評分還可以提供較少的主觀決策幫助，并可以進行基準測試，從而幫助團隊更輕松地做出通過/不通過的決策。