关于持续集成

持续集成的概念

在传统的团队开发过程中，每个开发人员都会不定期地向代码库提交代码，每次在开始新功能的开发工作前，也会更新代码库的代码到本地。如果某个人某次提交的代码有问题，其他人更新来下后发现了他的错误就需要提醒他去修改代码并重新提交到代码库，然后还要通知其他人重新更新代码。整个过程，费时费力。并且，这样的情况在团队开发过程中并不少见，极大地影响了开发效率。

持续集成正是为了解决这个问题而诞生的一种软件开发实践。通过持续集成的引进，每一次代码提交到代码库后，都会自动触发执行代码编译、静态扫码、部署、测试（包括但不限于单元测试、接口测试、UI自动化测试、安全测试等等）等为了保证产品质量而事先设定好的一系列操作。通过执行这些操作和及时反馈的结果，使得每一次的代码提交都能及时得到反馈，使得开发团队可以安心提交代码、放心更新代码，对软件开发过程和产品质量都信心满满。

持续集成工具——Jenkins简介

在实际的工程实践中，持续集成有6大实施工具，最常使用的是jenkins。Jenkins是使用java语言开发的一款开源的web服务，可以非常方便地部署在tomcat等web容器中使用。通过高达上千种的扩展插件，使得jenkins可以满足绝大部分项目、流程管理和监控的需求。关于jenkins的下载、安装和使用方法，难度不大，大家可以自行百度。

Jenkins2.0

Jenkins2.0介绍

Jenkins2.0是2016年4月20日发布的针对jenkins1.x的升级版，也是jenkins问市以来的首次实质的版本升级。按照官方的描述，jenkins2.0的主要特征分别是Pipeline as Code，全新的开箱体验和1.x的兼容性。Pipeline as code应该算是jenkins2.x带来的最实质的变化了。

Jenkins2.0 支持通过在构建过程执行项目路径中某个（些）事先写好的Groovy 脚本来实现类似jenkins1中pipeline那样的工作流管理。这种方式，无疑比Jenkins1.x中只能通过手工配置的方式建立pipeline更加灵活。

jenkins2.0支持三种类型的Pipeline:普通Pipeline，MultibranchPipeline和Organization Folders。后两种其实是批量创建一组普通Pipeline的快捷方式，分别对应于多分支的应用和多应用的大型组织。

Pipeline设计三个基本概念：

Stage: 一个Pipeline可以划分为若干个Stage，每个Stage代表一组操作。注意，Stage是一个逻辑分组的概念，可以跨多个Node。

Node: 一个Node就是一个Jenkins节点，或者是Master，或者是Agent，是执行Step的具体运行期环境。

Step:Step是最基本的操作单元，小到创建一个目录，大到构建一个Docker镜像，由各类Jenkins Plugin提供。

 

通过Groovy脚本实现工作流管理的步骤如下：

• 建立Pipelinejob，并通过Groovy脚本定义工作流：

定义工作流：

脚本如下：

node {
stage('Checkout Code') { // for display purposes
// Get some code from a GitHub repository
git 'https://github.com/jglick/simple-maven-project-with-tests.git'
}
stage('Build') {
// Run the maven build
if (isUnix()) {
sh "'${MAVEN_HOME}/bin/mvn' -Dmaven.test.failure.ignore clean package"
} else {
bat(/"${MAVEN_HOME}\bin\mvn" -Dmaven.test.failure.ignore clean package/)
}
}
stage('Unit test') {
junit '**/target/surefire-reports/TEST-UT.xml'
archive 'target/*.jar'
}
}

Groovy是一种在语法上类似java的脚本语言，有java基础的人都很容易上手，学习和使用成本较低。

• 完成其它配置，执行job。PipelineJob的配置比较简单，大部分的配置工作都是通过脚本完成的。配置好后就可以执行job了。

构建过程的stage View如下：

会实时显示各个工作流的执行进度和结果，比较直观。鼠标移上去，能看到日志信息的缩略图，单击可以调到对应stage的console中。

•  查看结果。和1.0一样，Jenkins2.x默认也是通过红黄绿（可以通过插件切换颜色）三种颜色来标识job和pipeline的执行结果的。点击stage，可以查看具体日志信息。也可以通过安装插件格式化展示构建结果、统计成功率、分析异常日志等等。

构建结束后的stage View:

从CI到CD

       Pipeline as code，jenkins官方号称这是从CI到CD的革命性转变。我个人对此有不同的理解。不得不承认，这种灵活的pipeline构建方式有其合理性和应用价值，但是各个软件项目是只能支持CI，还是可以实现CD，是由项目的应用场景、体系架构、人员结构等诸多因素决定的，不是一个作为工具的jenkins2.0可以左右的。事实上，用过这两个版本的人都知道，jenkins2.x能干的事情，jenkins1.x都可以做。

CD包括两个层次：ContinuousDelivery(持续交付)和Continuous Deployment(持续部署)

Continuous Delivery和CI一样，是一种软件开发实践。它通过将每一次改动都提交到一个模拟产品环境中，使用非常完备的自动化测试，确保业务应用和服务能符合预期，确保让代码能够“随时”安全地部署到生产环境中。

Continuous Deployment是持续交付的更高阶段。每一次代码提交，如果通过了多有的自动化测试，就会自动的部署到产品环境里。大多数的公司如果没有制度的约束或其它条件的影响，都应该以持续部署为目标。但是有很多的业务场景里，一个功能需要等待另外的依赖功能也开发完成才能上线，这使得持续部署不能实施。所以，持续部署是否适合项目，是基于业务需求和使用场景的。

综合以上原因，要想实现CI到CD 的变革，除了项目的使用场景需要满足要求外，更多的还得依靠人：一方面，在系统架构的设计阶段就得充分考虑；另一方面，依靠人去优化团队的开发、测试流程，完善测试和运维的自动化程度（包括但不限于完善自动化测试的完备性和运维自动化的程度）来实现。