1.持续测试、持续集成、持续交付、持续部署和DevOps

什么是集成？

例子：

• 现在有一个电商平台需要开发
• 由于电商平台模块众多，需要不同的开发人员开发不同的模块【本地开发】
• 最后将所有人开发好的代码集成到一个系统中【提交代码到远程仓库】
• 集成完成后需要对其进行部署上线
• 随着时间的推移，该系统无论是 Bug 修复，还是新功能开发，后续都需要对系统进行不断的更新迭代
• 重点：所有人最终开发完才集成

持续集成 CI：

• 持续集成指的是，频繁地（一天多次）将所有开发者的代码集成到主干
• 简单理解：重复集成的工作
• 持续集成流程

1. 开发人员（10101）提交代码到 Source Repository （源代码仓库，如 Gitlab）
2. 有代码更新到代码仓库后，会通过 WebHook 触发 CI Server（持续集成服务器，如 Jenkins）的相关功能，执行编译-测试-输出结果的流程
3. CI Server 会将执行结果返回给开发人员注意

4. 这里的测试并不是常规的功能测试，而是针对代码的单元测试

持续集成的好处

快速发现错误

• 每完成一点更新，就集成到主干，相当于将一个复杂的模块细分成一个个小模块
• 每次小模块集成后再进行测试，可以快速发现错误，定位错误更加容易

节省人力成本，加快软件开发进度

• 如果 Build-Test 这种重复性工作需要人工执行将会耗费很多时间
• 现在交给 CI Server 自动化执行，节约了很多时间，从而投入到有价值的工作中去

控制开发流程，实时交付

• 细分的代码提交，可以更容易判断当前的开发进度
• 这让管理者更容易管控整个开发流程，从而保证产品实时交付

持续集成的核心

确保新增的代码能够与原有代码正确的集成

持续集成的目的

让产品可以快速迭代，同时还能保持高质量，简化工作流程

核心措施

• 代码集成到主干之前，先进行自动化单元测试
• 只要有单元测试失败，就不能集成
• 持续集成并不能完全的消除 Bug，而是让它们非常容易发现和改正

持续交付 CD

持续交付是一种软件工程方法，团队可以在短时间内生产软件，以确保可以随时可靠地发布软件，并且在发布软件时，可以手动进行发布。

简单理解

频繁地将软件的新版本，交付给测试质量团队或者用户，以供测试/评审。如果测试/评审通过，代码就进入生产阶段

持续交付的流程

持续交付的重点

• 持续集成的重点是代码，但持续交付的重点是可交付的产品
• 可交付的产品一定要有达标的质量，确保产品在生产环境没问题，所以在成功集成代码之后，还需要进行测试（TEST）

和持续交付的区别

• 持续交付：代码最终部署到生产环境的过程是手动的（Manual）
• 持续部署：代码最终部署到生产环境的过程是自动化的（Auto）

持续部署 CD(目前很少项目能实现)

持续部署的流程（

• 开发人员提交代码到编译、测试、部署的全流程都不需要人工干预，完全自动化执行

）

持续部署的不足

• 全流程自动化，无法保证质量，哪一步出问题了无法提前预知
• 目前一个产品正常发布到生产环境，还是需要测试工程师进行手工功能测试
• 所以持续交付更主流，因为它算半自动化

什么是Devops

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
通俗一点来讲，DevOps要求开发、测试、运维一体化，实现敏捷开发；DevOps从计划、编码、构建，测试、发布、部署，以及运营、监控打通，就是把敏捷开发部门和运维部门之间的围墙打通，形成闭环。

可以理解为devops是以持续集成为基础，衔接敏捷开发流程中的各个上下游环节形成的一套最佳实践。

持续集成中还有一个Pipeline流水线概念，简而言之，就是一套运行于Jenkins上的工作流框架，将原本独立运行于单个或者多个节点的任务连接起来，实现单个任务难以完成的复杂流程编排与可视化。

Jenkins FreeStyle or Pipeline Job

Jenkins 1 版本：freestyle project ： 构建一个自由风格的软件项目
Jenkins 2 版本：Pipeline： 流水线

FreeStyle Job（自由风格构建）:

　　1. 需要在页面添加模块配置项与参数完成配置

　　2. 每个Job仅能实现一个开发功能

　　3. 无法将配置代码化，不利于Job配置迁移与版本控制

　　4. 逻辑相对简单，无额外学习成本

Pipeline Job（流水线）：

　　1. 所有模块，参数配置都可以体现为一个Pipeline脚本

　　2. 可以定义多个Stage构建为一个Pipeline工作集

　　3. 所有配置代码化，方便Job配置迁移与版本控制

　　4. 需要Pipeline脚本语法基础，学习成本高

企业级持续集成技术栈

git + gitlab + jenkins + pipeline + maven + harbor + docker + k8s

网上自动化持续集成的资料很多，但基本上都是局限于jenkins自由风格的job，结合shell脚本来实现持续集成，这种方式的缺点也很明显：

1、构建出问题，排查困难

2、构建节点挂了，就不能完成构建任务

而当前主流技术是 “ k8s + 微服务 ” 等，我们完全可以利用k8s的优势来完成持续构建任务，每次构建时可以调度到任意节点，或者是具有指定标签的节点，这就实现了高可用，另外，结合pipeline，可以轻松简单实现持续集成，并且哪个阶段出问题了一目了然，排查起来也容易。

docker是静态slave，如果节点挂了，就不能用了，要重新手动选一个节点

k8s是动态slave

流程：开发提交代码到git仓库--》拉取代码（手动、触发）--》拉取代码后的静态代码扫描（SonarQube）可不做--》mvn打包--》构建镜像推送到harbor镜像仓库--》拉取新镜像发布到k8s（完成测试环境部署）--》拉取最新自动化测试代码--》自动化测试执行--》allure报告，同时，过程中会有钉钉、企业微信消息推送。

环境：jenkins使用k8s作为构建环境，在某个节点执行测试