持续集成与版本号

2014 年 02 月 28 日

持续集成是我所见过的最有效的改善软件质量的方法。不过往往落后的软件企业都意识不到这一点,比如我所呆过的几家公司😂

版本号是联系QA和RD的纽带。我一直觉得版本号应该是三位一体的,也就是说有三个版本号必须是一一对应的。三个版本号包括:

  • 文件名版本号:也就是提供出来的生成档,必须有个版本号。比如app1.0.apk。如果不能或者不愿意在生成档上直接加版本号的话,可以考虑打个包,在注释或者是包名上加版本号。
  • 运行期版本号:也就是程序/应用/系统在运行期显示的版本号。这个版本号通常是写在代码里,有些公司会将这个版本号更新人工提交到SCM,我认为这是极端错误的做法,应该以程序自动生成为宜。
  • 源代码版本号:也就是对应的SCM系统中的版本号。源代码版本号往往QA不在意,但对于RD其实是一个极大的帮助。比如一个问题,RD提交了就认为改了,但QA验证时没有,这时就可以根据QA手上的运行期版本号和RD提交的源代码版本号对照了。如果像git之类的版本号,可以使用时间戳为版本号。

多说一句,理论上,源码服务器上每一个提交都应该能正常的编译出一个版本;至少绝大多数情况下应该可以正常的编译出版本。如果这点都做不到,只能说明程序员实在太差了。

持续集成与版本号的结合,在我看来,有一个比较通用的办法。依序是:

  1. 订立规则。比如我很喜欢的方法是主版本号+副版本号+svn版本号。类似3.14.15926。其中3和14分别是主版本号和副版本号,写死在代码里。15926是svn版本号,每次编译时动态取出。
  2. 编译脚本修改。持续集成的关键就在于通过编译脚本,从源代码一步生成编译档。因此我通常编译脚本的做法是:
  • 脚本先下载/更新源码到本地副本
  • 脚本获得源代码版本号,然后通过环境变量或是参数来将版本号设置进去。
  • 脚本复制一份代码到编译目录,在那里准备编译。
  • 脚本修改编译目录中的源码,将源代码版本号根据之前订立的规则,修改到源文件里面去。比如AndroidManifest.xml之类。
  • 脚本真正执行编译,得到生成档
  • 脚本对生成档改名,放到常用的目录去。

以上方法,用ant比较容易,shell脚本也勉强可以,maven没试过,但应该也是通用的。

Top