Gitlab分支策略建议指南

本文分支策略为总结各中小型企业常见做法(仅代表个人观点),在下才疏学浅,文章如有缺漏或不当之处,望各位帮忙指正。写此文也十分希望能起抛砖引玉之效。

据我所知,目前大部分无论是按瀑布/敏捷开发模型,就算服务器资源十分有限的情况下,一套相对标准的研发流程也都应该至少具有开发(DEV)/测试(TEST)/生产(PROD)三个环境(集群)。

环境说明

  • 开发环境(DEV): 此服务环境一般为开发人员进行代码开发,单元自测,以及实验的稳定环境。
  • 测试环境(TEST): 开发人员提交测试后,将相关代码,服务环境部署到此环境,由测试人员对此环境的服务进行专业性的二次测试,例如基准测试,安全测试,业务逻辑验证等等。
  • 生产环境(PROD): 当测试环境得到充分的验证之后并满足发布生产条件,会将相关代码,服务环境部署到此环境,提供正式服务。

分支说明

  • feature(-xx): 功能分支,每个功能分支应该代表着每个固定的迭代或开发功能集版本。
  • dev: 开发分支(保护分支),每次推送(Push) 代码到此分支时,会触发固定流水线(pipeline),部署应用到开发环境。
  • test: 测试分支(保护分支),每次推送(Push) 代码到此分支时,会触发固定流水线(pipeline),部署应用到测试环境。
  • main(master): 主分支(保护分支),不允许直接进行推送(Push)操作,需要合并应当发起Pull Request(PR),由负责生产环境的同事对此PR进行合并,此分支代码对应生产环境。
  • hotfix: 紧急修复分支,俗称救火分支,当生产环境发生问题需要紧急修改代码时,由开发人员从main分支创建出来的新分支,在此分支上紧急修改代码后,合并到测试环境,测试验证通过后,直接发起Pull Request(PR)提交到main;此分支一般在紧急修复线上问题之后,可将其合并(merge)到dev,再将此分支删除。

单一功能迭代型分支策略

适用场景: 统一开发迭代版本,统一提测流程,统一上线流程

不适用场景: 多功能并行开发,多功能分别提测

适用人数:3-5人

流程图说明

  • 开发 : 所有开发人员均在统一迭代分支(feature)上开发(包括修复bug),在功能分支开发自测,单元测试无误后并需要进行接口联调时,合并(merge)到dev(开发分支),触发开发环境持续集成过程。
  • 联调 : 提交到开发环境进行前后端联调,当联调通过之后,按照约定时间进行前后提测(前后端可分别提测),提测时,由开发人员将dev(开发分支) 合并(merge)到test(测试分支)上,触发测试环境持续集成过程。
  • 提测 : 提交测试后,测试人员对测试环境进行验证,测试中产生的bug,开发人员应该在feature上面进行修复,然后统一按批次和时间进行重新推送(push)开发分支(dev)和合并(merge)测试(test)过程
  • 上线 : 当测试环境代码已满足本次迭代所有功能,并且所有测试中产生的bug全部修复得到验证时,此时由研发负责人发起Pull Request (PR)test -> main提交到,并编写上线清单(包含上线数据脚本,外部依赖服务,上线配置细节等等),通知负责生产环境的同事合并,按照上线约定时间和上线清单进行上线。
  • 修复 : 当线上遇到需紧急修复的问题时,由开发人员从main分支创建出hotfix分支,在此分支上修改代码后,合并到测试环境,经过测试验证通过后由研发负责人发起Pull Request(PR)hotfix -> main,进行紧急修复上线流程。

说明: 此分支策略下,feature分支可以看作为开发人员熟悉的local分支,feature,dev,test均允许互相合并(merge)

多功能并行迭代型分支策略

适用场景: 多迭代版本并行开发,分别提测流程,分别上线流程,差异化上线

不适用场景: 多并行开发版本中有交叉内容。

适用人数:3-5人和20人以上

流程图说明

  • 功能开发 : 开发人员按组在不同的对应迭代分支(feature-xx)上开发(包括修复bug),在功能分支开发自测,单元测试无误后并需要进行接口联调时,合并(merge)到dev(开发分支),触发开发环境持续集成过程;多功能分支可并行开发。
  • 并行联调 : 提交到开发环境进行前后端联调,当联调通过之后,按照约定时间进行前后提测(前后端可分别提测),提测时,由开发人员将feature-xx(功能分支) 合并(merge)到test(测试分支)上,触发测试环境持续集成过程。
  • 并行提测 : 提交测试后,测试人员对测试环境进行验证,测试中产生的bug,开发人员应该在feature-xx上面进行修复,然后严格统一按批次和时间合并(merge)开发和合并(merge)测试(test)过程,以避免频繁发布造成测试环境不稳定。
  • 功能上线 : 当测试已满足本次迭代所有功能,并且所有测试中产生的bug全部修复得到验证时,此时由研发负责人发起Pull Request(PR)feature-xx -> main,并编写上线清单(包含上线数据脚本,外部依赖服务,上线配置细节等等),通知负责生产环境的同事合并,按照上线约定时间和上线清单进行上线。
  • 修复 : 当线上遇到需紧急修复的问题时,由开发人员从main分支创建出hotfix分支,在此分支上修改代码后,合并到测试环境,经过测试验证通过后由研发负责人发起Pull Request(PR)hotfix -> main,进行紧急修复上线流程。

使用注意

  • 此分支策略下,dev作为开发环境公共验证分支,test作为公共提测分支,feature-xx分支作为主要并行开发使用分支 ,最终会直接PR到main(主分支), 开发人员务必最大程度保证此分支代码的稳定。
  • 务必禁止开发人员对devtest进行相互合并(merge);禁止任何从feature-xx -> mainhotfix -> main以外内容发起的Pull Request (PR)
  • 所有feature-xx分支不可进行相互合并(merge)
张贴在2