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

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

流程因公司類型而異

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

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

測試范圍

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

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

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

構(gòu)建部署流程的技巧

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

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

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

錯誤分類：無論您準(zhǔn)備的多么充分，在一定程度上都是不可避免的錯誤。因此，應(yīng)該定義一個可以進(jìn)行錯誤評估的過程?！胺诸悺保═riage）就是確定最重要的錯誤，然后立即修復(fù)它們-即作為修補(bǔ)程序。緊急程度較低的錯誤應(yīng)根據(jù)它們對整體體驗的重要性來權(quán)衡。但是，團(tuán)隊?wèi)?yīng)始終保持最小的積壓，以免日后出現(xiàn)回歸錯誤。

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

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