自动化持续集成系列 -- 我真的需要吗？

[zhengguorong]

什么是持续集成

持续集成（英语：Continuous integration，缩写CI）是一种软件工程流程，是将所有软件工程师对于软件的工作副本持续集成到共用主线（mainline）的一种举措。——维基百科

请注意，持续集成只是一种工作流程，它的宗旨是避免集成问题，无论你是手动还是通过工具，只要你开发的软件每天不断的集成，就可以认为是持续集成。

持续集成解决的问题

探究持续集成解决的问题前，我们先想一下，如果不使用持续集成，会有什么问题。

1、集成风险

如果你开发的软件存在多个团队开发不同模块，在上线前夕进行集成往往都存在较大风险，有可能你调用其他模块的接口已经被修改，或者合并代码时存在较大量的冲突在解决冲突时无意引入的bug。 问题越早修改成本越低，因此我们可以使用持续集成每次进行小批量的集成，让问题更早的暴露出来，降低集成与上线的风险。

2、处理异常问题成本

我们通常把系统遗留问题和不规范的代码比作债务，债务会随着时间不断累积，最终导致无法偿还。 因此，问题在产生的初期去解决是最好的时机，通过持续集成保证系统随时可运行，遇到问题随时解决。

3、软件质量

自动化持续集成一般会包含自动化测试，自动测试可以帮助我们提高代码质量，开发者也可以大胆的重构或者添加新功能而不需要担心破坏原有系统。

4、自动构建/部署

我们需要部署web项目到生产环境，一般需要本地进行构建，拷贝到服务器，重启服务器。 这一系列手动的操作，难免会存在一定风险，例如一些复杂的项目，需要修改配置文件，万一构建时忘记修改，会引起线上异常。 如果要避免这些风险，可以利用自动构建，让机器帮我们做这些繁琐的事情。

自动化持续集成方案

目前自动化持续集成方案已经比较成熟了，下面介绍三款较常用到的解决方案。

1、jenkins

jenkins是一个较早出现的基于java编写的开源解决方案。 插件比较齐全，可以通过安装插件关联其他系统，例如gitlab、github，监听提交代码，自动触发构建。

2、gitlab CI

gitlab是一套开源的代码管理软件，较多应用于企业内部自建代码仓库。 gitlab CI是gitlab 8.0后引入的，它需要依赖gitlab runner进行任务构建，gitlab runner可以选择docker作为构建容器，任务的配置是比较方便。同时因为gitlab CI和gitlab本来就是一体的，不需要像jenkins那样配置hook，使用起来相对方案。 具体安装和使用方法可以参考：《自动化持续集成》-- gitlab CI

3、travis CI

travis CI对开源项目提供免费构建服务，如果你的项目是在github开放的开源项目，建议使用travis CI体验整体操作流程，配置和构建的过程都比较简单，也比较容易集成其他工具。 可以参考我之前写的 《自动化持续集成》-- github + travis CI进行配置

最后，如果你决定使用自动持续集成了，可以看看我之前写的方案对比 《自动化持续集成》-- 方案对比