从iPhone 3.0.1更新看软件版本控管策略 (1)

如果有跟Apple购买iPhone Developer Program的网友早已知道 Apple在Release iPhone 3.0没多久, 就开放让Developer下载iPhone 3.1 beta SDK, 所以过不了多久, Apple等到iPhone 3.1 beta测试了差不多, 就会Release iPhone 3.1版. 但2009/8/1 Apple为了修正安全漏洞, 很快的推出iPhone 3.0.1版, 所以, 聪明的你可以看出, Apple iPhone开发团队一定维护了两个iPhone OS版本, 一个是iPhone 3.0 , 一个是iPhone 3.1 , 在iPhone 3.1 Final版还没稳定之前, 还可以Release iPhone 3.0的修正版就可以了. 这个道理看似简单, 但是还是会有网友会问, 为什么要这么麻烦?? iPhone OS 3.0 release后, 开发团队不就火力全开, 努力往iPhone OS 3.1前进, 而且iPhone OS 3.1已经到了beta 3, 应该差不多了可以release了, 为什么不赶快release 3.1 final版来解决这个安全漏洞, 一来节省RD的开发时间, 一来兼顾消费者的期待, 但是软件开发不如意十之八九. Apple会这么做, 原因可归纳如下:

iPhone 3.0从3月起, 开始从beta版开放测试, 期间已经经历大约4个月才release final版, 除了4个月的beta版公开测试,在beta版之前,Apple内部应该也测试了几个月, 以这样长时间的测试,iPhone 3.0新增的许多新的功能应该通过所有unit test/test case测试. iPhone 3.0算是一个stable的版本 ( 也许你不同意iPhone 3.0 == stable, 这我可以理解), 针对iPhone 3.0修正的安全漏洞的source code其相依性(dependency) 远比针对从iPhone 3.1开始新增/修改的code其相依性来的少很多, source code修改相依性少, 加上之前长期的测试
Apple SQA人员, 自然有把握可以在这么短的时间完成iPhone 3.0.1测试, 并release给使用者upgrade. 简而言之, 所以将iPhone 3.1 beta3 修改后release给使用者其风险远高于iPhone 3.0.1 我想Apple内部应该有更精确的测试数据.

这里我要稍微解释所谓的相依性(dependency) , 软件是由许多模块所组成, 如果你开发一个模块A, 刚好被模块B,模块C所使用, 这样你可以说模块B,C与模块A相依, 如果软件发生了一个Bug, 这个Bug刚好要去修改模块A, 那么很有可能模块A的Bug解决了, 却造成模块B与C的功能不正常, 所以在软件开发过程, 模块A,B,C都会开发许多的unit test, 这些unit test会在build过程中去执行, 以确保修改source code确造成其它相依的模块无法work.

所以有了这个iPhone 3.0.1的案例, 如果你的软件开发团队也面临类似的问题. 而且团队也在使用版本控制软件(SCM)例如,VSS,CVS,SubVersion,Git,Mercurial等等, 那么你会怎么做?

1. 善用版本控制软件(SCM)工具的tag功能, 在每一次的release都在做tag(标签), 这样才能完整的将stable release的source code checkout来做branch
2. 善用版本控制软件(SCM)工具的branch功能, 当软件要进行下一版的修改, 最好是在另一个branch中进行

以下两种SCM的Pattern模式, 都可以应付当下一版软件还没stable, 而要先修改stable版的bug且需要在短期内release的状况.