泪崩！百度91持续集成总结之一

记一次不成功的持续集成经验，防止后人踩坑。...

测试百晓生——测试圈懂的最多的人，跟着百晓生一起学测试，你定会有收获。我就在你的口袋，你——有问题难得倒我吗？

本

主要的内容是源自在百度91接近一年关于持续集成和敏捷的工程实践中的经验总结和实践的一些分享,也许并不能引起大多数人的共鸣,但还是希望能起到一些抛砖引玉的作用,引发读者对工程实践的更多思考与讨论。由于篇幅限制，文章会做连载，喜欢的朋友可以关注一下。其实CI (Continue Intergation)并不是什么新鲜的概念, 早在2007年,TW的首席科学家Martin Flower先生已经在他的blog中首次提到了CI的概念。

以下是MF先生对于持续集成的基本定义:

持续集成 是一种软件开发实践。在持续集成中，团队成员频繁集成他们的工作成果，一般每人每天至少集成一次，也可以多次。每次集成会经过自动构建（包括自动测试）的 检验，以尽快发现集成错误。许多团队发现这种方法可以显著减少集成引起的问题，并可以加快团队合作软件开发的速度。

简而言之也就是团队频繁的提交代码，频繁的进行集成， 从流程上来说就是当开发团队提交代码之后，会自动化构建，自动化检验，自动化测试，自动化反馈，当开发工程师提交代码之后，只需要离开工位泡一杯咖啡再回到工位，那么这次commit的代码是否引起了Regression Bug，就能马上得知。

听起来是不是很美好?真是酷毙了，这一切都是完全自动的，不需要额外的人工干预。也许会有较为资深和懂行的测试工程师想，这有何难，不就是搭建个jenkinsCC之类的开源引擎，然后用shellat来调用ant， maven， gradle之类的构建工具，对源码进行编译，部署，接着调用写好的各种单元测试，集成测试，自动化验收测试，最后用测试框架提供出来的一些ITest对象，或者TestResult对象来统计结果， 通过邮件发送给团队所有人就好了。

嗯，从技术栈上面来说，确实是这样的，的确要做到这些不难。 但是做到这些了，并不代表团队的持续集成的工程实践就能真正帮助到整个研发体系和流程。要想做好持续集成这项实践， 并不是测试团队发力就好了，整个工程团队也应该从工程实践上做相应的调整，才能真正让CI起到应有的效果。

笔者所接触到的大多数软件企业，都在喊着我们在做”迭代开发”， 但从最后的结果上看基本是打着迭代的幌子做”增量开发”。 即团队一定要在所有的功能都结束之后，才能交付应用，整个过程犹如下图A1:

A1：可以看出， 一定要所有的工程师把自己的模块都做完之后，才能看到蒙娜丽莎的全图，如果目前的团队采用这种方式，持续集成就无从谈起，因为即使代码集成了，也无法工作，更无法进行后续的流程。

(笔者目前所在的企业就是典型喊着要做”迭代开发”，却最终做成了”增量开发”的案例。在半年前一个很重要的市场版本中，有一个底层模块在提测前的集成出现问题，导致delay了两天，有意思的事情是，整个开发团队block了两天，直到该模块的问题修复，所有人的工作才得以继续。)

但实际上，迭代的过程应该像是A2:

A2：团队可以先从最重要的内容开始开发起，用最快的速度交付一个可用的版本，确认结果是PM用户所需要的，然后不断的渲染，上色，直到完成整个应用的交付，只有这样，才可以尽早，尽快的集成， 之后才有可能努力做到每天集成， 随时集成。

团队应该采用的是真正的”迭代开发”的方式， CI才能更好的在工程实践中发挥作用。采用迭代开发的方式会迫使团队尽早开始考虑代码集成以及不同模块之间的交互方式。 把软件工程中风险较大的集成过程提前，避免出现笔者上文中的案例。

当研发团队开始使用迭代开发了之后， 在工作任务的划分和分配上也应该做相应的调整，至少做到工作内容的分配上能做到每天都完成，并且每天都能交付，否则CI的实践也很难可以进行下去。

同时，在设计程序架构的初期，也应该为此做好准备和设计，例如组件和组件之间最好是松耦合，组件和组件之间的交互可以被很容易mock，即便是有依赖关系的组件，在另一组件的代码被提交之前，也可以使用mock来模拟状态，完成单元测试，确保自己本身能够正常工作。在91的实践中，架构的梳理做的不到位，有很多强耦合，业务也极难剥离。可庆幸的是应用很小，可以做到每天交付。

在任务的拆分上， 笔者的团队使用了”扑克牌估算法”， 基于任务的难度和工作量进行估算，在经历了几次拍脑袋的估算之后，大致得出了一个可以量化的产能，即团队每周只能完成50个点数的工作量，超出了50个点数，要么降低最终的质量，要么只能delay交付的时间。

笔者也推荐对项目的工作量进行类似的定量的估算，估算的结果并不重要，重要的是在过程中会对目前的工作难度，范围有更多思考，同时在进行几轮估算过后，也可以得出一个比较粗糙的团队工作产能的量化值。便于后续工作的指导。增量开发跟迭代开发不是一个概念，请好好考虑自己的开发模型，不要为了持续集成而持续集成。持续集成不是用用CI工具就能做的。

上文只是普及了一些基本的概念，下期会讲到持续集成到底做了哪些东西包括收集、构建、测试，有兴趣的同学关注一下，这样就不会走丢啦。觉得讲的还不错就顺手转发一下吧，求你啦！

--------------------------

貌似好多同学不知道百晓生积分可以换道长和monkey亲笔签名的书哦。(づ￣ 3￣)づ公众号ID：ceshibaixiaosheng

软件测试圈子知道最多的人，不服来问。如果你有不懂的问题直接问我们，我们有的不仅仅是技术。

点击下方“阅读原文”领取500万福利！！！

↓↓↓

    关注 测试百晓生