軟件工程之美35講——版本發佈:軟件上線只是新的開始

軟件工程之美35講——版本發佈:軟件上線只是新的開始

版本號構成

  版本號 . 子版本號.[. 修正版本號.[構建版本號]]比如說:1.2.1、2.0、3.0.1 build-123。
  其中主版本號和子版本號用來標識功能變化,小的功能變化增加子版本號,大的功能變化增加主版本號。
  修正版本號則表示功能不變化的情況下修復 Bug,而構建版本號表示一次新的構建,這個通常由編譯程序自動生成。團隊中對版本有了清晰的定義和良好的版本編號,在討論版本時,你就可以根據版本號清楚地知道應該有哪些功能,屬於哪一次的構建結果。在修復 Bug 或者增加功能時,開發人員也能清楚地知道代碼應該加入哪個版本。在驗證 Bug 時,測試人員就可以知道應該在哪個版本中驗證 Bug 有沒有被修復。

怎麼做好版本號管理

版本發佈前,做好版本發佈的規劃

  • 首先是規劃好要發佈的功能。在發佈前,搞清楚哪些是用戶必須要有的功能,哪些是用戶可以沒有的功能。對於必須要有的功能,那麼要保證軟件中有這個功能才能發佈,對於不是必需的功能,可以以後再逐步完善。
  • 再有就是要設計好發佈的策略。考慮好是直接發佈給所有用戶?還是先讓一部分用戶試用?比如說可以先讓內部用戶使用,內部用戶對軟件質量問題容忍度是很高的,還可以幫助發現很多問題。
  • 最後,就是有一個綜合性的版本發佈計劃。在確定了要發佈的功能、定義好了質量標準、設計好了發佈策略,就可以制定一個綜合性的版本發佈計劃了,確定好發佈的時間點。

規範好發佈流程,保障發佈質量

  • 在發佈之前要做代碼凍結。

  什麼是代碼凍結呢?就是在發佈之前,對於要發佈的版本,在源代碼管理工具中,專門創建一個 release 分支,然後對於這個分支的代碼,凍結功能的修改,不接受新功能的增加,甚至重要性不高的 Bug 都不修改,只修復重要的 Bug。由於嚴格的控制代碼的修改,這樣可以讓版本的質量逐步趨於穩定。

  • 對代碼凍結後發現的 Bug 要分級

在代碼凍結後,可能還存在一些 Bug,測試的過程中也會新增一些 Bug。代碼凍結的原則就是儘可能減少代碼的修改,避免引起不穩定。所以對於這些 Bug,要有一個簡單的分級:是否在發佈前修改,還是留在發佈後再修改。至於如何對一個 Bug 分級,這需要項目負責人和產品負責人一起確認。

  • 每次修復 Bug 後,發佈新的候選版本

  進入代碼凍結後,開發人員還需要對一些 Bug 進行修復,每一次修復完 Bug 後,就要生成一個新的候選發佈版本,比如說 1.1 RC1、1.1 RC2。關於生成發佈版本,現在比較流行的做法是和持續集成系統整合,完全自動化。也就是在自動化測試通過之後,會自動構建,生成各個環境的發佈版本。這樣好處是,可以避免人爲失誤導致的錯誤,另外程序的配置管理做好了的話,只要測試環境的版本在測試環境測試沒問題,那麼就可以認爲在生產環境的版本也是正常的。自動化構建,生成發佈版本並不複雜,各個語言都有成熟的方案,如果你還不瞭解的話,可以通過搜索引擎搜索關鍵字:“[對應平臺] 自動打包”,例如搜索“iOS 自動打包”、“iOS build automation”這樣的關鍵字。其中稍微有點麻煩的就是如何應用不同環境下的不同配置,比如說測試環境連測試環境服務器,生產環境連生產環境服務器。有關程序配置管理部分,可以參考這篇文章:《大型項目程序配置管理演化之路》

  • 每次部署新的候選發佈版本後,要做迴歸測試

  在每次開發人員部署新的候選發佈版本到測試環境後,還需要做一次迴歸測試。也就是說在 Bug 修復完,對主要流程要重新測試一遍,同時還要對之前確認過的 Bug 再確認一遍,以確保 Bug 確實修復了,並且沒有引入新的 Bug。如果當前候選發佈版本達到版本發佈的質量標準後,就可以準備發佈了。

  • 申請上線發佈

  上線發佈是一件很嚴謹的事,所以在正式上線發佈前,通常還需要有一個申請和審批的流程。審批的主要目的是要有人或者有部門統籌對所有的上線發佈有一個全面的瞭解和控制,避免上線過於隨意導致問題,避免和其他部門的上線衝突。

  • 部署發佈

  如果已經實現了自動化,部署發佈應該是非常簡單的一步。如果還沒有自動化部署發佈,也需要事先將詳細的操作步驟寫下來,避免部署發佈時發生紕漏,這樣在實際部署發佈時,按照事先寫好的步驟操作就不容易出現錯誤。

  • 上線後的測試

  項目上線後,測試人員需要馬上對已經上線的版本做一個主要功能的測試,以確保線上運行正常。如果做好了數據監控,還同時要對一些關鍵數據進行監控,例如服務器 CPU 利用率、內存佔用率、服務出錯率等數據。如果萬一發現版本上線後出現問題,需要考慮按照事先準備好的回滾方案進行回滾操作,儘量將損失降到最低。通常不到萬不得已,不建議馬上對問題打補丁進行修復。因爲哪怕很小的代碼修改,都可能會引入新的 Bug。而重新做一遍迴歸測試,耗時會比較長。以上就是版本發佈的一個常見流程,你也可以基於這個流程制定適合你項目的流程,讓你的版本發佈更加穩定可靠。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章