源代码、编译包版本管理团队实践_代码版本管理实践sit uat pvt ...

2、源码版本管理

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

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

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

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

废话不多说，先上图。

1 、常规版本流程

【开发阶段】

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

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

3、针对规模较大（5人以上）的团队，以具体的功能模块为一个独立F eature分支，进行开发；但是集成测试不是固定某一个时间等到所有同事都完成开发才做，还是会分批一起合并到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文件一致，基本重新构建出来的一般也不会有什么问题的。

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

目录1、前言2、源码版本管理3、编译包版本管理4、后话1、前言随着所搭建的团队人数越来越多，开始形成一个个独立小团队的时候，协同开发的机制重要性就显得格外重要。刚好最近要针对这块版本管理向领导做个总结汇报，我这里就顺便分享一下我们团队的一个整体做法。2、源码版本管理整体上我们团队还是以Gitflow为主，再根据我们团队具体情况做一定程度的裁剪。首先这里复述一遍Git...

版本控制系统简史团队开发，协作开发使用版本控制，Team当中，有若干成员，比如说10人，DBHelper.cs、其他共用类库文件，还有自己文件，都可以能被别的成员会使用，查看、编辑、删除（这个操作很危险）。版本控制系统（VCS，Version Control System）可以划分为集中式和分布式两大类。集中式顾名思义，是用单一的服务器来集中管理保存项目的所有文件。项目团队的成员通过客户端连接到这台服务器，下载或提交文件。客户端一旦无法连接服务器，那么版本控制功能将无法使用（例如比较历史版

开发过程中需要导入很多第三方 jar 包，有的是开源的，有的需要我们自己封装一个。高版本 JDK 编译的jar 包不能在低版本的编译环境中运行，会报错。 1. 如何查看 jar 包编译时的 jdk 版本使用压缩软件直接打开 jar 包或者，解压需要查看的 jar 包，进入解压目录可以看到 “METE_INF”的文件夹，进入该文件夹，会看到 “MANIFEST.MF”文件，使用记事本类似工具打开，搜索“...

这是HOL4的Kananaskis发行版的分发目录。有关在线资源，请参见。以下是分发中可用内容的简短列表。 INSTALL * Installation instructions std.prelude * File loaded at the beginning of each HOL session bin/ * Executables doc/ * Some documentation, including release notes examples/ * Some examples help/ * Help support src/ * The system sources 主干分支（main）: 研发的分支从主干检出、经过测试（ UAT ）验收后必须要合并到main分支上，并且需要发布到 UAT 环境上再次验收，方可发布，此分支名称固定为main，每个业务线只存在一个。功能分支（feature）: 需求研发、功能迭代、缺陷修复、处于研发中的分支。此分支名称按版本规范命名，每个业务线允许多个存在。测试分支（ uat ）: 发布到测试环境的分支，任何研发修改，都需合并到此分支进行测试验证。此分支名称固定为 uat ，每个业务线只存在一个。团队目前在日常开发工作中都是在线下进行代码审查，但是这样的模式根本无法做到过程留痕。因此，需要使用GitLab的Merge Request或者Gerrit这样的工具进行过程管理。这里详述一下如何通过Merge Request进行线上的代码审查。