DevOps流水线设计的最佳实践

谈到到DevOps，持续交付流水线是绕不开的一个话题，相对于其他实践，通过流水线来实现快速高质量的交付价值是相对能快速见效的，特别对于开发测试人员，能够获得实实在在的收益。很多文章介绍流水线，不管是jenkins,gitlab-ci, 流水线，还是drone， github action 流水线， 文章都很多，但是不管什么工具，流水线设计的思路是一致的。于此同时，在实践过程中，发现大家对流水像有些误区，不是一大堆流水线，就是一个流水线调一个超级复杂的脚本，各种硬编码和环境依赖，所以希望通过这篇文章能够给大家分享自己对于Pipeline流水线的设计心得体会。

概念#

1. 持续集成 （Continuous Integration，CI）

持续集成（CI）是在源代码变更后自动检测、拉取、构建和（在大多数情况下）进行单元测试的过程
对项目而言，持续集成（CI）的目标是确保开发人员新提交的变更是好的，不会发生break build; 并且最终的主干分支一直处于可发布的状态，
对于开发人员而言，要求他们必须频繁地向主干提交代码，相应也可以即时得到问题的反馈。实时获取到相关错误的信息，以便快速地定位与解决问题
显然这个过程可以大大地提高开发人员以及整个IT团队的工作效率，避免陷入好几天得不到好的“部署产出”，影响后续的测试和交付。

1. 持续交付 （Continuous Delivery，CD）

持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「预发布环境」（production-like environments）中。交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段 持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实时部署。
强调： 1、手动部署 2、有部署的能力，但不一定部署

1. 持续部署 （Continuous Deployment, CD）

代码通过评审之后，自动部署到生产环境中。持续部署是持续交付的最高阶段。
强调 1、持续部署是自动的 2、持续部署是持续交付的最高阶段 3、持续交付表示的是一种能力，持续部署则是一种方式

流水线的编排设计#

参考： Pipeline architecture | GitLab
这里非常推荐以版本控制系统为源的构建流水线设计，从每一位开发人员提交代码即可对当前提交代码进行检查编译构建，尽快将错误反馈给每位提交人员。

对于DevOps流水线，主要是由各类任务串联起来，而对于任务本身又分为两张类型，一种是自动化任务，一种是人工执行任务。具体如下：

1. 自动化任务：包括了代码静态检查，构建，打包，部署，单元测试，环境迁移，自定义脚本运行等。
2. 人工任务：人工任务主要包括了检查审核，打标签基线，组件包制作等类似工作。

而通常我们看到的流水线基本都由上述两类任务组合编排而成，一个流水线可以是完全自动化执行，也可以中间加入了人工干预节点，在人工干预处理后再继续朝下执行。比如流水线中到了测试部署完成后，可以到测试环境人工验证环节，只有人工验证通过再流转到迁移发布到生产环境动作任务。
DevOps流水线实际上和我们原来经常谈到的持续集成最佳实践是相当类似的，较大的一个差异点就在于引入了容器化技术来实现自动化部署和应用托管。至于在DevOps实践中，是否必须马上将项目切换到微服务架构框架模式，反而不是必须得。

在整个DevOps流水线中，我们实际上强调个一个关键点在于“一套Docker镜像文件+多套环境配置+多套构建版本标签”做法。以确保我们最终构建和测试通过的版本就是我们部署到生产环境的版本。
构建操作只有一次，而后面到测试环境，到UAT环境，到生产环境，都属于是镜像的环境迁移和部署。而不涉及到需要再次重新打包的问题。这个是持续集成，也是DevOps的基本要求。

流水线任务的标准化/原子化#

今天谈DevOps流水线编排，主要是对流水线编排本身的灵活性进一步思考。

• 构建操作：构建我们通常采用Maven进行自动化构建，构建完成输出一个或多个Jar包或War包。

注意常规方式下构建完执行进行部署操作，部署操作一般就是将构建的结果拷贝到我们的测试环境服务器，同时对初始化脚本进行启动等。而在DevOps下，该操作会变成两个操作，即一个打包，一个部署。打包是将构建完成的内容制作为镜像，部署是将镜像部署到具体的资源池和指定集群。

• 打包镜像操作：实际上即基于构建完成的部署包来生成镜像。该操作一般首先基于一个基础镜像文件基础上进行，在基础镜像文件上拷贝和写入具体的部署包文件，同时在启动相应的初始化脚本。

那么首先要考虑构建操作和打包操作如何松耦合开，打包操作简单来就是就是一个镜像制作，需要的是构建操作产生的输出。我们可以对其输出和需要拷贝的内容在构建的时候进行约定。而打包任务则是一个标准化的镜像制作任务，我们需要考虑的仅仅是基于
1）基于哪个基础镜像
2）中间件容器默认目录设置
3）初始化启动命令。
即在实际的打包任务设计的时候，我们不会指定具体的部署包和部署文件，这个完全由编排的时候由上游输入。

• 部署操作：部署操作相当更加简单，重点就是将镜像部署到哪个资源池，哪个集群节点，初始化的节点配置等。具体部署哪个镜像不要指定，而是由上游任务节点输入。

任务节点间松耦合设计的意义
这种松耦合设计才能够使流水线编排更加灵活。比如我们在进行了构建打包后，我们希望同时讲打包内容部署到开发环境和测试环境。那么则是打包动作完成后需要对接两个应用部署任务。这两个部署任务都依托上面的打包结果进行自动化部署，可以并行进行。
对于测试环境部署完成后，我们需要进行测试人员手工验证测试，如果测试通过，我们打标签后希望能够直接发布到UAT环境。而这种操作我们也希望在一个流水线来设计和完成。这样我们更加容易在持续集成看板上看到整个版本构建和迁移的完整过程。如果这是在一个大流水线里