我們今天從版本發佈聊起，也就是運行維護篇的討論學些。
對於版本發佈，很多程序員可能覺得是很簡單的事情，就是將程序編譯打包部署，但是實際發佈的時候，卻經常出現版本發不錯、或者發佈前倉促修改合入了代碼導致線上新問題的出現。
對於項目經理來說，版本發佈也是很糾結的事情，總覺得很多功能沒完成，很多Bug沒修復，總覺得沒有達到客戶的預期，害怕用戶的投訴和負面評價，結果版本發佈一拖再拖，導致遲遲無法上線。
所以今天我們一起討論學習一下如何做好版本發佈，保障好發佈產品的質量。
關於軟件版本
產品經理眼中的“版本”是指特定功能集合，開發人員眼中的“版本”是指某一次程序的構建結果，也就是說軟件版本包含兩部分含義，一部分代表特定功能集合，一部分代表某一次代碼構建的結果。
爲了明確標識軟件版本，需要對版本進行編號，目前業界在軟件本命名上，通過規則如下：
主版本號.子版本號.[.修正版本號.[構建版本號]]
比如說，1.2.1、2.0、3.0.1 build-123，其中主版本號和子版本號用來標識功能變化，小的功能變化增加子版本號，大的功能變化增加主版本號，修正版本號則表示功能不變化，只是修復了Bug，而構建版本號表示一次新的構建，這通常由編譯程序自動生成。
團隊對版本有了清晰的定義和良好的版本編號後在討論版本時，就可以根據版本號清楚指導應該有哪些功能，屬於哪一次構建結果，修復Bug或者增加功能時，開發人員也會清楚知道代碼應該加入哪個版本，驗證Bug時，測試人員也會知道應該在哪個版本中驗證Bug是否被修復。
版本發佈前，做好版本發佈的規劃
項目經理爲什麼經常感覺沒準備好，害怕上線發佈呢?根源上是他們對於功能和質量沒有信心，擔心發佈後出現很多問題。但是實際上，我們不需要完成所有的功能、沒有任何Bug、知道一個完美的版本上線才發佈版本，因爲完美是沒有止境的，這世界上沒有完美的軟件，比如著名的Windows、Office、iOS等都會在發佈後還要打補丁。
這裏的關鍵在於，要在用戶的心理預期和我們軟件的實際情況之間找打一種平衡，讓軟件的功能和質量，滿足好用戶的預期。
那我們如何做好版本的發佈規劃呢？
首先是規劃好要發佈的功能
發佈前，搞清楚哪些功能是用戶必須要有的功能，哪些是用戶可以沒有的功能，對於必須要有的功能，要保證軟件中有這個功能才能發佈，不需要的功能可以後續完善。我們知道的經典案例是第一代iPhone，複製粘貼功能都沒有，但是它在用戶界面和觸屏設計上做的非常好，一樣是成功的。
然後定義好發佈的質量標準
發佈前，搞清楚用戶對質量的容忍度，對哪些功能的質量要求高，哪些暫時沒那麼高，對於用戶很在意的功能，需要較高的發佈標準，反之，可以有較低的質量標準。我們舉個例子，微博這種社交類應用軟件，界面佈局存在小瑕疵，用戶可以忍受，但是如果是經常程序崩潰，導致學好久的內容丟失，這個是用戶無法容忍的。
再有就是要設計好發佈的策略
考慮好是直接發佈給所有的用戶使用，還是先讓一部分用戶使用？比如說可以讓內部用戶先使用，這可以幫助發現很多問題，比如Facebook的做法。
最後就是有一個綜合性的版本發佈計劃
在確定了要發佈的功能、定義好了質量標準、設計好了發佈策略，就可以制定一個綜合性的版本發佈計劃了，確定好發佈的時間點。
這個發佈計劃，需要通觀全局，不止在項目內部成員，還需要和項目之外利益相關方如客戶、市場運營人員，大家一起確定最終的發佈計劃。
規範好發佈流程，保障發佈質量
在規劃好發佈的版本後，要發佈版本就是很簡單的事情，就是將源代碼編碼、部署。
首先保證編譯部署的是正確的版本，例如當年的拼多多造成了幾千萬的褥羊毛時間，就是錯誤發佈了一個測試用的無門檻券，導致被鑽漏洞。
然後要保證版本穩定可靠，做開發的知道，每次修復一個Bug，都可能導致新的Bug產生，如果我們的代碼庫在發佈之前還一直在增加新的功能或者不停的修復Bug合入代碼，那質量是很難穩定下來的。
再就是發佈失敗後能回滾，我們都不能保證程序發佈後沒有嚴重問題，所以保險的辦法就是在部署後，如果發現發佈的版本出現嚴重問題，就要進行回滾操作，恢復到部署之前的狀態，即使有不可逆的升級，也需要事先做好應對措施，比如發佈公告、停止服務，儘快修復。
針對這些問題，我們現在都有一些好的實踐，比如說代碼凍結、Bug分級、迴歸測試等降低發佈風險、保障發佈產品的質量。之前我們提過，流程和規範能將好的實踐標準化流程化，讓大家可以共享經驗，那大廠一般都是什麼樣的發佈流程呢？
- 在發佈之前要凍結代碼
發佈之前，對於要發佈的版本，在源代碼管理工具中，專門創建一個release分支，對於此分支，凍結功能的修改，不接受新功能的增加，重要性不高的Bug也不合入
- 代碼凍結後發現的Bug分級
代碼凍結後發現的Bug，要進行簡單的分級，是否是重大的功能性Bug，決定是在發佈前修改還是留到發佈後再修改。對於Bug分級，需要項目負責人和產品負責人一起確認。
- 每次修復Bug後，發佈新的候選版本
每次修復完Bug後，就要生成一個新的候選發佈版本，比如1.1 RC1 1.1RC2。
關於生成發佈版本，現在流行的做法是和CI系統整合，完全自動化。也就是在自動化測試通過後，自動構建，生成各個環境的發佈版本，這樣可以避免人爲失誤導致的錯誤，另外如果程序的配置管理做好了話，只要測試環境的版本在測試環境OK的話，在生成環境應該也是OK的。
自動化構建，生成發佈版本並不複雜，每個語言都有成熟的方案，如果你還不瞭解的話，可以通過搜索引擎關鍵字：“【對應平臺】自動打包”，例如“iOS自動打包”關鍵字。
- 每次部署新的候選發佈版本後，要做迴歸測試
每次開發人員部署新的候選發佈版本到測試環境後，還需要做一次迴歸測試，也就是在Bug修復完，對主要流程要重新測試一遍，同時還需要對之前已經確認的Bug再確認一遍，以確保Bug確實修復了，並且沒有引入新的Bug。
如果當前候選版本達到版本發佈的質量標準後，就可以準備發佈了。
- 申請上線發佈
上線發佈流程比較嚴謹，必須申請和審批，審批的人要多上線發佈有一個全面的瞭解和控制
- 部署發佈
如果有了自動化，部署發佈應該是非常簡單的一步，沒有自動化部署發佈，也需要事先將詳細的操作步驟寫下來，避免部署發佈時發生紕漏。
- 上線後的測試
項目上線後測試人員需要馬上對已上線版本進行主要功能的測試以保證線上的正常運行，如果做好了數據監控，還同時要對一些關鍵數據進行監控，例如服務器CPU利用率、內存佔用、服務出錯率等數據。
如果萬一發現版本上線後出現問題，需要考慮按事先準備好的回滾方案進行回滾，不建議馬上對問題打補丁進行修復，可能很小的代碼修改，都可能引入新的Bug，而且重新做一遍迴歸測試耗時會很長。
軟件上線只是新的開始
我們的軟件上線後，不代表項目就結束了，用戶在使用我們的產品時可能會遇到一些Bug或者一些建議，所以需要給用戶反饋的渠道，通過收集用戶的反饋，可以進一步完善我們的軟件產品。
我們還需要對發佈的版本進行監控，比如說收集App Crash的Log、監控服務器資源佔用情況、監控API出錯的比例、監控網頁響應的速度等數據，好及時發現發佈的版本是有問題的，及時處以應對，回滾班恩或者發佈新的補丁版本。
所以，版本發佈上線只是一個新的開始！