QQ截图20160624141520

项目开发中多人协作的工作实践

在互联网公司中,一个产品的开发是需要多个研发共同实现不同的功能的,并将自己的代码提交到代码库中。不管是选择Svn还是Git,代码库应该是所有互联网公司的标配了吧。但是,多人如何协作是一个管理问题同时也是一个技术问题。

那么,如何高效的协作是一个大问题,并不是用了代码库就能解决多人协作的问题。以SVN为例,以下是几个比较典型的问题:

问题一、所有人都将代码提交到Trunk中。

如果研发维护的代码和用户访问的代码都使用同一个目录——Trunk。那么,研发在开发新功能或调试的时候,很容易影响到正常的用户访问。因此,虽然使用了代码管理工具,但是将用户访问的代码和研发开发的代码放在一起,没有有效的隔离是不行的。

问题二、代码隔离的不彻底,不会使用分支开发。

如问题一,虽然很多开发团队会将代码进行隔离,但是隔离的不彻底也会造成比较严重的问题。我们知道,在产品开发的时候分为:1.正常的版本迭代;2.紧急的BUG修复;3.紧急的业务类需求上线(一般是小需求)这么几种常见情况。那么它们会带来什么问题呢,如图:

dev

A(研发)提测版本10给测试人员(一般开发团队都会有测试人员),在测试人员测试过程中,B(研发)和C(研发)分别将代码提交到dev中,这时测试人员经过测试发现代码有问题,反馈不通过,这时A再提交代码的时候已经是包含了B和C的代码。测试人员继续测试反馈通过了,而A负责的这个业务又是一个非常紧急的市场类业务需求,那么代码怎么上线?如果将代码上线势必会包含B和C的代码,而B和C的代码并没有提测,而且因为他们是正常的产品版本迭代正在开发中,不能上线,只有等到B和C的代码开发完并提测通过后一起上线,这个时间是需求方无法忍受的。

问题三、测试人员平行测试的问题

根据业务的不通,可能需要多个测试人员(比如四个)对同一个代码库版本进行测试,那么如果在一个Dev中提取测试样本,就很难保证提测代码的连续性以及其他不相关的研发提交代码对当前测试的影响。

由此可见,并不是说用了代码管理工具就能解决多人协作的问题,协作的矛盾还是无法避免。那么,如何规划代码协作流程呢?看看江边望海下面的一张图。

liucheng

分为三层:开发层测试层发布层

开发层:

Dev开发母本:目前,是研发团队在开发需求时拉分支的基础,是非常稳定的,非必须不得直接在Dev下进行开发;

Dev_vX.X.X:产品正常的版本迭代计划,有明确的开发周期、测试和上线周期,时间线相对会非常长,对上线时间要求不那么迫切;

Dev_patch:临时的紧急BUG处理和小需求实现,时间线非常短,对上线时间要求非常迫切;

研发人员在接到需求或BUG后根据大小从Dev开发母本中拉出分支进行开发。这个分支只解决当前需求的问题,开发完成后提交给测试。

测试层:

测试人员在接到提测请求后,将代码提交到测试环境并通过软链接的方式指向提测的开发分支对其进行测试,测试不通过打回,研发人员继续在分支上开发后再提交测试直到通过为止。

通过后,研发可以将分支的代码与Dev母本进行合并,如果有冲突由这个分支的开发人员来解决。合并完成后告知测试人员进行发布。

发布层:

发布的操作是由测试人员控制的,发布的代码依赖于Dev母本的代码,研发人员合并完成后告知测试人员发布即可。测试人员可能会在代码发布前进行一次主要流程的回归测试以保证Dev开发母本代码的正确性(视情况而定)。

研发不接触Trunk中的代码,Dev是Trunk的代码源,Trunk中的代码是发布到生产环境提供给用户访问的。

这个模型很好的解决了多人协作所造成的刚才遇到的业务问题,保证了每个通道都是并行的处理和测试。而且也解决了多个测试人员测试同一个代码库中的不同版本的问题。

svnflow

《项目开发中多人协作的工作实践》有1个想法

发表评论

电子邮件地址不会被公开。 必填项已用*标注