微信号:androidwalker

介绍:关注Android新技术、进阶开发

多团队协同开发经验

2015-11-07 18:12 Android高级开发

在规模比较大的团队里,一款App产品通常有好几个团队在一起协同开发。但是,开发分支只有一个,所以,每一个团队就需要不定期地将代码合并到同一个分支上。这样就涉及不少问题,我就在其中一个团队,那就让我谈谈,多分支开发遇到的那些坑,以及解决办法。


1 业务解耦

1.1 还未分团队之前,我们的业务是这样子的



1.2 分团队后,为了减少相互依赖,我们做了业务解耦和代码解耦。

为了做到上述情况,我们做了以下工作:

1)业务独立,去掉重叠的区域

2)形成新的模块——公共模块,目的是将各个业务的重叠区域挪到公共的地方


2 多分支协同开发

2.1 分团队之前,我们是以个体的方式提交代码,如下


可以看出,总共只有一个开发分支主干,所有人都不断地往一个分支提交代码。每一个版本(如图1.1版本)需求开发完成后,打出一个新的分支来,作为发布分支,然后下一个版本(如图1.2版本)继续开发。

如果1.1发布app后,上线验证,发现问题,则只能在1.1的稳定发布分支上修改。


2.2 分团队之后,为了达到多团队并行开发,我们新的协作方式如下:


从上图可以看出,每一个团队都多了一个分支,在每一个版本迭代开发时,所有需求功能都开发完成稳定后,才能合流到主干。另一个团队ft需要及时rebase主干上最新的修改。这样就可以确保两个团队可以并行开发。


3 灰度版本号

凡是用户上规模的产品,在发布正式版之前,总是会先发布一个小范围的灰度版本。目的是用来提前暴露新版本存在的问题,在发新版本前得以修正。

灰度版本,这是一个全新的规则,每一个app有一个版本号,灰度版本的版本号是否需要更高的版本号?

答案是否定的。因为放一个更高的版本,则会让线上的版本得到全部升级,而这并不是我们想要的。

那更低版本呢?Android系统也是不允许的。

所以,唯一的办法是版本号相同。thank godness!android是允许同版本覆盖的。这样,线上将有多个版本号一致的包,所以,我们自己定义了子版本号的概念,用来区分不同的包。

android系统识别我们的版本号为versioncode,但我们自己的app识别到的版本号versioncode+subcode。这样,我们便可以清晰地分辨同一个版本下的各个灰度包(正式包也有自己的subcode)。

比如前三位为versioncode,后三位为subcode,如下图所示




4 业务交叉

每一个团队拥有整个工程代码,但工程是经过解耦的,自己只能需要自己的业务模块,如果涉及其他团队的业务时,可以要求其他团队进行修改。但理想和现实总是存在差距,其他团队修改完之后,无法立马合流到主干(因为有一套严格的质量控制环节)。所以,另一个办法则是自己修改,并将修改的地方周知其他团队,同时,发code review出来,让其他团队相关负责人进行代码评审。


5 Code Review

为了确保代码质量,我们在需求开发完成后,通常需要发一个code Review出来,将自己的修改代码拿出来,其他组内成员作为评审,对代码质量进行把关。

业界比较有名的code review,比如酷派,据说,每周五下午下班前,有一个小时的代码review环节,一对一review,这样也能起到很好的代码质量把控。


6 版本Owner

这个是在分团队后,新增的一个角色。版本owner在版本控制上提到非常总要的角色,负责rebase代码、合流以及分支的稳定状况(比如crash率等)。除此之外,还需要与PM、合流审批者等打交道,具体如下:

1)定期rebase主干代码,同步其他团队的修改,确保自己团队的分支是最新的代码;

2)

3)与测试沟通,提供测试包

4)关注灰度包质量(crash问题等)、效果

5)申请合流权限,并合流


(觉得不错的话,可以打赏我)






 
Android高级开发 更多文章 Android Studio 入门技巧之<基础篇> Android Studio 之<进阶篇:实用快捷键> Android Studio 之<进阶篇:IDE设置> 2015年度腾讯MIG内部技术峰会 Android进程间通信:Messenger
猜您喜欢 神州数码TDMP平台成功签约 德阳银行&攀枝花商行 安卓单元测试(十一):异步代码怎么测试 阿里月饼事件中的一个有趣现象 Android自定义Lint实践 当今世界最NB的8位科研学术界大数据科学家