在我接触过的持续集成推广案例以及网上所推崇的持续集成中，持续集成最重要的概念即是：尽早集成代码，禁止私有分支；*
在持续集成的理论中，什么是私有分支？
比如传统的开发模式中，项目A、项目B同时开发功能模块as，那么常规的做法是为项目A、B拉两条分支，大家各自在自己的分支中开发、提测、发布，当其中的某个分支发布后，比如A先发布，那么在A发布之后将分支A的代码合并到分支B中，之后B再发布；
那么在持续集成中，以上传统模式中的分支A、分支B即是私有分支；
传统的模式中，有一个开发任务C，开发人员张三可能需要独自开发一个星期才能交付或者跟其他人的代码集成，传统的做法：张三会拉一条私有分支，当一个星期开发完成后，再做代码合并；
在持续集成中，这种情况也是私有分支；
在持续集成中，废弃了私有分支后，要求所有人将所有的代码都提交到统一的一条分支中，通常我们取主干，即所有人将所有代码都提交到主干中，我们还是以上面的两种案例来说：即项目A、项目B、项目C都要将代码提交到主干上；但是代码虽然在一起，却不能影响项目A的正常发布，这就意味着，项目A在发布的时候，其发布的代码中包括项目B、项目C的代码，并且项目B、C有可能还有bug，甚至有可能还没开发完成；
说实话，当我第一次听说这种开发模式的时候，我特别诧异，觉得有些不可思议，但幸好，我之前接触的推广持续集成的项目是C语言的，这个项目在引入这种模式的时候，引入了编译开关，即当我们在代码中加入一段新功能的时候，我们为每个新功能引入编译开关，即项目A、B、C的代码虽然都在主干中，但是每个功能都有对应的开关，当A发布的时候，功能B、C的开发是关着的，即虽然B、C的代码也被发布了，但是功能不生效，所以不会影响A的正常发布；6 w
这种模式是引入了编译开关，但其实这个编译开关是一个幌子，表面上代码是集成在一起了，但由于B、C的开关是关着的，功能不生效，其实还是没有集成，还是会隐藏一些潜在的bug；
那么如果我们想要做到真正意义上的尽早集成代码，废弃私有分支，应该做些什么，怎么做？
1、需求拆分
2、开发任务拆分
3、本地构建7
4、全面的自动化功能测试、性能测试
这4点种，第四点很容易理解，前面三点呢，为什么要做前面三步：需求拆分、开发任务拆分、本地构建 ，根本原因还是：因为我们要及早集成代码，所以我们要保证，每个人的代码至少每天下班前都要提交到主干中，这就意味中，每个人在提交代码前，必须保证他的代码质量是ok的，不能因为他的代码提交影响了其他人；(
下面再分开说前面三步：
1、需求拆分：
这个也很好理解，原来的需求可能需要开发一个月，我们要进行需求拆分，将一个大需求拆分成n多个小需求，然后开发人员再分步实现，分步验证，以降低风险；
2、开发任务拆分：
说实话，这个工作我没经历过，我只是大致知道概念：比如一个任务原本要开发一周，在写代码时，先写框架，然后再按照自己的任务分解逐个写实现，目标就是保证我每天都能将代码check in到主干中，并且保证程序是可run的，并且不会block其他人；6
3、本地构建：
这个的目的还是为了保证代码质量，一般在每个人的代码提交前，至少要做三件事：ut、codereview、本地构建，本地构建在不影响效率的情况下，应该至少保证准入级别的case可以通过；
这四个任务中，任务1、3、4我觉得都ok，关于2，我曾经咨询过一些敏捷经验很丰富的人：怎样才能推行这项工作，他们的说法是：
我们需要招一个开发能力很强、敏捷开发经验很强的人来推行这项工作，由这个人去指导开发人员，然后1传2，2传4、4传8、……；
我们先暂且不说这样的人有多难找，其次这种传法，难道不会在传递的过程中变形？
说了这么多，我就是想说，禁止私有分支，第一、风险太大；第二、为了实现这个目标，我们前面要经历很多很多； E
所以如果我去推行持续集成，我会首先去推行1、3、4，在这三个都推行很好的情况下，特别是如果我们的自动化case覆盖率能够达到99%的情况下，我才敢去推行：禁止私有分支
上一篇：敏捷项目管理实战之质量管理
下一篇：为何敏捷将成为主流 |
[复制链接]
service@step365.com
0571-87357690
狗仔卡
发表于 2012-4-17 17:09:16
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
转播
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡