Jenkins && CI/CD

Jenkins简介

 

Jenkins的主要开发者是川口耕介, 是在MIT许可证下发布的自由软件。

Jenkins是一个用Java编写的开源的持续集成工具。在与Oracle发生争执后，项目从Hudson项目独立。

Jenkins提供了软件开发的持续集成服务。它运行在Servlet容器中（例如Apache Tomcat）。

Jenkins支持软件配置管理（SCM）工具（包括AccuRev SCM、CVS、Subversion、Git、Perforce、Clearcase和RTC），可以执行基于Apache Ant和Apache Maven的项目，以及任意的Shell脚本和Windows批处理命令。

 

Jenkins功能

1、持续的软件版本发布/测试项目。

2、监控外部调用执行的工作。

 

Jenkins概念

Jenkins是一个功能强大的应用程序，允许持续集成和持续交付项目，无论用的是什么平台。

这是一个免费的开源项目，可以处理任何类型的构建或持续集成。集成Jenkins可以用于一些测试和部署技术。Jenkins是一种软件允许持续集成。

 

Jenkins目的

① 持续、自动地构建/测试软件项目。

② 监控软件开放流程，快速问题定位及处理，提提高开发效率。

 

Jenkins特性

① 开源的java语言开发持续集成工具，支持CI，CD。

② 易于安装部署配置：可通过yum安装,或下载war包以及通过docker容器等快速实现安装部署，可方便web界面配置管理。

③ 消息通知及测试报告：集成RSS/E-mail通过RSS发布构建结果或当构建完成时通过e-mail通知，生成JUnit/TestNG测试报告。

④ 分布式构建：支持Jenkins能够让多台计算机一起构建/测试。

⑤ 文件识别:Jenkins能够跟踪哪次构建生成哪些jar，哪次构建使用哪个版本的jar等。

⑥ 丰富的插件支持:支持扩展插件，你可以开发适合自己团队使用的工具，如git，svn，maven，docker等。

产品发布流程

产品设计成型 -> 开发人员开发代码 -> 测试人员测试功能 -> 运维人员发布上线

 

 

 

持续集成 持续交付 持续布署 (CI/CD)

持续集成

持续集成(Continuous Integration)，一种软件工程流程，将所有工程师对于软件的工作复本，每天集成数次到共用主线(mainline)上。

这个名称最早由葛来迪·布区（Grady Booch）在他的布区方法中提出，但是他并没有提到要每天集成数次。

之后成为极限编程（extreme programming，缩写为XP）的一部分。在测试驱动开发（TDD）的作法中，通常还会搭配自动单元测试。

持续集成的提出，主要是为了解决软件进行系统集成时面临的各项问题，极限编程称这些问题为集成地狱（integration hell）。

持续集成主要是强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，确定新代码和原有代码能否正确地集成在一起。

简单来讲就是：频繁地（一天多次）将代码集成到主干。

持续集成目的在产生以下效益如：

• 及早发现集成错误且由于修订的内容较小所以易于追踪，这可以节省项目的时间与成本。

• 避免发布日期的前一分钟发生混乱，当每个人都会尝试为他们所造成的那一点点不兼容的版本做检查。

• 当单元测试失或发生错误，若开发人员需要在不除错的情况下还原代码库到一个没有问题的状态，只需要放弃一小部分的更改 (因为集成的次数频繁)。

• 让 "最新" 的程序可保持可用的状态供测试、展示或发布用。

• 频繁的提交代码会促使开发人员创建模块化，低复杂性的代码。

• 防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。

 

持续交付

持续交付(Continuous Delivery), 是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。

它的目标在于让软件的构建、测试与释出变得更快更频繁。这种方式可以减少软件开发的成本与时间，减少风险。

持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。

比如，我们完成单元测试后，可以把代码部署到连接数据库的Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。

 

持续部署

持续部署(Continuous Deployment)，是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。

持续部署即在持续交付的基础上，把部署到生产环境的过程自动化。

 

简单总结

持续集成(Continuous Integration, CI): 代码合并，构建，部署，测试都在一起，不断地执行这个过程，并对结果反馈。

持续交付(Continuous Deployment, CD):　将产品部署到测试环境、预生产环境, 手动(选择性的)布署到生产环境。　

持续部署(Continuous Delivery, CD): 将最终产品自动布署到生成环境, 给用户使用。

 

持续交付与持续部署

持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署, 人为控制。

持续部署意味着所有的变更都会被自动部署到生产环境中,自动部署。

如果要实施持续部署，必须先实施持续交付.

 

持续交付与 DevOps

持续交付与DevOps的含义很相似, 所以经常被混淆, 但是它们是不同的两个概念。

DevOps的范围更广, 它以文化变迁为中心, 特别是软件交付过程所涉及的多个团队之间的合作(开发,运维,QA,管理部门等), 并且将软件交付的过程自动化。

持续交付是一种自动化交付的手段，关注点在于将不同的过程集中起来，并且更快、更频繁地执行这些过程。

因此，DevOps可以是持续交付的一个产物，持续交付直接汇入DevOps。

 

 

DevOps（Development和Operations的组合词）

是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

 

它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

 

它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

 

从定义来看，其实devops就是为了让开发、运维和QA可以高效协作的流程。（可以把DevOps看作开发、技术运营和质量保障（QA）三者的交集。）

 

 

DevOps对应用程序发布的影响

在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险很低

 

（1）减少变更范围

与传统的瀑布模式模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。

 

（2）加强发布协调

靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；采用电子数据表、电子数据表、电话会议和企业门户（wiki、sharepoint）等协作工具来确保所有相关人员理解变更的内容并全力合作。

 

（3）自动化

强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。

与传统开发方法那种大规模的、不频繁的发布（通常以“季度”或“年”为单位）相比，敏捷方法大大提升了发布频率（通常以“天”或“周”为单位）。

 

 

 

DevOps 与 CICD的区别及联系

• DevOps是CICD思想的延伸，
• CICD是DevOps的基础核心，如果没有CICD自动化的工具和流程，DevOps是没有意义的。

 

Docker、Kubernetes的 CICD实现思路

Jenkins是一个比较流行的持续集成工具

GitLab是存储镜像的镜像仓库

由客户端将代码push推送到git仓库，gitlab上配置了一个webHook的东西可以触发Jenkins的构建。进入到Jenkins虚线范围内，它所做的事情非常多，从mvn构建代码，对代码进行静态分析，做单元测试，测试通过之后就可以build镜像，镜像构建成功后就把镜像push推送到Harbor镜像仓库中，镜像push推送到镜像仓库后，我们就可以调用kubernetes集群的restAPI更新服务，而后kubernetes接收到了更新的指令，从Harbor镜像仓库pull拉取镜像，从而完成服务的更新与重启，最后我们从客户端来访问kubernetes集群的服务

1.开发从镜像库里获取基础镜像，对应用进行容器化开发；

2.开发提交代码到Gitlab（在Kubernetes中实现Gitlab服务，并通过持久化存储保存用户数据）；

3.Gitlab收到代码提交请求后通过webhook触发Jenkins master

4.Jenkins master收到请求后在slave节点中对源码进行打包；

5.在源码打包完成后根据流水线，从Gitlab中获取dockerfile，在slave节点中生成docker images；

6.Docker镜像生成之后上传到Docker 私有仓库harbor；

8.通过Jenkins流水线在Kubernetes测试环境拉取镜像，部署应用；

9.测试成功之后，通过Jenkins流水线在Kubernetes生产环境进行应用的部署上线。

其中build镜像过程还可以细分为两部：

• 构建可执行的程序包（Java为tar包）
• 将tar包导入基础镜像（Java程序的基础镜像可以理解为一个包含了JDK的linux系统），其实现可以通过dockerfile导入tar包到基础镜像从而构建为应用镜像，也可以通过openshift的s2i启动一个名为build的pod将tar包的二进制流导入基础镜像然后通过docker commit构建为应用镜像