关于研发过程中的代码版本控制的思考

文章目录

前言
一、研发
- （1）分支管理
- （2）代码提交规范
- （3）版本号控制
二、测试
- （1）研发自测与用例评审
- - 研发自测
  - 测试人员测试
- （2）BUG反馈与复测
- （3）回归测试
三、发包
- （1）自动化打包
- （2）打基线
- （3）发版记录
总结

前言

通常，在项目管理过程中，我们会对代码管控进行分类，比如分支、主干、基线等等。
但是，有些项目，它需求来来回回反复变更（就好比女盆友的脸，说变就变），发包日期无法自主把控（犹如女盆友的大姨妈，时而提前，时而延后，让人终日不能心安）。简单的主干、分支管理根本无法解决那么多突发情况。（有时恨不得一行代码一个分支去干！夸张了哈）
在这里插入图片描述

说点儿题外话：在目前的公司呢，也呆了有快六年时间了，发现来到这家公司后，博客很少更新了。开始时是因为确实有很多新东西要学，很多业务知识要补习，很多行业知识要了解。慢慢的陷入了更多的琐事、杂事中。回过头来看，这几年在项目中应用了不少技术，但都没有深入沉淀下来，日常中一直在处理类似管理或设计上的事情。虽然我一直认为技术并不是一个研发人员的最重要技能，但一直深陷到琐碎的事务中，长期如此下去，对身心都不会太好。所以，上周我离开了奋战多年的公司，希望给自己些时间休息下，思考下未来的道路，顺便这几年的一些技术总结整理下，与大家共勉！

言归正传！下面是我在日常的项目代码管控中的一些思考与总结：

提示：以下是本篇文章正文内容，下面案例可供参考

一、研发

研发-测试-发包，这是一个软件功能从研发到上线的基本流程，在流程中的每个环节都有相应的关键点。下面对每个环节进行说明：
在这里插入图片描述

（1）分支管理

即代码域的划分。一般情况下，是主干、分支、基线，三个大域。

主干（trunk）： 主要用于提测、打包、发包和打基线；只进行提测前的分支合并与提测期间的bug修复。

也有人认为主干不能进行直接开发。我个人认为，应该视情况而定：比如就是一个小的bug修复，可以不用拉分支，直接在主干改；如果是复杂bug问题，修改内容较多，或是新需求，这些都需要创建分支进行开发，然后发版提测前把分支合并到主干。凡事不能因循守旧，项目管理不是一成不变的按既定规则执行，很多情况下，起始是需要技术负责人根据实际情况灵活变通。

分支（branches）： 分支有几个类型：新功能研发分支、已发版问题修复分支；

新功能研发：是基于trunk的代码进行创建，开发完成后，达到发版时机时，合并到主干后提测；

已发版问题修复：是基于tags或稳定定版的代码版本进行创建（每次发版后，必须对代码打基线tags），哪个版本有问题，就根据哪个版本的基线域创建分支，测试通过后，再将此分支合并到主干。（如果需要立即发包，就直接将该分支提测，如果后续修复，则此分支现场验证通过后，可合并主干，随后续功能一同提测发包）

基线（tags）： 只用于发正式版时的代码备份。

一般由测试人员在版本发布前，将代码备份

在这里插入图片描述
以上是对三个代码域的介绍，下面是实际项目开发过程中的一些注意事项的总结：

创建分支时，最好注明该分支是基于哪个代码创建的，用于做什么功能，方便后续代码合并；
代码合并时，可通过将合并的路径及合并的svn版本区间一并写入到提交记录中，方便后续排查问题；
分支合并后，技术负责人需要将分支的svn进行锁定，避免其他人员再次修改提交；
一定要做好代码提交时的记录编写，说明每次提交的内容及关键代码类；

（2）代码提交规范

代码提交规范
即指svn或其他版本控制工具，严格限制代码提交的格式。需要按照规范格式描述提交信息的具体内容。（具体如何实现，可能和SVN钩子强制提交日志等相关，各位自行百度或脑补吧，这块可能涉及到QA、质管部门的一些自动化工作）
格式规范描述内容比如：修改内容、新增功能或需求描述，是否自测等等。
在这里插入图片描述
代码格式规范
为了避免过多的代码冲突，规范代码的格式是必要的。
这一点，各种开发工具都有其自动格式化的插件或工具，比如AndroidStudio在进行svn提交时，就能自动进行代码格式化。

对于已经在运的项目，之前如果没有进行格式化，也建议统一对项目进行一次格式化处理，保障代码既整洁又便于管理。
方法如下：对项目进行格式化（快捷键Ctrl+alt+L）
在这里插入图片描述

（3）版本号控制

每个公司对版本号的规定各不相同，参照之前网上流行的版本控制，主要需要注意几点：

版本号的含义，如1.1.1，每段标明不同的含义，比如最前位1是大版本号，第二位1是新功能版本号，第三位1是bug修复版本号；
版本号的区分，如beat-1.1.1就是内测版，debug-1.1.1就是调试版；per-1.1.1就是个性化版本。
通过编译时间打包到程序中，避免人为修改版本号时的遗漏问题；

注：虽然版本号可以让我们区分程序包的版本，但毕竟修改版本号是人为改动的行为，难免会出错（尤其是调试包发包时）。所以为了避免人为因素的干扰，我通常会在程序中定义一个打包编译时间。在日志记录或隐藏按钮处可以查看这个打包编译时间。因为正式包只会编译打包一次，时间就固定下来了，我们去核对程序是否是我们某个时间发布出去的包时，更准确的是核对打包编译时间。
比如：安卓的gradle中能够自定义buildConfigField，webpack的DefinePlugin插件可以定义时间变量等等。

如下图：BUILD_TIME即为编译打包的时间，编译一次，就固定写入到程序包中，后续进行程序对比时，就可以根据编译时间判断程序是否是正式发包的程序。

关于webpack的定义打包时间，可以参考往期博客：通过webpack配置【程序打包时间】

二、测试

（1）研发自测与用例评审

测试分为研发人员自测和专有测试人员测试

研发自测

研发人员开发完一个功能后，自测是一个必要的流程。不进行自测就直接提交给测试人员测试，是一种不负责任的表现（和渣男渣女的烂桃花行为无异）。

无论开发的是app程序、中间件、插件或是组件，都需要进行自测。对于中间件、插件等一类需要依赖于其他程序集成调用的组件开发，需要有相对应的测试程序。不求完全复现集成调用的整个流程，至少也要尽可能的覆盖到组件的所有功能调用接口，否则，后续出现问题时，要依赖于其他程序进行测试，这是一个很麻烦的问题。

测试人员测试

各个公司的测试人员配比可能不尽相同，但有一个专业的测试人员是一个项目保障质量的最后关卡。
其中，测试用例编写，是此流程中的一个关键环节，测试用例是否尽可能的覆盖了所有场景，是否能指导其他测试人员开展测试工作等等。

测试人员一般会针对研发提测的功能进行梳理，前期进行系统的冒烟测试，随机测试，然后根据功能、需求以及测试程序，进行测试用例编写。项目组评审完测试用例后，测试人员会根据测试用例展开更细致的功能测试。（测试用例编写和评审没有严格的先后顺序，有时也会依紧急程度而定，但用例评审时，主要研发负责人肯定会参与）

（2）BUG反馈与复测

BUG问题反馈是测试人员与开发人员的沟通环节。通常是需要测试人员对问题现象、操作流程、期待结果等信息进行记录，并转交给开发人员进行排查、定位。一般会使用类似禅道的平台工具进行流程化管理bug问题。
开发人员接收到bug反馈后，会根据描述信息和操作步骤进行复现，或是根据反馈的信息，进行分析定位原因。之后对问题进行修复。并提交给测试人员进行复测。