持续集成CI、持续部署CD以及工具集

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

持续构建（Continuous Build）指频繁将代码合并至VCS中。频繁，无法精确定义的词汇，不同公司或团队有不同的实践。通常具体指一天多次。每次合并操作都会触发一个自动化的构建与测试实例。

持续集成（Continuous Integration）是但是无论具体表达如何，持续集成和持续构建都无法直接实现交付和部署方面的工作，其只负责代码层面的管理，而不涉及其它具体事物。

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

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

持续集成

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

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

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代码很好地结合，也能用于扩展现有代码。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

核心功能

插件

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 目录中：

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，这里设置发送者的邮箱地址，否则邮件可能发送不成功。报错信息：

Failed to send out e-mail
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)

其他CI工具

TeamCity

TeamCity是JetBrains的CI/CD工具。它允许用户在代码提交之前构建、监视和执行自动化测试，从而维护干净的代码库。提供全面的VCS集成，使CI服务器始终保持正常运行，即使没有任何构建。它可以与Amazon EC2、Microsoft Azure和VMware vSphere集成。

插件系统丰富，有社区版和终极付费版。特性如下：

• 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工作流。类似产品：CircleCI、MagnumCI。

CodeFresh

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

Bamboo

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

GitLab

开源VCS功能外延。在GitLab中，每当有代码提交或合并请求时，GitLab会根据.gitlab-ci.yml文件中定义的指令自动运行构建和测试流程。

BitBucket

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

CircleCI

一个基于云的CI/CD服务，它支持快速软件交付且易于扩展：

1. 云端优势：无需管理物理服务器，提供灵活的资源配置；
2. 速度和效率：通过并行运行作业，显著缩短构建和测试时间。

CircleCI提供各种预配置的环境和工具，使用YAML文件定义工作流程。具体来说，在项目根目录下创建config.yml文件来定义构建、测试和部署的步骤，可用于不同环境。

Buildkite

Buildkite是开源平台，可以在上面运行CI流水线。提供源码控制、聊天支持，并且不需要访问源码。你可以将基础设施作为代码系统来进行调度，从而使你可以通过他们的网页平台监视和控制所有流水线。然而，该平台缺少一些DevOps流程，比如源码管理和安全测试。

GitHub’s Integration Library

GitHub的一个系统集成库。

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工具链的核心。

持续交付

Spinnaker

官网：https://www.spinnaker.io/
Spinnaker无缝集成已有CI工作流。可从Git，Jenkins，Travis CI，Docker registry，类似cron的调度器，或甚至其他流水线里触发流水线。Spinnaker开箱即用地支持精细的部署策略，比如发布canary，多阶段环境，红/黑（也称为蓝/绿）部署，流量分流并且易于回滚。
对于需要针对某个项目或者账号实施基于角色访问控制的管理员来说，Spinnaker支持多种授权和认证的方式，包括OAuth，SAML，LDAP，X.509 certs，GitHub Teams，Azure Groups，Google Groups。

用户还可以基于人工判断来授权，Spinnaker stage在继续执行工作流之前要求人工审批，确保每个版本不会发生在没有得到正确人员授权之前。

提供全新的开源命令行接口CLI工具，称为halyard，帮助管理员更容易地安装，配置以及升级用于生产环境的Spinnaker实例。

halyard

JFrog Artifactory

专业工具，用于管理和分发软件包。

Sonatype Nexus

持续部署

能实现CI的工具，几乎都具备CD功能。

BuildMaster

官网：https://inedo.com/buildmaster

借助于Inedo的BuildMaster，开发人员能够用它将软件发布到各种环境，为各种平台提供全面的CD能力，使团队有能力创建私有的自助发布管理平台，单独处理自己的应用程序并私有部署。避免自动发布未经测试的软件。无需精通流水线即可使用，简洁易用。

Microtica

官网：https://microtica.com/

Microtica是DevOps自动化工具，从创建云基础设施到使用K8S交付应用程序和服务，覆盖了整个软件交付过程。Microtica的开箱即用组件为用户提供可重用的代码片段，无需额外编码即可帮你在几分钟内搭建起底层架构。

通过微服务生成器，开发人员可以自动化地创建微服务。通过已集成的预上线K8S和本地K8S仪表板，只要点一点鼠标就能创建出可伸缩的应用程序。

Microtica流水线定义每个组件和微服务的工作流。用户可以随时自动或手动触发它们，获取整个构建的概览。用户可在Microtica网站内执行所有的操作，每次变更都有Slack通知。

Microtica允许开发人员设置自动化的休眠周期，降低AWS成本。一旦启动节约模式，Microtica会自动运行，防止过度消费，节省金额可在成本仪表板中看到。

Semaphore

官网：https://semaphoreci.com

Semaphore覆盖整个CI/CD过程，支持GitHub、K8S、iOS、Docker，并预装100多个工具。可以自动化任何持续交付流水线，并提供自定义步骤、并行执行、依赖管理等。Semaphore构建非常快速，而且操作简单。

Buddy

官网：https://buddy.works/

Buddy是CI/CD平台，通过简单的UI/UX来减少配置和维护Jenkins的工作量，这使得创建、评估和部署应用程序变得非常简单。可在15分钟内通过具有即时YAML导出功能的图形化界面完成配置。它可以在云端和本地使用，并提供完整的Docker和K8S支持。

Drone.io

官网：https://drone.io/

Drone.io是自助CD平台，使用简单的YAML配置文件和DockerCompose的超集，在Docker容器中创建和执行流水线。运行时会自动下载独立的Docker，它执行容器中的每个流水线步骤。

GoCD

官网：https://www.gocd.org/

GoCD是ThoughtWorks的持续集成开源服务。您可以使用它来简化动态工作流的模拟和可视化。它提供持续交付和优雅的设计来构建CD流水线，支持并行和顺序执行，可以随时部署任何版本，有活跃的支持社区。用户反馈，GoCD与跨服务器扩展不兼容，但优点是可以自定义流程。