持续集成CI以及工具集

这年头，开发不仅仅是开发，也是半个运维，四分之一个 DBA，略懂前端，搞点测试。

持续集成（Continuous integration）是指频繁将代码合并至中央储存库中。“频繁”通常具体指一天多次。每次合并操作都会触发一个自动化的“构建与测试”实例，这一过程也会被称为持续构建。但是无论具体表达如何，持续集成和持续构建都无法直接实现交付和部署方面的工作——其只负责代码层面的管理，而不涉及其它具体事务。

持续交付（Continuous delivery）是指软件交付过程中的自动化机制，其中包括一部分需要开发人员亲自动手的操作。通常来讲，开发人员都会允许和启用自动部署，不过同时也会配合其他一些手动的步骤。

持续部署（Continuous deployment）是指不需要开发人员以手动方式操作的持续交付机制。整个流程皆自动实现，而不需要人为参与。

持续集成

软件开发引入 CI 的目的：用于帮助团队成员频繁、快速的集成，测试工作成果，以尽快发现集成错误。 更频繁、更早的集成意味着更早的发现问题。通过持续集成，及时发现和解决代码故障，提高代码质量，减少故障处理成本等等。可以在整个软件开发生命周期内保证代码质量，实现敏捷开发，使得一些开发工作自动化：

• 自动检查：当软件开发团队在周期性的新增或修改后的代码后，CI 服务器能持续地获取新增或修改后签入的源代码，并可以对这些变更的代码进行质量或者编码规范的检查。常用的工具有 PMD、SonarQube、CheckStyle、FindBugs等。
• 自动构建：CI 系统会依照预先制定的配置计划，或某一特定事件，自动检出代码，并对目标软件进行构建。一般有三种方式触发构建：Git 提交触发 hook，用户手动触发，每个工作日凌晨的自动任务触发。
• 自动测试：构建检查完成后，可以执行预先制定的一套测试规则，也可以在执行构建的过程中进行测试用例的测试，前提是项目团队采用测试驱动开发（TDD）。常用测试工具，如 JUnit、TestNG、Selenium 等。
• 自动部署：当自动化检查和测试成功完成，将打包软件、构件部署到一个运行环境或者软件仓库。这样，构件才能更迅速地提供给用户使用。
• 邮件提醒：当上面定义的任何一个阶段进行过程中发现出错或者预设事件得到触发，都能够及时通知给相应的项目干系人来进行处理。比如，构建出错提醒；自动化部署完成了，CI 服务器通知会测试人员可以进行测试了，等待。除邮件外，提醒方式也可以是短信、桌面通知器等。

Jenkins

可以说是最老牌的 CI 服务器，前身是 Hudson。有丰富的插件生态系统，支持构建、部署和自动化软件项目，可以轻松地跨多个机器分布工作，帮助驱动构建、测试和跨多个平台的部署更快。特性：

• 傻瓜式安装和配置，多语言 & 多系统支持；
• 数以百计的可用插件，支持自定义开发；
• 持续集成和持续交付；
• Web界面提供简单的配置和错误检查；
• 提供docker 版本，docker 支持；
• Jenkins 2 pipeline，基于Groovy的DSL；

Jenkins几个概念

• Master是Jenkins安装和运行的地方，它负责解析job脚本，处理任务，调度计算资源；
• Agent 负责处理从Master分发的任务；
• Executor就是执行任务的计算资源，它可以在Master或者Agent上运行。多个Executor也可以合作执行一些任务；
• job 任务，用来定义具体的构建过程；

Groovy是一种基于JVM的敏捷开发语言，结合Python、Ruby和Smalltalk的许多强大的特性，Groovy代码能够与Java代码很好地结合，也能用于扩展现有代码。由于其运行在 JVM 上的特性，Groovy可以使用其他Java语言编写的库。Jenkins用Groovy作为DSL；
Pipeline 流水线即代码（Pipeline as Code），通过编码而非配置CI/CD运行工具的方式定义部署。流水线使得部署是可重现、可重复的；
流水线包括节点Node、阶段Stage和步骤Step。
流水线执行在节点上。节点是Jenkins安装的一部分。流水线通常包含多个阶段。一个阶段包含多个步骤。流水线上手指南可以查看到更多的内容。
node在Pipeline中的context中，node是job运行的地方。node会给job创建一个工作空间。工作空间就是一个文件目录，这是为了避免跟资源相关的处理互相产生影响。工作空间是node创建的，在node里的所有step都执行完毕后会自动删除。
stage阶段，stage是一个任务执行过程的独立的并且唯一的逻辑块，Pipeline定义在语法上就是由一系列的stage组成的。 每一个stage逻辑都包含一个或多个step。
step步骤，一个step是整个流程中的一系列事情中的一个独立的任务，step是用来告诉Jenkins如何做。
Jenkinsfile Jenkins支持创建流水线。使用基于Groovy的流水线领域特定语言（Pipeline DSL）的简单脚本，即Jenkinsfile。定义一些根据指定参数执行简单或复杂的任务的步骤。流水线创建好后，可以用来构建代码，或者编排从代码提交到交付过程中所需的工作。

pipeline & Jenkinsfile

核心功能

插件

插件1. Job Configuration History

考虑到 Jenkins 的使用过程就是配置文件变更的过程。如果能够对配置文件的变更进行跟踪管理，将极大的提高系统的可用性。Job Configuration History 插件不仅能处理 Job Configuration 的变更历史，还能够处理系统级别的配置变更历史。
安装很简单，可能需要重启；纵览页面可以看到：系统中的配置变更(其实是系统配置和所有根及项目的配置)，并且可以通过左上方的菜单项或者是正上方的链接过滤出 “系统配置”、“Job 配置”、“创建 Job 的配置” 以及 “删除 Job 的配置” 的历史记录。并且可以查看历史记录中配置文件的内容。

Agent Config History
插件可以自动识别主从节点，故而应该能够看到 Agent Config History 视图：可以选择不同的配置版本进行比较，或者是用历史版本覆盖当前的版本。
Prev：左右两个文件都更新为前一个版本(时间上比当前版本更早的一个版本)。
Next：左右两个文件都更新为下一个版本(时间上比当前版本更晚的一个版本)。
左 Shrink Diff：左边文件更新为时间上比当前版本更晚的一个版本。
左 Expand Diff：左边文件更新为时间上比当前版本更早的一个版本。
右 Shrink Diff：右边文件更新为时间上比当前版本更早的一个版本。
右 Expand Diff：右边文件更新为时间上比当前版本更晚的一个版本。
Restore this configuration：用某个历史版本的配置信息覆盖当前的配置信息。
它们组合在一起可以方便的对比文件的不同版本。并且可以轻松的把配置回滚到某个历史时刻。

Job Config History
Job Config History 视图，和 agent 视图类似，能够极大的提高调试配置文件时的生产力，尤其是当错误发生时，可以立即定位是哪些配置的变化导致 Build 失败。

实现原理
当配置发生变化时，就把旧的配置文件复制一份存起来！旧配置文件的存放路径默认就在 Jenkins 安装目录下的 config-history 目录中：

插件2. Build Timestamp Plugin

记录每次构建的耗时信息；安装类似，可以配置时区 TIMEZONE, 时间 TIME 的格式；"BUILD_TIMESTAMP"变量，配置参数时可以使用 ${BUILD_TIMESTAMP}

其他问题
用jar -jar jenkins.war来启动 Jenkins 服务器。
关闭 Jenkins 服务
只需要在访问 Jenkins 服务器的网址 URL 地址后加上exit。按return键后会跳转到如下网页：
点击Try POSTing按钮后，就直接将jenkins服务器关闭。
重新启动jenkins服务器
将上面的exit改为restart后就可以重新启动jenkins服务器。
点击Yes按钮后，就将Jenkins重启。
重载
将上面的restart改为reload就可以实现重新加载配置信息。
点击Try POSTing按钮后就可以重载配置。

在设置 Jenkins URL 底下有一个文本框System Admin e-mail address，这里设置发送者的邮箱地址，否则邮件可能发送不成功。报错信息：

com.sun.mail.smtp.SMTPSendFailedException: 501 mail from address must be same as authorization user;  nested exception is: com.sun.mail.smtp.SMTPSenderFailedException: 501 mail from address must be same as authorization user
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)

TeamCity

大名鼎鼎的 JetBrains 公司的产品，官网：http://www.jetbrains.com/teamcity/。 插件系统丰富，有社区版和终极付费版。特性参考：http://www.jetbrains.com/teamcity/features/：

• Technology Awareness
• Key Integrations
• Cloud Integrations
• Continuous Integration
• Configuration
• Build History
• Build Infrastructure
• Code Quality Tracking
• VCS Interoperability
• Extensibility and Customization
• System Maintenance
• User Management

安装 TeamCity 好之后，创建项目，关联到代码仓库，比如 Git，设置触发构建的方式，添加质量坚持工具比如 sonarqube，设置构建命令比如 maven clean install -Dmaven.test.skip=true，构建成功之后设置构建产物比如 jar/war 上传到指定的部署服务器的 Tomcat servlet 容器指定目录（比如 Tomcat 是 webapps ）下面，然后可能需要重启 Tomcat。大公司的持续集成部署 CI/CD 不会如此简陋，但是功能流程都是类似的。在此基础之上加强，实现热部署，即不需要重启 servlet 容器，部署版本回退，多节点负载均衡等等。

Travis CI

开源产品，得知这个是经常看到 GitHub 项目里面有一个 .travis.yml 文件，可以自动化测试和部署GitHub项目中的代码。需要在官网注册账号，关联到 GitHub 的指定仓库 repository，且必须是感慨的 public，否则 private 需要付费。特点和大多数 CI 服务器类似：

• 多系统、多语言支持；
• 运行时可查看测试；
• 通过电子邮件、Hipchat或Slack进行通知；
• API和命令行接口可用

实例讲解

GitHub repository 添加 .travis.yml 文件，自动触发构建：

其他工具

CodeShip

CodeShip是一个简单优雅且适合中小规模开发团队的CI/CD平台。部署快，易损耗、成本低。易用性比肩Travis，而更胜一筹的是集成相当数量的选项，可以根据自身的工作流程和开发工具定制化CI/CD工作流。如果使用公有云的小团队想快速地把CI/CD工作流集成到工作流程中，CodeShip是一个不错的选择。类似的产品：CircleCI、MagnumCI。

CodeFresh

纯粹为Docker镜像提供CI/CD工作流。虽然CodeFresh不是典型的CI/CD平台，但它提供一种有趣的应用场景，在容器上使用CI/CD从而促进Docker，Kubernetes和云原生的发展前景。

Bamboo

来自牛逼的软件公司 Atlassian，开箱即用，可在硬件上运营。Bamboo是一个聚焦企业级的解决方案，并且包含具有极强竞争力的特性、定价和技术支持等。可以部署在大规模生产环境中。如果开发团队使用Atlassian相关技术和产品，那么Bamboo是最佳选择。还提供大量的集成功能，稍作修改配置就能达到团队理想的工作流程。

GitLab

开源版本控制系统功能外延，可以一试。毕竟 CI/CD 是从源码开始的。

BitBucket

上面提到过Atlassian的Bamboo构建系统，实际上Atlassian在BitBucket上也集成了CI/CD，称作工作流（Pipelines） 。简单地说，工作流是BitBucket针对CI/CD的SaaS解决方案，如果BitBucket也是工具集成的一部分，那么工作流是尝试把CI/CD整合到工作流程最简单的开始。

GitHub’s Integration Library

GitHub的一个系统集成库。参考 GitLab 介绍。

Azure

Azure可以对接任意CI/CD平台的支持。CodeShip和CircleCI是原生整合在Azure理的功能，且微软提供针对CI/CD以及基于Jenkins、DC/OS的Azure容器服务使用指南。
微软对于CI/CD，Node.js和Azure容器服务都做了极好的工作，可快速地定制出特定技术栈场景下部署的CI/CD，实现应用与生产的无缝对接。

Heroku

Heroku也提供一种有趣的CI/CD工具——Flow。Flow让你设置的工作流，它可以运行测试工作流程，启动测试应用，这些都能相对轻松地启动和回滚，并集成在GitHub中用以完成部署请求和部署状态。Flow是Heroku平台的完美延伸。它能够快速启动，正如Heroku一如继往擅长的那样，把这种能力延伸到CI/CD工作流程中。容器渐渐成为CI/CD工具链的核心。