源代码、编译包版本管理团队实践

目录

1、前言

2、源码版本管理

3、编译包版本管理

4、后话

---

1、前言

随着所搭建的团队人数越来越多，开始形成一个个独立小团队的时候，协同开发的机制重要性就显得格外重要。刚好最近要针对这块版本管理向领导做个总结汇报，我这里就顺便分享一下我们团队的一个整体做法。

2、源码版本管理

整体上我们团队还是以Gitflow为主，再根据我们团队具体情况做一定程度的裁剪。首先这里复述一遍Gitflow不好的地方。

Gitflow本质上还是基于Branch-based，本质上还是一种代码隔离技术。每个功能就拉一个Feature分支，然后准备做集成测试的时候就一起合并到Develop分支。这里有什么问题？

1、合并冲突。因为基于分支开发的话，按照大部分的开发习惯肯定做不到每天一起做合并到Feature分支，分支隔离时间越长，代码冲突可能性越大；

2、跟持续集成的理念相违背。持续集成讲究的是持续提交、持续合并、持续集成构建，通过自动化的测试保证代码的构建成本是相对较低的一个水平。 

 废话不多说，先上图。

1、常规版本流程

【 开发阶段 】

1、从Master主干拉取最新代码至Develop和Feature分支；

2、针对部分开发人员团队人员规模控制在5人左右的或者系统模块化程度较高的团队，因为考虑到开发人员直接在同一个Develop分支进行开发，这样就可以避免上述说的合并冲突的问题； 

3、针对规模较大（5人以上）的团队，以具体的功能模块为一个独立Feature分支，进行开发；但是集成测试不是固定某一个时间等到所有同事都完成开发才做，还是会分批一起合并到Develop分支；在这个时候，会进行代码审查，具体的代码审查目前因团队而异，具体有通过团队leader负责的，有结对编程交叉审查实现的（都是通过Merge Request的形式，具体的Merge Request的用法可以参考我之前的另外一篇文章：GitLab的权限管理及Merge Request）。

【 SIT、UAT阶段】

4、开发人员将Develop 分支同步至Release分支，通过Jenkins的进行进行构建部署，给到SIT进行集成测试验证和BUG重测。

【 测试完成，发布生产 】

5、开发人员基于Release分支提交代码审查，由leader最后负责审核（Merge Request），审核通过后由leader合并至Master分支并打版本标签。

2、紧急版本流程

6/7、从Master 分支克隆Hotfix分支，开发人员进行代码修复、测试并投产验证后再合并至Master分支和Develop分支。

 

3、编译包版本管理

 除了源代码外， 版本译包的版本流转（这里叫版本管理） 

1、【 测试准入 及编译部署】步骤（1）-（6）

• 开发人员提交代码至Gitlab 的Release分支；
• 开发人员根据提测内容准备准入文档给到SIT人员审核，如提测单、详细设计文档、单元测试报告等；
• SIT人员审核开发提交材料是否符合准入条件；
• 如果通过，SIT人员通过触发相应的Jenkins任务，进行手工触发构建任务并自动生成测试版本标识，根据测试类型发布至相应的SIT环境。（具体的Jenkins搭建及集成Gitlab请参考我的另外一篇文章：Jenkins任务基于Tag进行构建）

2、【 SIT测试】步骤（7）

• SIT人员在SIT测试环境进行测试。

3、【 UAT测试】步骤（8）-（9）

• 正常情况，SIT完成后由SIT人员使用Jenkins基于把发布至UAT环境，UAT人员安排UAT测试；
• 部分情况，在SIT完成冒烟测试通过后，由SIT人员使用Jenkins把程序包发布至UAT环境，UAT人员安排UAT测试。

 4、【 回归、上线封版】步骤（10）-（11）

• 待UAT完成后，SIT人员负责进行最后一轮的回归测试；
• 测试通过后，SIT人员通知配置管理岗对上线系统进行打标签封版，SIT人员负责计算程序包MD5值并上传至专门SVN；
• 后面当内部的上线投产流程（通常是嵌入在公司的OA系统上）走完后，由运维负责通过SVN获取该程序包并根据投产手册进行部署投产。

这里有个地方需要说明：

从SIT到UAT是否需要重新构建？这个要看具体情况，具体原因如下： 

1、如果你的war包或者jar包已经接入类似阿波罗这样的配置中心的话，重新构建基本可以忽略。 只需要接入类似Artifactory或者Nexus这样的制品库就可以，只需要在启动的是否动态传入配置中心的参数即可；

2、如果 你的war包或者jar包的JAVA代码是使用profile进行环境区分，这样重新构建也基本可以忽略，只需要像第1点一样通过启动时动态 传入不同环境的profile参数即可，除非你这次投产内容里面是需要修改配置文件，且修改内容刚好是新增对接一个新系统（生产IP在测试阶段是未知的），这个只要你是老司机一定懂的，这里就看穿不说穿。 

 3、如果你的工程是很久的，可能是以前的SSH那个年代的，估计连spring profile你都没法用的话，估计就只能乖乖的重新构建。当然只要代码一致、maven文件一致，基本重新构建出来的一般也不会有什么问题的。

4、后话

关于制品库管理，暂时团队还没用，目前自己正在调研中，之前试用过Nexus但是界面什么的不太友好，最近在搭建Artifactory玩玩，看对团队有没有用，具体为什么需要制品库的话，我这里有个意见（具体参考我的另一篇：为什么我们需要制品管理？），当然不一定全面，权当 个人理解。