软件版本管理制度

 版本管理是软件研发管理中比较容易忽视的一环,这当然是比较好理解的,因为版本管理毕竟和具体业务关系不大。其实,版本管理是很多更高级管理制度的基础,如果版本管理做得糟糕,类似代码审查一类的工作就很难高效方便的执行。

 

1 工具软件:SVN 和 Beyondcompare

         SVN是代码备份软件,Beyond compare 是代码对比软件

 

2 版本日志

         我们要求,每个项目都应当有自己独立的版本日志文件,小的项目或者模块版本日志可以 TXT格式,大的可以用 excel 来保存。

         版本日志顾名思义,就是记录项目版本演进的历史。它应当包含的内容有:序号、版本号、提交时间、作者、新增功能、修复bug列表和依赖模块信息。

         版本日志存放的目录一般是项目根目录的 ./doc 子目录,直接存放到项目根目录也很好。

         序号:每提交一次,序号加一。

         版本号:要求每次提交都采用唯一的版本号标示。版本号一般由数字加字母组成,如 V 1.05a 这个版本号,“1.05 ”描述的是软件功能集合,也就是说,V 1.05b、V 1.05c 的功能和 V 1.05a 完全一致,a、b、c 代表软件修复的bug 在减少。

         提交时间:版本提交SVN的日期。

         作者:提交人。

         新增功能:软件新增加的功能列表,只要软件功能增加,则版本号的数字也应当增加,若某版本没有新增功能,则版本号数字不应当变更。新增功能的描述详尽程度以产品经理或者测试功能师能理解为准,太详细了也没必要,过于简单或者有歧义也不行。

         修复bug列表:如果修复的bug 是测试部门报告的bug,则用 bug编号记录。如果是研发自己发现的 bug,则应当简要描述bug 现象,方便测试工程师验证。

         依赖模块信息:稍微大一点的项目,必然会依赖于大量的独立模块,这些模块可能是第三方开源模块,也可能是公司其他部门或者团队提供的模块,当然,也可以是自己研发的通用功能模块。这些模块名字、版本号必须在版本日志中描述,尤其是这些模块的变更信息,应当明确的进行描述。

         版本日志的注意事项:我们明确的规定,如果既没有新增功能,也没有修复bug,则不允许进行代码提交。在很多团队的研发实践中,常常把 SVN 当做日常研发的代码备份工具,代码稍微写了一点,就马上进行提交,比如在开发某一个功能时需要3天时间,有些工程师会有每天下班提交成果到 SVN 的习惯,这种习惯不能说不好,但是我个人感觉不是最好,我相信过多的冗余信息会把真正有用的信息掩盖,所以,我建议的原则是只把真正有用的信息保存下来,同时要求,所有有用的信息都必须保存下来!对一个软件的开发工作而言,新增功能和修复bug 是我们编写代码的全部目的,因此,我们就只关注这两点,而过程则不在项目SVN中记录。

 

3 提交内容

         提交内容应当包括:版本日志、相关代码和资源文件等。

         提交的内容应当是完整的、可编译的。这句话的意思是,其他同事在一个新的机器(开发编译环境自己可以安装)上把代码从SVN上Check Out 下来后,可以顺利完成项目的编译。某些项目编译环境有一些特殊的需求,比如要打一些特殊的定制补丁等,对这样的项目,开发人员有义务在 SVN 的 ./doc 目录下进行详尽说明,并完整上传定制补丁在 ./patch 目录下。

         在公司有配置管理员的情况下,建议项目编译生成的 bin 文件(即项目成果,如 exe、DLL 或者 *.so 等)由配置管理员编译生成并提交。在没有配置管理员的情况,对重大项目,我们建议采取交叉编译提交的方式,即开发人员只负责提交自己的代码,然后相互编译其他同事的代码和上传别人的 bin文件。这种管理方式有时候可以提前避免很多非技术性纠纷。

         开发人员在提交代码前,必须对完成的功能和修复的bug 自己做一次冒烟测试,即冒烟测试原则上应当研发人员自己完成。

         对于代码编译过程中产生的一些中间文件,典型的如 *.obj、*.o、*.s 等文件,严禁提交到 SVN。很多工程师提交这些文件的原因主要是对 SVN 不熟。

         另外,需要着重指出的是,提交的代码,应当是和版本日志中描述的新增功能和修复bug 相关的。在实践中,有工程师在编程时会发现以前某些代码文件的版式不漂亮、代码注释太多等等,然后就随手做了一些修改;另外就是在提交代码时,某些正在进行中的功能开发代码也顺便做了提交。就我个人的建议,这不是好的做法,我们应当尽力避免。因为版本日志是版本管理的总纲,版本日志的核心又是新增功能和修复bug两项,这意味着我们提交的代码是围绕着这两个核心进行的。在SVN的提交日志上可以清楚看到每次提交的代码文件名,如果按照规定做的话,这些文件名应当是完整说明了版本日志中对应的功能和修复bug所需要新增或者修改的代码文件,在这里,我不希望出现冗余信息,理由前面说过。

 

4 提交时间

         我们建议采取以功能点和修复的bug为线索的提交方式,即完成一个功能或者修复一个bug 后就立即提交。

         先把提交版本和发布版本的概念做一个清晰定义。提交版本意即开发工程师完成若干功能或者修复若干bug 后,把代码上传到SVN服务器,而发布版本意即由配置管理员从SVN更新到最新代码,并进行编译和bin提交,然后把bin发布给测试部门。

         我们建议采取的是多次提交对应一次发布的原则,而很多研发团队事实上采取的是一次提交对应一次发布的原则,即在版本发布的截止时间点做一次匆忙的提交活动,这种方式是可能存在一些隐患的。

 

5 优势

         采用这样的版本管理方法,研发团队是可以获取很多好处,也可以在流程上预先排除一些隐患。当然,自卖自夸不是好习惯,所以这部分我只是简单的说几点,真正的益处,是要大家在实践中去体会的,当然,可能也还有缺点也不完善,这也需要大家在实践中去发现。

         有些工程师出于各种原因,可能没有完整提交代码,对这种现象,我们采取了增加配置管理员编制的方法来解决。

         有些团队一方面提交的代码和最终生成的bin 不一致,另一方面,SVN服务器上的bin 和测试的bin 又可能不一致,对这种现象,配置管理员的设置解决了前者,而通过开放SVN上 ./bin 和 ./doc 两个目录权限给测试部门可以解决后者。

         测试工程师对于发布的版本可以采取增量测试的方法进行测试,减少测试工程师系统测试的次数,这样可以极大的提高测试工程师的工作效率。所谓增量测试,指的是只测试和验证发布版本的新增功能和修复的bug。

         刚发布的版本很快就被测试打回,这个现象的原因很复杂,但是,通过研发人员自己完成冒烟测试可以极大缓解该现象。

         有利于培养研发工程师对待代码的严肃性,为代码规范等一系列规定创造一个比较好的环境。

         现在回归测试更方便和有效了。研发工程师通过回归测试的方式可以更容易的排查bug了。

         有些团队测试平时很空闲,一发布版本就很忙,甚至有可能要搞通宵。现在我们通过多次提交对应一次发布的方法来解决这个问题。测试平时就可以随着研发的进行先把提交的版本测试起来,极大的提高的测试的工作效率,使得测试工程师的工作量安排分布更加均匀。

         最大的好处是,使得团队内部互相 code review 成为可能。Code review 是在研发阶段消灭软件质量最好的方法,也是促进新手程序员成长的最高效方式。在严格的版本管理制度下,每个功能、每个bug 对应修改的代码在SVN上可以简明的看到,这极大的方便了资深工程师对新手代码的审查,同时,也极大的方便了新手程序员向资深工程师的学习。我一向的观点是,软件工程师把一个功能完成算不得什么,如果百分制的话,完成功能最多得30分,我们除了功能,还应当考虑稳定性、可靠性、可扩展性,还有注重代码的可读性和可维护性等等,这些东西新手程序员是很难全面兼顾的,这就需要资深工程师进行现场指导,结合新手工程师自己写的代码进行讲解,这是最快速的优秀程序员培养模式。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值