一种 gitlab 版本管理策略

有运维或运维开发方面的需求,可以联系博主QQ 452336092或Email:admin#centos.bz(收费)

背景

  • 目前负责小组内源码的版本管理,将目前的我们的源码管理策略做一番梳理和分享,以期共同进步。

流程

  1. 先建立主分支master

  2. Owner基于master建立开发分支xxx-dev-v1,xxx-release-v1,分别是第一期开发版本,第一期发布版本。

  3. xxx-dev-v1供开发人员拉取并开发,功能点开发完成且单元测试通过后,将开发代码提交到xxx-dev-v1上。

  4. 测试人员测试xxx-dev-v1的代码,测试通过后,由本人将xxx-dev-v1的代码合并到xxx-release-v1,待发布。发布前若测试人员发现bug,则重复3、4步。

  5. 发布时,由Owner将xxx-release-v1合并到master分支,合并后master分支打tag,如master> git tag 20171220-v1.0,然后运行自动发布脚本进行发布。

  6. 项目是迭代开发,第一期完成后该进行第二期开发,命名方式相同,依次类推。

  7. 如果在开发V2的过程中,需要紧急修复V1(线上)中的漏洞,则重复3、4、5步,并在最后将master的代码合并到V2上,以保证V2的代码最新;如评估后不紧急,可放在V2中开发。

注意

  1. 务必保证master是线上最新版本。

  2. 可改进的地方:经过一段时间的策略使用,认为目前的问题在于角色分工上不够明确,具体表现在两个问题:(1)开发人员代码开发并提交dev分支后,应该提起dev到release的合并请求,由Owner审核后通过,而不是Owner发起合并(2)测试人员在测试没有bug后应提起release合并到master的请求,而不是由Owner发起合并。

原文出处:flcoder -> http://flcoder.com/articles/2017/12/20/1513749064701.html?utm_source=tuicool&utm_medium=referral

打赏

如果此文对你有所帮助,请随意打赏鼓励作者^_^