1.編寫目的

主要針對軟體版本的流程, 以確保公司資產得到保護。

2.適用範圍

該流程適用於產品研發部門。

3.環境資源

在整個產品生命週期中，以gitlab作為公司主要程式碼倉庫。

4.流程

流程分為版本號定義、版本釋出

4.1 版本號定義

4.1.1 版本號規則採用語義化版本

版本格式：主版本號.次版本號.修訂號，版本號遞增規則如下：

主版本號：當你做了不相容的 API 修改，

次版本號：當你做了向下相容的功能性新增，

修訂號：當你做了向下相容的問題修正。

專案版本號可加到“主版本號.次版本號.修訂號”的後面，作為延伸。

4.1.2 部署包版本

對於產品，採用上面的規則，比如1.0.0

對於專案，在上面版本的基礎上，再追加一個版本號：-客戶名字.項

目版本號，比如1.0.0-xinqiao.01

4.1.3 正式釋出版本

正式釋出版本的版本號規則：release主版本號.次版本號.修訂號

linux、windows專案都需要支援離線的部署包。

4.2 版本釋出流程

4.2.1整體流程

說明:

1. 研發自測通過,定版後通過郵件釋出releasenotes。
2. 測試經理接收到release notes開始測試, 測試通過後釋出測試結果,並進行版本checklist檢查。 測試不通過打回, 開發重新定版釋出,並彙總所有釋出版本。
3. 運維配置人員收到測試通過郵件, 並按照正式release命名規則進行產品釋出/備份。
4. 釋出過程通過郵件傳送通知，整體版本文件彙總在wiki空間。
5. 通用產品組釋出須抄送產品評審組、技術評審組，運維組，測試組。

4.2.2程式碼合入、編譯打包與自測、研發釋出流程

版本轉測試前,開發確認相關程式碼已全部合入gitlab庫, 由開發統一介面人記錄轉測試程式碼所對應的gitlab版本號,打包 –> 自測 -> 封版。

開發自驗通過標準:

1. 開發階段, 以開發人員開發的模組功能特性效能指標階段性達到需求要求, 並且本次轉測試的bug修改自驗通過, 程式無致命問題, 可轉測試。
2. 維護階段, 本次要轉測試的bug修改自驗通過, 程式無致命問題, 可轉測試。

通過郵件釋出產品releasenotes，包含以下版本配套文件列表:

文件模板參考：

4.2.3開發轉測試

測試進行產品測試，並通知運維人員釋出到測試環境。

測試完成之後，測試人員通過郵件遞交《版本釋出checklist》。審批通過後，運維定版。

版本釋出checklist：

4.2.4 產品釋出/備份

運維配置人員按照正式釋出版本進行產品釋出。 離線部署包隨產品釋出

歸檔，放到運維指定位置。