持续集成（Continuous integration）

发布于 2022-08-21 | 作者: 休耕 | 来源: 博客园 | 转载于: 博客园

一、基本概念

1、持续集成

持续集成（Continuous integration，简称CI），简单来说持续集成就是频繁地（一天多次）将代码集成到主干。

每次集成都通过自动化的构建（包括编译、发布、自动化测试）来验证，从而尽快地发现集成错误。

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

持续集成的好处： 

持续集成的目的：  

让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。

持续集成并不能消除 Bug，而是让它们非常容易的发现和改正。

2、持续交付

持续交付（Continuous delivery）指的是：频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。

持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。

3、持续部署

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

持续部署的目标是：代码在任何时候都是可以部署的，可以进入生产阶段，持续部署的前提是能自动化完成测试、构建、部署等步骤。

4、持续交付和持续部署的区别

CD是持续交付和持续部署，但是持续交付不等于持续部署。持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。具体区别参考下图：

二、持续集成的一般流程

根据持续集成的设计，代码从提交到生产，整个过程有以下几步：

（1）提交

流程的第一步，是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交（commit）。

（2）测试（第一轮）

代码仓库对commit操作配置了钩子（hook），只要提交代码或者合并进主干，就会跑自动化测试。

（3）构建

通过第一轮测试，代码就可以合并进主干，就算可以交付了。

交付后，就先今夕构建（build），再进入第二轮测试。所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源（样式表、JS脚本、图片）等等。

常用的构建工具主要是：jeknins、Travis、codeship等。

（4）测试（第二轮）

构建完成，就要进行第二轮测试。如果第一轮已经涵盖了所有测试内容，第二轮可以省略，当然，这时构建步骤也要移到第一轮测试前面。

第二轮是全面测试，单元测试和继承测试都会跑，有条件的话，也要做端对端测试。所有测试以自动化为主，少数无法自动化的测试用例，就要人工跑。

（5）部署

通过第二轮测试，当前代码就是一个可以直接部署的版本（artifact）。将这个版本的所有文件打包（tar filename.tar *）存档，发到生产服务器。

生产服务器将打包文件，解包成本地的一个目录，再讲运行路径的符号链接（symlink）指向这个目录，然后重新启动应用。

这方面的部署工具有Ansible、Chef、Puppet等。

（6）回滚

一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接，指向上一个版本的目录。

三、认识DevOps 

1、DevOps是什么？

DevOps 一词的来自于 Development（开发） 和 Operations（运维） 的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。

目前对 DevOps 有太多的说法和定义，不过它们都有一个共同的思想：“解决开发者与运维者之间曾经不可逾越的鸿沟，增强开发者与运维者之间的沟通和交流”。

DevOps可以用一个公式表示：文化观念的改变+自动化工具 = 不断适应快速变化的市场。

强调：DevOps是一个框架，是一种方法论，并不是一套工具，它包括一系列的基本原则和实践。 

DevOps的核心价值： 

2、为什么需要DevOps?

（1）产品迭代 

在现实工作中，往往都是用户不知道自己想要什么，但是当我们设计完一个产品后，他会告诉我们他们不需要什么，这样我们的产品需要反复的迭代，而且过程可能是曲折的，那我们有什么好办法快速的交付价值，灵活的响应变化呢？

答案就是DevOps，因为DevOps是面向业务目标，助力业务成功的最佳实践。

（2）技术革新

现在的IT技术架构随着系统的复杂化不断的革新，从最初所有服务在一个系统中，发展到现在的微服务架构、从纯手动操作到全自动流程、从单台物理机到云平台。

3、DevOps如何落地？

落实DevOps的指导思想 

高效的协作和沟通、自动化流程和工具、迅速敏捷的开发、持续交付和部署、不断学习和创新。

下面是一张来自 devops 经典著作《success with enterprise dev-ops whitepaper》的介绍图。

敏捷管理：一支训练有素的敏捷开发团队是成功实施DevOps的关键。

根据康威定律：软件团队开发的产品是对公司组织架构的反映。

持续交付部署：实现应用程序的自动化构建、部署、测试和发布。

通过技术工具，把传统的手工操作转变为自动化流程，这不仅有利于提高产品开发、运维部署的效率，还将减少人为因素引起的失误和事故，提早发现问题并及时地解决问题，这样也保证了产品的质量。下图展示了DevOps自动化的流程：

IT服务管理（ITSM），它是传统的“IT管理”转向为“IT服务”为主的一种模式，前者可能更关注具体服务器管理、网络管理和系统软件安装部署等工作；而后者更关注流程的规范化、标准化，明确定义各个流程的目标和范围、成本和效益、运营步骤、关键成功因素和绩效指标、有关人员的责权利，以及各个流程之间的关系等，比如建立线上事故解决流程、服务配置管理流程等； 

精益管理：建立一个流水线式的 IT 服务链，打通开发与运维的鸿沟，实现开发运维一体化的敏捷模式。

精益生产主要来源于丰田生产方式（TPS）的生产哲学，它以降低浪费、提升整体客户价值而闻名，它主要利用优化自动化流程来提高生产率、降低浪费。所以精益生产的精髓是即时制（JIT）和自动化（Jidoka）。

精益管理贯穿于整个DevOps阶段，它鼓励主动发现问题，不断的优化流程，从而达到持续交付、快速反馈、降低风险和保障质量的目的。

4、实施DevOps的具体方法

（1）建立快速敏捷的团队

按照业务功能划分团队，建立沟通群组，设置产品负责人（一个策划人员）、Scrum Master（我们一般选择测试人员担任，测试驱动开发模式）和开发者团队（前端工程师、后端工程师、测试各一名），形成如下的组织结构和系统构架：

 

（2）实现自动化的流程

直接看图说话吧，以下为一个完整DevOps的Pipeline：

（3）DevOps在落地实施过程中经常会遇到的问题

人手紧缺；跨部门协作，前期沟通培训成本高；前期投入工作量大见效少。

5、DevOps技术栈 

（1）敏捷管理工具 

Trello、Teambition、Worktile、Tower

（2）产品&质量管理 

confluence、禅道、Jira、Bugzila。

其中 confluence 和禅道主要是产品的需求、定义、依赖和推广等的全面管理工具；而 Jira 和 Bugzilla 是产品的质量管理和监控能力，包括测试用例、缺陷跟踪和质量监控等。

目前使用Jira 和 禅道较多。

（3）代码仓库管理

Git、Gitlab、Github.

Git是一个开源的分布式版本控制系统；

Gitlab 和 Github 是用于仓库管理系统的开源项目，它们使用Git作为代码管理工具，并在此基础上搭建起来的web服务。

（4）自动化构建脚本

Gradle、Maven、SBT、ANT

（5）虚拟机和容器化

VMware、VirtualBox、Vagrant、Docker

（6）持续集成(CI)&持续部署(CD)

Jenkins、Hudson、Travis CI、CircleCI。

Jenkins 是一个开源软件项目，是基于 Java 开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能，它的前身为Hudson。

Travis CI 是目前新兴的开源持续集成构建项目，它与 jenkins 很明显的区别在于采用 yaml 格式，简洁清新独树一帜。

CircleCI 是一个 web 应用开发者提供服务的持续集成平台，主要为开发团队提供测试，持续集成，以及代码部署等服务。

（7）自动化测试
（8）自动化运维工具

IT运维自动化是指将IT运维中日常的、大量的重复性工作自动化，把过去的手工执行转为自动化操作。自动化是IT运维工作的升华，IT运维自动化不单纯是一个维护过程，更是一个管理的提升过程，是IT运维的最高层次，也是未来的发展趋势。下图为常用自动化运维工具对比：

（9）监控管理工具