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

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

流程因公司類型而異

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

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

測(cè)試范圍

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

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

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

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

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

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

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

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

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

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