2ac8634945216dc5eb1c2cfc7e6c3a52
持续集成是什么?

一、前言

这几年我一直在坚持做一件事情,那就是持续集成。它给项目带来了许多好处,现在做项目已经离不开它了。我也时常与人交流持续集成,发现了解它的人非常明显地分成了两类。一类是非常了解它的人,了解到骨子里的那种;另一类则仅仅把它当成一个打包工具。 并且第一类的人也少得可怜,因此我觉得持续集成被轻视了。本专栏将会以理论到实践的形式讲述持续集成,希望大家都能享受到持续集成带来的好处(最显而易见的就是,我基本不需要加班)。

二、软件开发面临的问题

  • 确定软件需求
  • 确定项目的进度(可见性)

这两个是当今软件开发面临的最普遍问题。
不知道多少程序员与产品经理的故事都是因为问题一。想解决这个问题,需要清楚为什么需求难定。需求难定是因为“差异”“变化”

“差异”表现在每个人对事物的看法不同(特别是美感和交互上),这点比较好解决,就是让产品经理统筹团队的意见做出最后决定即可。因为软件需要满足于业务目的,质量不等于完美,“追求完美是把事情做好的大敌”

在软件中唯一不变的就是“变化”。市场在变、事件优先级在变、客户想法在变、接口在变等等,种种的变化使得需求一直在变。既然我们不能改变“变化”,那么只能响应“变化”。

确定项目的进度是项目经理想得到却“永远”没有得到的。最让我印象深刻的是,在一次迭代的最后一天我向组员询问进度,组员非常开心地跟我说很快就完成了,最后合一下分支就能提测了。可到了接近下班的时候,他们跟我说今天没法提测了。原因是合完代码后,发现一堆冲突,解决冲突后又遇到了一些问题,无奈地加了个班。

除了这两个普遍问题,我在项目中还遇到了以下问题。

  • 如何以最快速度将软件交付给用户?
  • 如何让开发、测试、产品经理、运维人员高效协作?

不知道多少需求的变更是因为没有将软件快速交付到用户而导致的。用户需要等到开发完毕后,才能第一次体验到产品。但通常这个时候用户的反馈是,我想要的不是这样子的。导致的结果就是苦逼的改需求,重写代码。

一般的开发流程中,开发、测试、产品经理、运维等人的交集很少,这导致了一些问题:对需求的认识没有统一、开发和测试总是有时候很闲,有时候很忙、运维人员到快要上架了才知道产品长什么样。

庆幸的是,我找到了这些问题的解决方法,那就是持续集成

三、持续集成

持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误。 — Martin Fowler

持续集成

持续集成

这里很重要的一点是,持续集成是一种开发实践,而不是工具。所以,大家一定要注重持续集成的理论,而不是简单地当成个工具来用。

四、持续集成的价值

  • 让开发的软件一直处于可工作状态

每一次提交到主干的代码都经过构建来验证,这不但使得软件一直处于稳定状态,而且使得用户无论何时都能体验产品,快速反馈问题,以便产品经理可以快速修改需求,这样就能做到快速响应变化。这也就是为什么敏捷开发强调可以工作的软件 胜过 面面俱到的文档的原因。

  • 尽快发现问题

每一次提交到主干的代码都经过构建来验证,一旦验证失败,则通知到相关人员。解决问题的关键是尽快发现问题,因为尽快发现问题减少了引入缺陷与修复缺陷之间的时间。试想一下,让你修复刚写下不久的bug简单,还是等一个月后再修复这个bug简单就能明白了。

减少了引入缺陷与修复缺陷之间的时间

减少了引入缺陷与修复缺陷之间的时间

  • 防止分支大幅偏离主干

每天至少集成一次,这样能避免因分支过长而导致像上面说的那个情况,到临近提测的时候一合分支,冲突一堆,无法确定项目进度。

  • 减少重复过程&人为错误

以自动化的构建代替手工操作,可以减少重复低效的过程(高效的人总把时间用在有意义的事情上)。也能避免一些人为错误,比如:Build号忘加1、Debug开关忘关。

  • 建立团队对开发产品的信心

这点我深有体会,团队人员看到自己做的产品质量越来越好,用户越来越多,都很开心(每个程序员都有一颗产品的心)。当然了,我知道团队最开心的是,终于不用加班了。

  • 高效协作

有了持续集成,开发人员每次提交代码就会触发构建,这样产品、测试、运维就能最快体验到最新的开发版。这样,测试人员就不会在开发周一点活也没有,在测试周忙得要死。产品也能尽早看到问题,尽早反馈给开发,减少开发的修改成本。运维人员也能尽早准备相关事项。

下图是测试的同事描述持续集成前后,他周一到周五的工作量变化。

工作量

工作量

因为工作量被较平均地分配到两周,这样自然就不用加班了。因为持续集成后,软件质量提高,所以在周五发布的时候,再也不用手忙脚乱的了。

下面是实行持续集成前后两个迭代的发现bug数量分布。

虽然两次迭代开发内容不同,可能有所影响。但是我们能发现,持续集成之后,bug的数量随着时间的推移是递减的,这有利于质量的保证。

五、小结

持续集成的目的其实是沟通:集成可以让开发者告诉其他人他们都改了什么东西,频繁的沟通可以让开发者更快地了解变化。这也就是为什么敏捷开发强调个体和交互 胜过 过程和工具的原因。

持续集成有这么多价值,那要如何开展呢?下面我们就来看下它有什么前题条件。

六、持续集成的前提条件

  • 团队共识

持续集成不是工具,是一种实践,需要投入并遵守一些规则,才能提高质量。试想一下,如果开发不遵循每天至少一次提交的原则,那其他人就获取不到最新的开发版,就不能及时反馈问题,那也就体现不出持续集成的价值了。所以共识是最重要的,团队里每个人对自己负责,对团队负责

  • 频繁提交

“如果你遇到一件很痛苦的事情,似乎比较好的建议就是更频繁地做这件事情” — Martin Fowler

top Created with Sketch.