优维产品最佳实践：如何设计流水线？

前言：我们上期介绍了什么是CI以及CI的重要性，本期目标就是学习如何设计流水线，流水线是一种用于自动化软件开发和部署的工具链，它可以将软件开发过程中的各个步骤组织成一个连续的流程，从而提高开发效率和软件质量。在CI（持续集成）中，流水线是实现自动化软件交付的关键组成部分。

本期EasyOps产品使用最佳实践，我们将为您揭晓：

• 优维持续集成是如何设计流水线的？

「流 水 线 的 编 排 设 计」

这里EasyOps非常推荐以版本控制系统为源（如gitlab、gitee等）的构建流水线设计，从每一位开发人员提交代码即可对当前提交代码进行检查编译构建，尽快将错误反馈给每位提交人员。

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

1. 自动化任务：包括了代码静态检查，构建，打包，部署，单元测试，环境迁移，自定义脚本运行等。

2. 人工任务：人工任务主要包括了手工测试、检查审核等类似工作。

一个流水线可以是完全自动化执行，也可以中间加入了人工干预节点，在人工干预处理后再继续朝下执行。比如流水线中到了测试部署完成后，可以到测试环境人工验证环节，只有人工验证通过再流转到迁移发布到生产环境动作任务。整个流水线强调“一次构建，多次部署”，确保我们最终构建和测试通过的版本就是我们部署到生产环境的版本。构建操作只有一次，而后面到测试环境，到UAT环境，到生产环境，都属于是制品/镜像的环境迁移和部署。而不涉及到需要再次重新打包的问题。这个是持续集成，也是DevOps的基本要求。

「基 于 场 景 设 计 流 水 线」

是否需要一条完整的流水线？流水线是越多越好，还是越少越好？ 我们建议按照场景来设计，一条流水线通吃所有流程是不现实的，搞了好多流水线（比如一个构建就一个流水线，一个复制操作就一个流水线）这些都是不可取的，维护成本巨大，得不偿失。

流水线按照场景分类如下：

• 提交阶段流水线（个人级）

• 验收阶段流水线（团队级）

• 部署阶段流水线（部署/发布）

流水线任务按需串行、并行、特殊场景下跳过执行；必要环节人工干预，如在手工测试、正式发布等环节导入手工确认环节，流水线牵引流动。不同的流水线还可以串联起来组成CI/CD流水线。

「流 水 线 任 务 的 标 准 化」

流水线任务主要由以下三类操作组成：

• 构建操作：不同的编程语言有不同的构建方式：java通常使用maven；golang需要环境执行go build；python直接打包。总的来说，该步骤完成后输出一个或多个可执行的文件，我们在该步骤约定好制品的存放路径，方便下一步打包操作。

• 包镜像操作：实际上即基于构建完成的部署包来生成镜像。该操作一般首先基于一个基础镜像文件基础上进行，在基础镜像文件上拷贝和写入具体的部署包文件，同时在启动相应的初始化脚本。打包任务则是一个标准化的镜像制作任务，我们需要考虑的仅仅是基于 1）基于哪个基础镜像 2）中间件容器默认目录设置 3）初始化启动命令。即在实际的打包任务设计的时候，我们不会指定具体的部署包和部署文件，这个完全根据约定好的规则去获取。

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

在EasyDevOps中，常用任务都抽象成了插件，插件中心中现在有57个插件，分别实现代码拉取、静态检查、编译构建、代码测试等功能。如果用户现场有定制化开发需求，还支持自定义插件，用户可以自行开发插件。

例如Docker这一插件，EasyDevOps将常用的参数例如镜像名称、容器名称、端口映射、环境变量等抽离出来，方便用户在编排流水线时根据不同项目的实际情况传参。这样保证了：

• 定制化配置：每个项目可能需要不同的Docker配置，通过传参，用户可以根据项目的需要进行定制化配置，而无需修改固定的流水线模板。

• 灵活性：不同的项目可能需要不同的镜像、不同的环境变量等，通过传参可以使流水线具有更高的灵活性，适应各种需求。

• 重用性：通过参数传递的方式，可以使流水线模板更具有重用性。用户可以根据需要在不同项目中重复使用同一个流水线模板，只需要传递不同的参数即可。

• 减少错误：用户手动输入参数可能会引入错误，通过参数传递可以减少手动操作，降低错误发生的可能性。

• 一致性：将常用的参数抽离出来，并在流水线中进行传参，可以使项目团队在使用相同的参数上保持一致性，减少混淆和误解。

以上，就是本期所有内容，下一期我们将本期的知识运用起来，给一个实际代码项目编排流水线。