文章目录
前言
通常,在项目管理过程中,我们会对代码管控进行分类,比如分支、主干、基线等等。
但是,有些项目,它需求来来回回反复变更(就好比女盆友的脸,说变就变),发包日期无法自主把控(犹如女盆友的大姨妈,时而提前,时而延后,让人终日不能心安)。简单的主干、分支管理根本无法解决那么多突发情况。(有时恨不得一行代码一个分支去干!夸张了哈)
说点儿题外话: 在目前的公司呢,也呆了有快六年时间了,发现来到这家公司后,博客很少更新了。开始时是因为确实有很多新东西要学,很多业务知识要补习,很多行业知识要了解。慢慢的陷入了更多的琐事、杂事中。回过头来看,这几年在项目中应用了不少技术,但都没有深入沉淀下来,日常中一直在处理类似管理或设计上的事情。虽然我一直认为技术并不是一个研发人员的最重要技能,但一直深陷到琐碎的事务中,长期如此下去,对身心都不会太好。所以,上周我离开了奋战多年的公司,希望给自己些时间休息下,思考下未来的道路,顺便这几年的一些技术总结整理下,与大家共勉!
言归正传!下面是我在日常的项目代码管控中的一些思考与总结:
提示:以下是本篇文章正文内容,下面案例可供参考
一、研发
研发-测试-发包,这是一个软件功能从研发到上线的基本流程,在流程中的每个环节都有相应的关键点。下面对每个环节进行说明:
(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反馈后,会根据描述信息和操作步骤进行复现,或是根据反馈的信息,进行分析定位原因。之后对问题进行修复。并提交给测试人员进行复测。
(3)回归测试
回归测试一般是对一轮问题修复后,再次进行各个功能的复测。分为全面回归、选择性回归等等。有些公司可能还会用一些专业的自动化测试工具来降本增效。但归根结底,其实是对一轮bug修复后的重新验证,避免在修改代码时的相互影响。
三、发包
发包环节,分为两类:调试包和正式包。
调试包,一般由开发人员直接打包发布;正式包则必须由测试人员通过svn最新代码进行打包。
(包含测试环节,也是由测试人员打包,而非开发人员打包)
这里说明下,为什么正式包一定要由测试人员通过svn最新代码打包。
(1)可以避免开发人员因未提交代码导致的代码丢失风险;
(2)在正式包出现问题时,可以完全信任svn的代码,并根据提交记录拉取历史版本进行排查分析;
(1)自动化打包
测试人员并不一定需要了解程序的编译、运行环境等,可以通过各种打包编译脚本实现测试人员对程序的一键打包。(但需要注意的是,打包的代码,必须是svn服务器上的最新代码)
(2)打基线
当测试通过后,发包前,需要对当前测试的代码打基线,将当前程序代码复制备份到基线域做记录。以备后续排查问题时,可以随时拉取基线域代码进行分析定位。
(3)发版记录
每次发版的新增功能、修复bug、程序包、程序版本号、相关配套集成环境,都需要进行记录,以备后续进行查看定位。
总结
研发、测试、发包,虽然每个环节都有特定的人去执行,但项目中的成员会参与到每个环节中,对与项目管理中存在的问题,应该勇于提出自己的想法和建议,不断的改进每个环节。项目管理流畅了,每个人的工作才不会受到太多的干扰和影响。