剛接手一個(gè)中型項(xiàng)目的研發(fā)流程那會(huì)兒我做的第一件事不是翻代碼而是把近半年的發(fā)布記錄全導(dǎo)出來對(duì)了一遍。結(jié)果非常典型同一個(gè)功能在測試環(huán)境叫 v2.3.1到預(yù)發(fā)變成 v2.3線上又成了 release-20230417三個(gè)名字指向的是同一份代碼反過來更嚇人的是兩個(gè)完全不同的構(gòu)建產(chǎn)物都叫 v1.0.0線上跑的到底是哪一個(gè)誰也說不清。這就是軟件版本管理沒有統(tǒng)一規(guī)定的直接后果——不是沒人管而是每個(gè)人按自己的習(xí)慣管最后誰也拼不出完整的一張圖。軟件版本管理規(guī)定這件事聽起來像是寫文檔的活實(shí)際上它決定了你出事之后能不能在十分鐘內(nèi)定位問題、能不能安全回滾、能不能回答線上到底是什么。這篇內(nèi)容我打算按自己踩過的坑和后來落地的規(guī)則來講適合剛接手發(fā)布流程的研發(fā)、測試負(fù)責(zé)人也適合團(tuán)隊(duì)里那個(gè)被默認(rèn)管版本的人不管你現(xiàn)在用的是 Git 還是別的工具規(guī)則層面的東西是通用的。1. 版本號(hào)到底該怎么編從語義化版本到團(tuán)隊(duì)內(nèi)規(guī)1.1 三個(gè)數(shù)字各自承諾了什么很多人以為版本號(hào)就是給發(fā)布排個(gè)序漲上去就行其實(shí)版本號(hào)真正的作用是對(duì)外承諾兼容性。語義化版本那套 MAJOR.MINOR.PATCH 的約定之所以被廣泛采用是因?yàn)樗堰@次升級(jí)會(huì)不會(huì)弄壞我的代碼這個(gè)問題變成了可以提前判斷的事主版本號(hào)漲了意味著有不兼容的改動(dòng)調(diào)用方必須改代碼次版本號(hào)漲了意味著新增了功能但保持向后兼容修訂號(hào)漲了意味著只有修復(fù)接口沒動(dòng)。這個(gè)承諾一旦定下來就不能隨便破例。我見過最常見的破例方式是順手改一下。發(fā)布前發(fā)現(xiàn)一個(gè)小接口的參數(shù)名寫錯(cuò)了覺得反正沒人用直接改掉版本號(hào)只在修訂位上加一。結(jié)果下游某個(gè)服務(wù)正好用了這個(gè)參數(shù)上線當(dāng)晚就報(bào)錯(cuò)。所以團(tuán)隊(duì)內(nèi)規(guī)里必須寫清楚只要接口簽名、數(shù)據(jù)格式、配置項(xiàng)名稱發(fā)生了變化無論改動(dòng)多小都要往次版本號(hào)漲必要時(shí)甚至要往主版本號(hào)漲。判斷標(biāo)準(zhǔn)不看代碼行數(shù)看的是外部能不能感知到差異。還有一點(diǎn)容易被忽略版本號(hào)的數(shù)字段是有排序語義的不要塞入前導(dǎo)零也不要用字母去替代數(shù)字。像 v1.10 和 v1.9 這種字符串排序會(huì)得出錯(cuò)誤結(jié)論必須按數(shù)字段比較。如果團(tuán)隊(duì)里有人寫腳本去解析版本號(hào)這一點(diǎn)會(huì)直接導(dǎo)致灰度分批的邏輯出錯(cuò)。1.2 企業(yè)里通常要多加幾位純粹的語義化版本在內(nèi)部研發(fā)場景下經(jīng)常不夠用因?yàn)槲覀冃枰獏^(qū)分同一份代碼在不同環(huán)境下構(gòu)建出來的不同產(chǎn)物。所以大多數(shù)團(tuán)隊(duì)會(huì)在三段式后面追加構(gòu)建號(hào)或者日期流水號(hào)形成類似2.3.1.20240517.812或者2.3.1build.812這樣的形式。這里的關(guān)鍵是區(qū)分業(yè)務(wù)版本和構(gòu)建版本前三段是業(yè)務(wù)版本由人決定代表這一版包含什么后面的構(gòu)建信息由流水線自動(dòng)生成只用來唯一標(biāo)識(shí)一份產(chǎn)物。字段誰來決定含義是否重復(fù)出現(xiàn)主版本號(hào)研發(fā)負(fù)責(zé)人評(píng)審不兼容變更否次版本號(hào)研發(fā)負(fù)責(zé)人評(píng)審兼容性新增否修訂號(hào)開發(fā)自定兼容性修復(fù)否構(gòu)建流水號(hào)流水線自動(dòng)唯一標(biāo)識(shí)產(chǎn)物是每次構(gòu)建遞增預(yù)發(fā)布標(biāo)識(shí)發(fā)布同學(xué)標(biāo)記rc / beta 等階段同版本可多次預(yù)發(fā)布標(biāo)識(shí)也要有明確規(guī)定。rc 代表候選發(fā)布beta 代表公開測試alpha 代表內(nèi)部驗(yàn)證這些標(biāo)識(shí)只能出現(xiàn)在正式發(fā)布之前且同一個(gè) rc 編號(hào)只能對(duì)應(yīng)一份產(chǎn)物。如果 rc1 修復(fù)了問題重新構(gòu)建那就必須是 rc2不能覆蓋 rc1 的制品。這一點(diǎn)后面講制品管理的時(shí)候還會(huì)展開因?yàn)樗苯記Q定了回溯的可靠性。1.3 用日期做版本號(hào)這件事要謹(jǐn)慎不少團(tuán)隊(duì)喜歡用2024.05.17這種日期版本看著直觀實(shí)際用起來有兩類麻煩。第一是排序問題如果跨年月份和日期不足兩位就會(huì)亂序必須嚴(yán)格補(bǔ)零第二是并發(fā)問題同一天出兩個(gè)版本就沒法區(qū)分了得再掛一個(gè)流水號(hào)于是變成2024.05.17.2這時(shí)候它已經(jīng)不再是純?nèi)掌谡Z義而是日期序號(hào)那就干脆說明白別讓新同學(xué)誤以為它就是日期。我的建議是面向外部用戶的版本用語義化三段式面向內(nèi)部構(gòu)建的標(biāo)識(shí)用日期或構(gòu)建號(hào)。兩套并存但職責(zé)邊界必須在規(guī)定里寫死。最怕的是混著用一會(huì)兒 v2.3.1 一會(huì)兒 20240517臺(tái)賬里兩列數(shù)字沒法對(duì)賬。如果確實(shí)要給用戶展示一個(gè)更容易理解的版本比如手機(jī)應(yīng)用里的3.5 版那它和內(nèi)部版本號(hào)之間要有明確的映射關(guān)系表且這張表要跟代碼一起維護(hù)不能只存在某個(gè)人的腦子里。2. 分支模型與版本號(hào)的綁定關(guān)系2.1 主干開發(fā)和發(fā)布分支選哪個(gè)先想清楚分支模型和版本號(hào)是一體的光規(guī)定版本號(hào)卻不規(guī)定分支怎么切規(guī)定就是空轉(zhuǎn)。目前主流是兩條路線一種是主干開發(fā)、發(fā)布分支拉出后凍結(jié)另一種是長期維護(hù)多個(gè)版本分支。前者適合迭代快、只有一兩個(gè)在線版本的團(tuán)隊(duì)后者適合有客戶還在用老版本的場景比如企業(yè)軟件、交付類項(xiàng)目。主干開發(fā)模式下版本號(hào)的推進(jìn)點(diǎn)很清晰功能合并進(jìn)主干時(shí)次版本號(hào)已經(jīng)在規(guī)劃里鎖定了從主干切出release/2.4分支的那一刻2.4 這個(gè)版本號(hào)就凍結(jié)后續(xù)在這個(gè)分支上只允許修訂位遞增也就是 2.4.1、2.4.2 這樣往上走。凍結(jié)的含義是不再往這個(gè)分支合入新功能只能合修復(fù)。我見過發(fā)布分支被當(dāng)成第二個(gè)開發(fā)分支用的團(tuán)隊(duì)結(jié)果就是每次上線都要重新跑一遍全量回歸因?yàn)榉种系拇a跟測試過的不是同一份。多版本并行維護(hù)的情況下規(guī)則要再收緊一層每個(gè)維護(hù)分支對(duì)應(yīng)一個(gè)大版本線比如release/2.x、release/3.x兩條線上同一個(gè)修復(fù)要打兩次補(bǔ)丁版本號(hào)分別遞增且要在臺(tái)賬里注明同源修復(fù)。這里最容易出的問題是漏合修了 3.x 忘了 2.x客戶投訴之后才發(fā)現(xiàn)。規(guī)定里可以要求補(bǔ)丁類修復(fù)必須列出所有受影響的大版本線逐個(gè)確認(rèn)是否合入。2.2 熱修復(fù)的版本號(hào)怎么漲線上出問題從發(fā)布分支切一個(gè)hotfix/2.4.3分支修完合回發(fā)布分支同時(shí)必須合回主干否則下一次從主干切發(fā)布分支的時(shí)候這個(gè)修復(fù)會(huì)丟失問題會(huì)復(fù)發(fā)。這是我在實(shí)際項(xiàng)目里反復(fù)見到的坑因?yàn)闊嵝迯?fù)分支往往是在深夜臨時(shí)拉的人一累就只想著趕緊上線忘了往回合。版本號(hào)方面熱修復(fù)只動(dòng)修訂位從 2.4.2 變成 2.4.3。如果這次修復(fù)其實(shí)改了對(duì)外接口或者數(shù)據(jù)結(jié)構(gòu)那就不能只漲修訂位要按前面說的兼容性規(guī)則來處理必要時(shí)直接發(fā)一個(gè)次版本。判斷動(dòng)作只有一個(gè)改完之后調(diào)用方在不改代碼的情況下能不能正常工作。能就是修訂位不能就得往上漲。標(biāo)簽Tag的規(guī)則也要一起寫。每個(gè)正式發(fā)布的版本必須在對(duì)應(yīng)的提交上打一個(gè)不可變的 TagTag 名與版本號(hào)嚴(yán)格一致禁止移動(dòng)或覆蓋已存在的 Tag。我在早期項(xiàng)目里遇到過有人為了省事把 Tag 刪了重新打結(jié)果 CI 里緩存了舊的制品兩邊對(duì)不上排查了兩個(gè)小時(shí)才找到原因。Tag 一移動(dòng)所有基于它的溯源都失效了這個(gè)代價(jià)遠(yuǎn)比重新發(fā)一個(gè)版本號(hào)高。2.3 環(huán)境和版本的映射必須成表規(guī)定里必須有一張環(huán)境與版本的對(duì)應(yīng)表明確哪個(gè)環(huán)境允許出現(xiàn)什么形態(tài)的版本號(hào)。環(huán)境允許的版本形態(tài)是否允許重新構(gòu)建覆蓋版本號(hào)確定時(shí)機(jī)開發(fā)聯(lián)調(diào)快照版本如 2.5.0-SNAPSHOT允許不入臺(tái)賬功能測試rc 版本如 2.5.0-rc1不允許重建換編號(hào)提測時(shí)鎖定預(yù)發(fā)布rc 或正式版候選不允許上線前一日鎖定生產(chǎn)正式版如 2.5.0絕對(duì)不允許上線評(píng)審?fù)ㄟ^后這張表看著簡單執(zhí)行起來最難的是快照版本往外漏。開發(fā)階段圖方便用 SNAPSHOT提測時(shí)忘了換成正式編號(hào)測試環(huán)境跑著跑著代碼被覆蓋了測試結(jié)論直接作廢。規(guī)定里要明確寫一句快照版本只允許存在于開發(fā)聯(lián)調(diào)環(huán)境任何進(jìn)入測試環(huán)節(jié)的制品都必須有不可變的版本號(hào)。3. 提測、灰度、上線版本流轉(zhuǎn)的門檻3.1 什么樣的版本才允許提測版本管理規(guī)定里提測門檻是最容易寫虛的一條。我后來總結(jié)成幾個(gè)可檢查的硬條件版本號(hào)已確定且制品已歸檔到制品庫冒煙用例全部通過并留有記錄本次變更清單已經(jīng)填寫完整包含涉及的服務(wù)、配置、數(shù)據(jù)庫腳本發(fā)布說明的初稿已提交。這幾條只要有一條不滿足測試就不接。為什么要卡這么死因?yàn)榘姹净靵y的源頭大多在提測這一步。測試拿到的包和開發(fā)本地跑的不是同一個(gè)這種事一旦發(fā)生測試出一個(gè)問題開發(fā)說我這邊沒問題來回扯皮的時(shí)間比修問題還長。版本號(hào)加制品哈希值是唯一能終結(jié)這種扯皮的東西。提測單上除了版本號(hào)還要寫上制品的校驗(yàn)值測試下載后核對(duì)一下不一致就直接打回不需要討論。另外提測的版本號(hào)和最終發(fā)上線的版本號(hào)最好保持一致。中間如果需要修改就只能往上遞增新版本號(hào)重新提測不能就地修改。有些團(tuán)隊(duì)會(huì)想省事降級(jí)處理成這次改動(dòng)很小就不用重新走流程了但改動(dòng)小不小不由改動(dòng)者說了算得由影響面評(píng)估說了算。規(guī)定里可以留一個(gè)快速通道僅修改文案、配置且不涉及邏輯的允許走簡化評(píng)估但仍然要換版本號(hào)重新歸檔制品。3.2 灰度階段的版本怎么標(biāo)識(shí)灰度本質(zhì)上是同一版本在小范圍先跑所以灰度和全量應(yīng)該是同一個(gè)版本號(hào)而不是兩個(gè)。這一點(diǎn)常被搞混有人把灰度包和全量包當(dāng)成兩個(gè)版本結(jié)果臺(tái)賬里多出一條記錄對(duì)賬的時(shí)候找不到對(duì)應(yīng)關(guān)系。正確的做法是版本號(hào)保持一致用發(fā)布批次或者流量比例來區(qū)分階段臺(tái)賬里記錄的是2.5.0 在灰度批次 A、B 各發(fā)布一次?；叶绕陂g如果發(fā)現(xiàn)問題需要修復(fù)那就不能就地改灰度包而是從發(fā)布分支拉修復(fù)、漲修訂位、重新走提測和歸檔形成 2.5.1然后決定是繼續(xù)灰度還是全量。這個(gè)過程雖然麻煩但它保證了線上跑的每一份代碼都能在制品庫里找到對(duì)應(yīng)的不可變產(chǎn)物。我見過就地改包的做法改完之后線上版本號(hào)沒變出問題時(shí)按版本號(hào)去查制品查到的還是修改前的那份排查方向直接跑偏?；叶冗€會(huì)帶來一個(gè)隱蔽問題不同實(shí)例上跑的版本號(hào)不一致。發(fā)布過程中一部分機(jī)器先更新另一部分還沒更新這個(gè)時(shí)候如果去查線上版本答案是不唯一的。所以版本查詢接口要能返回實(shí)例粒度的版本分布而不是一個(gè)全局值。這個(gè)能力在排查灰度期問題時(shí)幾乎是剛需。3.3 回滾不是版本號(hào)減一回滾這件事我在規(guī)定里單獨(dú)寫了一節(jié)因?yàn)榻^大多數(shù)翻車都發(fā)生在這里?；貪L到上一個(gè)版本絕不等于把版本號(hào)從 2.5.0 退成 2.4.3 那么簡單它至少要考慮三件事數(shù)據(jù)結(jié)構(gòu)的兼容性、配置的回退、以及回滾動(dòng)作本身要不要記錄為一個(gè)版本。數(shù)據(jù)結(jié)構(gòu)這塊最要命。如果 2.5.0 上線時(shí)加了字段、改了表結(jié)構(gòu)回滾到 2.4.3 之后老代碼可能讀不懂新數(shù)據(jù)或者寫入了新代碼無法識(shí)別的內(nèi)容。所以規(guī)定里要有一條涉及數(shù)據(jù)庫結(jié)構(gòu)變更的版本必須同時(shí)提交回滾腳本和兼容性說明明確標(biāo)注該版本是否可回滾。不可回滾的版本要在發(fā)布評(píng)審時(shí)被單獨(dú)標(biāo)記出來上線決策也會(huì)因此不同。配置回退同樣容易被漏掉。代碼回退了配置中心里的參數(shù)還停留在新版本的狀態(tài)導(dǎo)致行為不一致。所以回滾清單里要包含配置項(xiàng)的回退動(dòng)作最好由配置中心支持按版本回退而不是人工改。至于回滾這個(gè)動(dòng)作本身我的做法是把回滾也當(dāng)作一次正式發(fā)布來記錄臺(tái)賬里新增一條記錄注明回滾至 2.4.3原因、操作人、時(shí)間而不是把原來那條 2.5.0 的記錄刪掉。歷史不能擦除只能追加這樣事后復(fù)盤才有據(jù)可查。4. 制品管理讓版本號(hào)真正對(duì)得上東西4.1 不可變制品是整條規(guī)定的地基如果說版本管理規(guī)定只有一條是必須執(zhí)行的我會(huì)選制品不可變。具體含義是一個(gè)版本號(hào)一旦歸檔對(duì)應(yīng)的制品就再也不能被覆蓋或刪除需要改動(dòng)就換新版本號(hào)重新構(gòu)建。這條規(guī)則看起來嚴(yán)苛但它是所有溯源能力的前提。如果制品可以被覆蓋那么版本號(hào)就失去了標(biāo)識(shí)意義等于一個(gè)隨時(shí)會(huì)變的別名。為了支撐這條規(guī)則制品庫里要禁止覆蓋推送重復(fù)推送同一個(gè)版本號(hào)時(shí)直接報(bào)錯(cuò)而不是靜默覆蓋。這個(gè)特性在多數(shù)制品倉庫里都能配置值得花時(shí)間打開。我見過因?yàn)闆]開這個(gè)開關(guān)流水線重跑一次就把已歸檔的包覆蓋了兩個(gè)月后排查線上問題時(shí)本地復(fù)現(xiàn)不出來因?yàn)橹破芬呀?jīng)變了。構(gòu)建信息要寫進(jìn)制品。至少在制品里包含一個(gè)描述文件記錄源碼提交哈希、構(gòu)建時(shí)間、構(gòu)建人、流水線編號(hào)、依賴清單的哈希值。這樣從版本號(hào)出發(fā)可以一路查到具體代碼而不是只能查到大概是那幾天的主干。這一步做起來不復(fù)雜但帶來的排查效率提升是數(shù)量級(jí)的出問題時(shí)先拿版本號(hào)查出提交哈希再用哈希去看變更兩分鐘就能圈定范圍。4.2 依賴鎖定不能靠自覺內(nèi)部服務(wù)之間的依賴如果用范圍版本比如[2.0,3.0)那構(gòu)建結(jié)果就不可復(fù)現(xiàn)。今天構(gòu)建和明天構(gòu)建可能拉到不同的依賴同一個(gè)版本號(hào)產(chǎn)出的東西不一樣這直接違背制品不可變的原則。所以規(guī)定里要寫明內(nèi)部依賴一律使用固定版本禁止在正式發(fā)布的制品中使用范圍版本或最新版本標(biāo)識(shí)。外部三方依賴同理鎖定文件必須提交到代碼庫不能放在忽略列表里。這個(gè)問題我在兩個(gè)項(xiàng)目里都遇到過表現(xiàn)是一樣的本地能跑CI 上跑不起來因?yàn)?CI 重新解析依賴時(shí)拉到了新版本。鎖定文件提交之后構(gòu)建結(jié)果才真正穩(wěn)定下來。還有一個(gè)細(xì)節(jié)依賴升級(jí)本身也要走版本號(hào)。比如某個(gè)公共庫從 1.2 升到 1.3使用方要做的是在自己的版本號(hào)上體現(xiàn)這次依賴變更而不是悄無聲息地跟著升。依賴變更屬于變更內(nèi)容必須寫進(jìn)發(fā)布說明否則出問題時(shí)沒人會(huì)想到是依賴引起的。4.3 制品保留策略要有明確規(guī)則制品庫不可能無限增長所以要規(guī)定保留策略。我的做法是按版本類型區(qū)分正式發(fā)布版本永久保留至少保留到該大版本線終止維護(hù)候選版本保留最近若干個(gè)超過數(shù)量的可以清理快照版本保留最近若干天。規(guī)則要寫進(jìn)制度而不是讓運(yùn)維憑感覺刪。清理動(dòng)作本身也要謹(jǐn)慎。清理前必須確認(rèn)該版本沒有被任何環(huán)境的臺(tái)賬引用尤其是那些還在灰度或者還有客戶在用的老版本。我經(jīng)歷過一次清理把某個(gè)老版本的制品刪了結(jié)果出了一次需要在這個(gè)老版本上打補(bǔ)丁的情況只能重新構(gòu)建而重新構(gòu)建出來的東西和當(dāng)年發(fā)布的并不完全一致依賴已經(jīng)更新最后只能如實(shí)向客戶說明差異。這個(gè)麻煩完全可以避免。5. 發(fā)布說明與版本臺(tái)賬出事后三分鐘定位5.1 發(fā)布說明寫什么、不寫什么發(fā)布說明不是營銷文案不需要把每個(gè)改動(dòng)都包裝得漂亮。它要回答的是運(yùn)維和排查人員關(guān)心的問題這次改了什么、影響哪些模塊、有沒有配置變更、有沒有數(shù)據(jù)庫變更、回滾怎么做。我建議用固定結(jié)構(gòu)寫不出來的地方填無而不是省略因?yàn)槭÷詴?huì)讓人無法判斷是沒有還是忘了寫。欄目內(nèi)容要求常見缺失變更清單按需求單號(hào)列出標(biāo)明類型只寫優(yōu)化若干問題影響范圍涉及的服務(wù)、接口、頁面漏寫下游依賴配置變更新增、修改、刪除的鍵及默認(rèn)值完全沒提數(shù)據(jù)變更腳本、是否可回滾只給腳本不說兼容性回滾方案步驟、預(yù)估耗時(shí)、決策人寫直接回滾優(yōu)化若干問題這種寫法我見一次打回一次。它的問題不在于不詳細(xì)而在于無法和代碼變更對(duì)應(yīng)出了問題想反查是哪次改動(dòng)引起的根本無從下手。變更清單里的每一項(xiàng)都要能對(duì)應(yīng)到具體的提交或者合并請(qǐng)求這是發(fā)布說明和版本臺(tái)賬能打通的關(guān)鍵。5.2 臺(tái)賬要記錄的是事實(shí)不是計(jì)劃版本臺(tái)賬和發(fā)布計(jì)劃是兩回事。計(jì)劃寫的是打算發(fā)什么臺(tái)賬寫的是實(shí)際發(fā)了什么。臺(tái)賬里每一條記錄至少包含版本號(hào)、制品哈希、發(fā)布環(huán)境、發(fā)布時(shí)間、操作人、對(duì)應(yīng)的發(fā)布說明編號(hào)、灰度批次或者流量比例、當(dāng)前狀態(tài)。狀態(tài)包括已發(fā)布、已回滾、已下線狀態(tài)是追加變更的不能直接改歷史記錄。為什么強(qiáng)調(diào)記錄事實(shí)因?yàn)槭潞髲?fù)盤時(shí)人們回憶的內(nèi)容往往和實(shí)際情況有偏差。我記得那次只發(fā)了后端結(jié)果臺(tái)賬一查前端也發(fā)了。有了臺(tái)賬爭論就變成了查表。我在項(xiàng)目里推行臺(tái)賬之后最直觀的變化是事故復(fù)盤會(huì)的時(shí)間縮短了一半因?yàn)椴辉傩枰〞r(shí)間確認(rèn)當(dāng)時(shí)發(fā)了什么直接看記錄。臺(tái)賬最好和發(fā)布系統(tǒng)聯(lián)動(dòng)能自動(dòng)寫入的就別讓人手填。手填的數(shù)據(jù)必然會(huì)漏、會(huì)錯(cuò)而且填的人覺得這是額外負(fù)擔(dān)。自動(dòng)采集加上人工補(bǔ)充關(guān)鍵字段比如回滾原因、影響范圍是可持續(xù)的做法。5.3 版本一致性要能自動(dòng)校驗(yàn)前面所有的規(guī)則最終都要落到三個(gè)地方對(duì)得上線上實(shí)際運(yùn)行的版本、制品庫里的制品、臺(tái)賬里的記錄。這三個(gè)地方任意兩個(gè)對(duì)不上就意味著有一環(huán)失控了。所以規(guī)定里要包含定期校驗(yàn)的要求最好做成自動(dòng)化任務(wù)。校驗(yàn)邏輯并不復(fù)雜從線上采集實(shí)例版本去制品庫查詢?cè)摪姹臼欠翊嬖谌ヅ_(tái)賬查詢是否有對(duì)應(yīng)記錄且狀態(tài)一致。不一致就告警。這條告警的價(jià)值在于它能在問題爆發(fā)之前發(fā)現(xiàn)流程漏洞。比如某次有人繞過流水線手工發(fā)包線上版本和臺(tái)賬就對(duì)不上校驗(yàn)任務(wù)當(dāng)晚就會(huì)報(bào)出來。我在一個(gè)項(xiàng)目里加上這個(gè)校驗(yàn)之后第一次運(yùn)行就發(fā)現(xiàn)了三個(gè)歷史遺留的不一致其中一個(gè)已經(jīng)存在了半年多誰也不知道那份代碼是怎么上去的。校驗(yàn)結(jié)果的處置也要有規(guī)定發(fā)現(xiàn)不一致必須在規(guī)定時(shí)間內(nèi)處理處理方式只有兩種要么補(bǔ)齊記錄要么把線上版本糾正到與記錄一致。不允許先放一放因?yàn)榉乓环潘蜁?huì)變成一個(gè)沒人敢碰的歷史遺留。6. 制度怎么推下去模板、流水線和例外登記6.1 從最小可行的模板開始制度推不動(dòng)十有八九是因?yàn)橐婚_始就寫得太全。我見過幾十頁的版本管理規(guī)定發(fā)下去沒人看因?yàn)槔锩嬉话氲膬?nèi)容和當(dāng)前團(tuán)隊(duì)的實(shí)際流程無關(guān)。更可行的做法是先做最小版本規(guī)定版本號(hào)格式、規(guī)定 Tag 不可變、規(guī)定制品不可覆蓋、規(guī)定發(fā)布必須有發(fā)布說明。就這四條覆蓋了最常見的混亂來源而且執(zhí)行成本低。模板比文字規(guī)定更能約束行為。把版本號(hào)格式做成提單模板的必填字段并帶格式校驗(yàn)把發(fā)布說明做成固定表單把回滾方案做成必填項(xiàng)這些東西比寫十頁應(yīng)當(dāng)如何如何有用得多。人在填表的時(shí)候被動(dòng)遵守規(guī)則比讀完文檔再主動(dòng)遵守的成功率高得多。起步階段允許有例外但要登記。規(guī)定里寫清楚例外的申請(qǐng)方式、審批人、以及事后要在多少天內(nèi)補(bǔ)齊。例外不是違規(guī)而是有意識(shí)的偏離登記了就能追蹤不登記就成了失控。6.2 把規(guī)則嵌進(jìn)流水線而不是寫在文檔里這是我踩過最大的一個(gè)認(rèn)知坑。早期我以為只要文檔寫得清楚大家就會(huì)照做。實(shí)際情況是人在趕進(jìn)度的時(shí)候文檔永遠(yuǎn)排在最后。后來我把能自動(dòng)化的規(guī)則全部嵌進(jìn)流水線分支名不符合規(guī)范流水線直接失敗版本號(hào)格式不對(duì)構(gòu)建階段就攔下來嘗試往制品庫推送已存在的版本直接報(bào)錯(cuò)單獨(dú)構(gòu)建正式版本而不關(guān)聯(lián)發(fā)布說明編號(hào)不允許歸檔。規(guī)則一旦變成流水線的失敗條件它就有了強(qiáng)制力。文檔負(fù)責(zé)解釋為什么流水線負(fù)責(zé)保證必須做兩者分工明確。這樣做還有一個(gè)好處新同學(xué)不需要通讀文檔就能上手因?yàn)樗峤坏拿恳徊蕉紩?huì)被系統(tǒng)校驗(yàn)出錯(cuò)時(shí)的提示就是最好的培訓(xùn)材料。當(dāng)然攔截規(guī)則要一次加一條加完觀察一段時(shí)間。一次性加太多正常發(fā)布全被攔住大家就會(huì)想辦法繞過反而破壞了制度的權(quán)威性。我一般是在某類問題連續(xù)出現(xiàn)兩次以上之后再把它變成自動(dòng)攔截這樣每次攔截都有現(xiàn)實(shí)依據(jù)團(tuán)隊(duì)也更容易接受。6.3 例外和復(fù)盤要形成閉環(huán)再完善的制度也會(huì)遇到例外比如緊急故障需要立刻修復(fù)。規(guī)定里要留一條快速通道但這個(gè)通道的代價(jià)是必須在限定時(shí)間內(nèi)補(bǔ)齊全部記錄包括發(fā)布說明、臺(tái)賬和回滾方案。緊急不是豁免記錄的理由緊急只是允許你先做后補(bǔ)。每隔一段時(shí)間要復(fù)盤一次版本相關(guān)的問題看看是規(guī)則缺失還是執(zhí)行不到位。如果是規(guī)則缺失就補(bǔ)規(guī)則如果是執(zhí)行不到位就看看能不能自動(dòng)化攔截。這個(gè)循環(huán)跑起來之后制度才會(huì)慢慢貼合團(tuán)隊(duì)的實(shí)際而不是一份寫完就沒人碰的文件。我個(gè)人的體會(huì)是版本管理規(guī)定最忌諱一次成型、長期不變它應(yīng)該像代碼一樣被維護(hù)和迭代每次出事都是它進(jìn)化的機(jī)會(huì)。最后分享一個(gè)我一直在用的小技巧把當(dāng)前各環(huán)境的版本號(hào)做成一頁隨時(shí)可查的面板放在團(tuán)隊(duì)最常打開的地方。這一頁不需要復(fù)雜的權(quán)限所有環(huán)境、所有實(shí)例的版本一目了然。很多關(guān)于版本的爭論本質(zhì)上是因?yàn)樾畔⒉煌该饕坏┐蠹铱吹亩际峭环輸?shù)據(jù)討論就會(huì)從你說是多少變成數(shù)據(jù)上是多少溝通成本一下子就降下來了。這件事我做了之后最明顯的變化是再也沒人問我線上現(xiàn)在是什么版本了。