配置管理工作流程


業內實踐

git flow

固定遠程分支:

  • master分支: 主分支,和生產環境一致,存放已發布完成的版本
  • develop分支: 主開發分支,用於合並功能分支,維護公共的最新代碼

臨時遠程分支:

  • release分支: 預發分支,發布時基於Develop分支創建一個Release分支,完成Release后,我們合並到master和develop分支
  • feature分支: 功能分支,每個功能對應的分支,合並到develop分支和release分支后刪除
  • hotfix分支: bug修復分支,后合並到develop和master分支后刪除

優點:

清晰明了,每個分支都有都自己的作用,有工具或插件幫助操作者使用此流程。

缺點:

更加適合於按版本發布的項目,不太適合持續發布。 有的服務更期望代碼變動就發布一次,每次發布需要合並develop、release、master三個分支。

github flow

如圖,github flow非常簡單,只有一個固定的遠程分支marter。每個研發人員fork項目后,在本地用功能分支開發,開發完成后提交PR請求合並master分支。
PR請求通過后,合並至master分支並部署。master分支代表可以隨時上線的版本,並且可以通過持續發布系統,無限發布到生產環境。

但有些時候,PR被合並了之后我們可能也不會立刻就發布到生產環境,久而久之,生產環境就會落后master。

綜合git flow 和 github flow 的優缺點,在github flow的基礎上,增加一個production分支,用來標識目前已上線的版本。

配置流程

  • 項目管理員創建gitlab倉庫,創建並保護master分支,設立相關權限
  • 研發人員fork項目,生成自己的fork庫
  • 研發人員clone自己的fork庫至本地
  • 研發人員在本地新建功能分支,並提交至本地分支,也可以push功能分支至遠程fork庫備份
  • 研發人員定期與遠程主干分支同步
  • 研發人員推送至自己的fork庫
  • 不需要測試人員測試時:
    • 研發人員直接發起PR請求合並個人遠程倉庫的開發分支至項目遠程倉庫的master分支
    • CI自動執行代碼靜態檢查和單元測試
    • 項目管理員審核PR,合並請求完成開發流程
  • 需要測試人員測試時:
    • 研發人員通知項目管理員在項目遠程分支中創建功能分支,研發人員發起PR請求合並個人遠程倉庫的開發分支至項目遠程倉庫的對應分支
    • CI自動執行代碼靜態檢查和單元測試
    • 項目管理員審核PR,合並至項目庫的遠程功能分支
    • 測試人員拉取功能分支測試
    • 測試人員提出PR請求,合並遠程功能分支至master分支
    • CI自動執行單元測試
    • 項目管理員審核PR,合並請求完成開發流程
  • 項目管理員在發布平台選擇響應的master提交進行發布,發布后自動對master標記tag

Git commit日志規范

git checkout新分支時,分支名采用 feature_標題_erp#、bugfix_標題_erp#、refactor_標題_erp#

如:feature_batch_save_product_12345

git commit時提交日志規范如下:

<type>:<subject>
	
<body>

type 枚舉:

  • feat 新增功能
  • fix 修復bug
  • docs 修改了文檔、readme
  • style 不改變代碼邏輯,僅修改代碼樣式
  • refactor 非功能性重構
  • test 測試用例

subject: 描述主要變更內容

body: 主體內容,更詳細的說明文本,如erp地址等,可以為空

Code Review

提交Code Review之前要做什么?

  • 准備或者提交相關需求文檔以備審查者詢問
  • 編寫符合規范的代碼和合適的注釋
  • 考慮代碼是否有重構的可能
  • 單元測試全部通過,測試覆蓋率達標

**如何Code Review? **

  • 了解需求:這個提交是為了解決什么問題,是需求單、BUG修復、還是代碼重構,
    如果不明確,需要及時和代碼作者溝通和討論
  • 檢查代碼業務邏輯是否符合需求
  • 代碼是否符合相關代碼規范
  • 確認是否有更好的方式方法重構代碼
  • 檢查單元測試用例是否考慮全面
  • 如果代碼沒有問題,也寫上類似GOOD JOB之類的評論

Code Review之后可以做什么?

  • 對於代碼審查人表示感謝
  • 如果代碼審查沒有通過,不要往心里去,審查的是代碼,不是你
  • 嘗試對每一個評論做出回復
  • 等待合並分支,等待持續集成告訴你全部通過

項目結構規約

-doc 文檔文件夾,用來存放概要、詳設、API等文檔資料
-src 程序源碼文件夾,用來存放源碼
-db 數據庫文件夾,用來存放可執行的數據庫相關變更DDL腳本文件,如V1__init.sql,V2__feature_batch_save_product_12345.sql
-deploy (可選)用來存放部署相關文件,如shell腳本等
-.. 按項目自由配置
README.md 項目說明
Dockerfile


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM