版本管理說明文檔?産品版本項目/子項目所定義的版本，兩節：x.y如智計劃1.2，那麼這個産品版本号為1.2，我來為大家講解一下關于版本管理說明文檔?跟着小編一起來看一看吧!

版本管理說明文檔

産品版本

項目/子項目所定義的版本，兩節：x.y。如智計劃1.2，那麼這個産品版本号為1.2。

工程版本

代碼構建産物的版本。工程版本号通常為四節,x.y.z.build。x.y 繼承産品版本号；z在敏捷項目團隊中是沖刺編号，在瀑布團隊中為流水号。該節用于區分不同的研發、上線周期；build為構建流水号，通常由構建工具自動生成。

測試代碼同樣也有工程版本号。目前測試代碼沒有發布流程，也沒有通過工具發布，所以z.build由測試團隊人員自行決定。原則上每一次正式交付，變更z。

發布标簽

每一次發布到生産，在git代碼庫中，給對應的commit标記一個标簽，值為部署物的工程版本，即x.zy.z.build。

統一分支管理策略以及定義。版本化一切，最終提高項目的團隊合作效率、加速新功能開發和發布管理。

• 采用GitHub Flow策略（推薦）或基于主幹開發策略。
• 要求項目有完善的自動化測試、持續集成和部署等相關的基礎設施。
• 版本化一切。
• 團隊有代碼審查的相應流程。
• 具備自動部署的條件

• 必須：代碼應放在集團統一的代碼倉庫。
• 必須：工程的可見性不能設置為public。
• 必須：隻允許給項目相關開發人員配置權限，并應該遵循最小授權原則。
• 必須：代碼項目創建在團隊空間内，不允許放在個人空間。
• 建議：團隊空間命名格式為：group/[subgroup]。group為産品線簡稱，如果産品線有多個子産品，再加上subgroup。subgroup為子産品簡稱。如 gaia/gfs，group=gaia，subgroup=gfs。
• 建議：代碼項目命名格式為：項目代号-模塊[-子模塊][-孫模塊]。如：gaia-gfs-demo，halo-wechat。這樣，GIT中完整的空間-項目名為：gaia/gfs/gaia-gfs-demo。

• 必須：master分支被保護，不允許直接提交至master。
• 必須：創建分支使用有意義的名稱頭，功能開發用 feature/{JIRA編号}-*，bug修複用 bug/{JIRA編号}-*，熱修複用 hotfix/{JIRA編号}-*。如 feature/XM1907901-1390-enable_audit_log_for_inventory, bug/XM1907901-1403-xxxxxxx。
• 建議：創建分支開始後，就創建一個MR，用于描述思路，并記錄讨論過程。
• 建議：未完成的MR以WIP:開頭，如：“WIP:用戶1分鐘未有動作，自動鎖屏”。
• 必須：至少有一個成員同意合并，才允許合并分支。
• 建議：合并分支時，使用 --squash，或選中gitlab界面上的"[X]Squash commits when merge request is accepted"。

• 必須：每一次準備發布生産的交付物，打上發布标簽，并記錄Release Notes。
• 建議：數據庫有版本号。不同版本的數據庫變更腳本，支持幂等操作，以便自動化完成升級/降級。
• 建議：測試用例、測試數據也有版本号，要麼和代碼工程版本一緻，要麼自定義，和代碼工程版本有對應關系。
• 建議：推薦使用Flyway，EntityFramework Migrations來管理DB版本。

1. 敏捷項目沖刺開始，定義本沖刺版本的前三節。
2. 提交、解決、關閉bug時，正确填入了DevOps中對應的工程版本号。
3. DevOps構建時，根據前三節，自動補充最後一節的編譯流水号。
4. 發布至生産環境時，DevOps根據工程版本，自動生成tag标簽。
5. 如果隻通過DevOps部署，則沒有沖刺版本。DevOps根據産品版本，自動加上制品的上傳批次号，如1.2.13，以追蹤各環境和不同版本部署物的對應關系。

開發流程

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!