1 简介

介绍

Build great things at any scale.
The leading open source automation server, Jenkins provides hundreds of plugins to support building, deploying and automating any project.
Jenkins是一个开源的、提供友好操作界面的持续集成(CI)工具，起源于Hudson（Hudson是商用的），主要用于持续、自动的构建/测试软件项目、监控外部任务的运行（这个比较抽象，暂且写上，不做解释）。Jenkins用Java语言编写，可在Tomcat等流行的servlet容器中运行，也可独立运行。通常与版本管理工具(SCM)、构建工具结合使用。常用的版本控制工具有SVN、GIT，构建工具有Maven、Ant、Gradle。

特性

开源的java语言开发持续集成工具，支持CI，CD。
易于安装部署配置：可通过yum安装,或下载war包以及通过docker容器等快速实现安装部署，可方便web界面配置管理。
消息通知及测试报告：集成RSS/E-mail通过RSS发布构建结果或当构建完成时通过e-mail通知，生成JUnit/TestNG测试报告。
分布式构建：支持Jenkins能够让多台计算机一起构建/测试。
文件识别:Jenkins能够跟踪哪次构建生成哪些jar，哪次构建使用哪个版本的jar等。
丰富的插件支持:支持扩展插件，你可以开发适合自己团队使用的工具，如git，svn，maven，docker等。

2 CI/CD介绍

CI / CD的采用改变了开发人员和测试人员如何发布软件。
在这里插入图片描述
最初是瀑布模型，后来是敏捷开发，现在是DevOps，这是现代开发人员构建出色的产品的技术路线。随着DevOps的兴起，出现了持续集成（Continuous Integration）、持续交付（Continuous Delivery）、持续部署（Continuous Deployment）的新方法。传统的软件开发和交付方法正在迅速变得过时。从历史上看，在敏捷时代，大多数公司会每月，每季度，每两年甚至每年发布部署/发布软件。然而，现在，在DevOps时代，每周，每天，甚至每天多次是常态。当SaaS正在占领世界时，尤其如此，您可以轻松地动态更新应用程序，而无需强迫客户下载新组件。很多时候，他们甚至都不会意识到正在发生变化。开发团队通过软件交付流水线（Pipeline）实现自动化，以缩短交付周期，大多数团队都有自动化流程来检查代码并部署到新环境。

2.1 CI(Continuous integration)持续集成

介绍

CI(Continuous integration)即持续集成。在CI环境中，开发人员将会频繁地向主干提交代码。这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试流进行验证。
在这里插入图片描述

要求

团队需要为每个新功能、代码改进、或者问题修复创建自动化测试用例。
你需要一个持续集成服务器，它可以监控代码提交情况，对每个新的提交进行自动化测试。
研发团队需要尽可能快的提交代码，至少每天一次提交。

优点

通过自动化测试可以提早拿到回归测试的结果，避免将一些问题提交到交付生产中。
发布编译将会更加容易，因为合并之初已经将所有问题都规避了。
减少工作问题切换，研发可以很快获得构建失败的消息，在开始下一个任务之前就可以很快解决。
测试成本大幅降低，你的CI服务器可以在几秒钟之内运行上百条测试。
你的QA团队花费在测试上面的时间会大幅缩短，将会更加侧重于质量文化的提升上面。

2.2 CD(Continuous Delivery)持续交付

介绍

CD(Continuous Delivery)即持续交付。它可以让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。
在这里插入图片描述

要求

你需要有强大的持续集成组件和足够多的测试项可以满足你代码的需求。
部署需要自动化。触发是手动的，但是部署一旦开始，就不能人为干预。
你的团队可能需要接受特性开关，没有完成的功能模块不会影响到线上产品。

优点

发布频率更快，因为你不需要停下来等待发布。每一处提交都会自动触发发布流。
在小批量发布的时候，风险降低了，发现问题也可以很轻松的修复。
客户每天都可以看到我们的持续改进和提升，而不是每个月或者每季度，或者每年。

2.3 CD(Continuous Deployment)持续部署

介绍

CD(Continuous Deployment)即持续部署。在CD环境中，通过自动化的构建、测试和部署循环来快速交付高质量的产品。某种程度上代表了一个开发团队工程化的程度，任何修改通过了所有已有的工作流就会直接和客户见面，只有当一个修改在工作流中构建失败才能阻止它部署到产品线。
持续部署是一个很优秀的方式，可以加速与客户的反馈循环，但是会给团队带来压力，因为不再有“发布日”了。开发人员可以专注于构建软件，他们看到他们的修改在他们完成工作后几分钟就上线了。