持续集成的重要性？

背景

自从我们使用scrum进行项目开发后，出现了这样那样的问题，有些是因为我们对scrum的理解不到位，有些则是客观因素导致的，针对这些问题，在每次迭代的总结会上，我们进行了反思，并根据具体环境对scrum进行了一一调整，想通过几篇文章和大家分享一下我的经验。

 

我说的不一定正确，只是描述问题，然后说说我对问题的看法，采取的解决方案，希望使用敏捷开发的大牛提供宝贵意见。

 

为什么我们需要持续集成？

 

又要从我们的故事说起，我越来越喜欢讲故事了……

 

在前几个sprint的评审会上，我们只是让各个组员单独演示了自己开发的功能，并且约定时间，大家都提交一个稳定的版本，做了一次集成。

 

过了一些天，领导L突然造访，想看看项目进展，让我们集成起来，这时候问题来了，各个模块开发进度不一，很难找到某个时间点，让大家顺利集成。上次是约定好时间，大家有所准备，这次又不能使用上次的集成版本，太陈旧了。所以出现了这样的情况，领导L坐在那里等着看，大家赶紧手忙脚乱的构建，然后集成，幸好没出大问题，结果可以看了，但中间浪费了不少时间。

 

领导L的造访，说明了他对进度和质量的担忧，我们该如何让他放心？

 

另一方面，scrum提倡，可用的软件优于面面俱到的文档。但如何保证可用软件的质量成了一个棘手的问题，尤其是在不断变化的需求中。

 

怎么办才能看出软件质量的优劣，进度的快慢？ 经常集成起来，看看效果，不就知道质量怎么样，进度怎么样了嘛？而且经常集成起来看，有助于发现问题，解决问题，如需求有没有偏差，是不是领导和客户想要的效果，又或者发现和解决这样那样的bug等等。

 

但经常集成，又会牵扯开发人员很多精力去更好地协同工作，这是在开发过程中不可回避的问题。

 

这次又得站在巨人的肩膀上了，看下面一段话：

 

持续集成正是针对上述一系列问题的一种软件开发实践，它倡导团队开发成员必须经常集成他们的工作，甚至每天都可能发生多次集成。而每次的集成都是通过自动化的构建来验证，包括自动编译、发布和测试，从而尽快地发现集成错误，让团队能够更快的开发内聚的软件。

——Martin Fowler

持续集成的核心价值在于：

1、降低风险，每天都可能发生多次集成，有利于及早发现软件质量问题。

2、自动完成，通过自动化工具可以避免开发人员投入过多精力

3、软件运行状态随时可看，可以增加领导和团队成员对项目的信心。

4、利于对未来进行把控，持续集成的信息有利于我们对未来进行更好地规划和把控。

 

概念不多说，我们团队非常需要持续集成，所以经过调研，我们采用jenkins作为持续集成的大管家，Jenkins 就是一个配置简单和使用方便的持续集成服务器。由它完成自动构建、自动部署、集成。用了一段时间，还不错，上面说的一系列问题也迎刃而解。

写到这里有一点小感触：很多东西的产生是那么地理所当然，顺理成章。