软件开发——软技能（七、持续集成）

七、持续集成

    “持续集成”的概念已经不是什么新鲜事物。但对于国内的很多软件公司来讲，可能就是个新东西，更别说使用到项目中。项目的编译都很原始，发布的话就更不用说了。就拿Java Web项目来说，很多公司都是采用Eclipse来打war包（这也跟没有使用好编译、构建工具有关），然后放到生产线，修改配置，启动服务等这种手工操作。手工操作的问题在于，操作过程中容易出问题，配置参数、发布不能出一点错，出错了则要花很多时间去找这个错误，影响发布不说，还浪费人力。更别说，这种工作是重复的且枯燥无味。这也是“持续集成”出现的意义和各种持续集成工具所要解决的问题。

    持续集成主张项目的开发人员频繁的将他们对源码的修改提交(check in)到一个单一的源码库，并验证这些改变是否对项目带来了破坏，持续集成包括以下几大要点：

• 访问单一源码库，将所有的源代码保存在单一的地点（源码控制系统）， 让所有人都能从这里获取最新的源代码，提倡开发人员频繁提交修改过的代码；
• 支持自动化创建脚本，使创建过程完全自动化，让任何人都可以只输入一条命令或者几次点击就完成系统的创建；
• 测试完全自动化，要求开发人员提供自测试的代码，让任何人都可以只输入一条命令或者几次点击就运行一套完整的系统测试；
• 支持自动化部署，能够按照不同的要求发布到测试、发布服务器，提供测试环境和发布程序包；
• 自动提供集成信息，按照不同情况提供通过邮件、报告等方式提供每次集成结果，并且提供发布平台大家能轻易看到集成的进度和结果。

     持续集成的关键是 完全的自动化， 自动读取源代码、编译、测试、部署、信息发布。对于每次成功的创建，要求在这个自动化过程中的每一步都不能出错，而最重要的一步是测试，只有最后通过测试的创建才是成功的创建。
     在持续集成里面创建不再只是传统的编译那么简单，创建还应该包括自测试，自测试的代码是开发人员提交源码的时候同时提交的，是针对源码的单元测试，将所有的这些自测试代码整合到一起形成测试集，在所有的最新的源码通过编译之后还必须通过测试集的测试才算是成功的创建。< 出处>

    一些关于持续集成方面的文章如下：

持续集成是什么？

使用Docker实现丝般顺滑的持续集成

如何部署软件 - 让你团队的部署像地狱一样无聊且毫无压力

    Jenkins是一款Java实现的开源持续集成工具，具有丰富的插件。在Java项目中，使用好jenkins，能够达到完全的自动化（或半自动化），自动读取源代码、编译、测试、部署、信息发布。能够把上述繁琐的发布过程，通过一次配置，然后简化为一条命令或几次点击。