传统 CI/CD 处理的问题
说到 CI/CD 的工具，IT 圈内名声最响亮的可能就会是传统的老牌 CI/CD 的王者之一：Jenkins。说到它基本上 IT 人都知道。在曾经云计算时代，乃至更久远的时代，因为那个时候软件架构还没有拆分成微服务，很多都是主机部署。所以 Jenkins 靠着一套 Pipeline 和自由风格流水线，打遍天下无敌手。
Jenkins 之所以能够这么纵横宇内有很大的一部分原因就是：开放，CI/CD，使用简单，能够走完一整套交付流程。
开放：意味着有着开放包容的api和插件，能够面临各种场合。
CI/CD：意味着能够完整的走完一整套交付，包含代码的拉取，制品的生成存储以及服务的部署。
但是随着技术的不断迭代，Jenkins 终将有一天不再适合新的环境。各位请继续往下看嘞。
云原生时代 CI/CD 面临的挑战
在云原生时代，万物皆可云原生。随着微服务的盛行，业务逻辑的服务拆分，容器化的兴起，编排容器逐步成为了业务主流规范。进入到这一阶段，新的挑战也就随之而来。例如：
- 以前服务少，Jenkins 能够一把梭哈，现在服务多起来了，每个服务都要一个Jenkins Job，尽管都是一样的逻辑，复制粘贴，但是数量多了也终将是一个麻烦事。如果十个，百个呢？
- 现在每个服务都要用 Jenkins 去做 CI/CD，那么我要封装很多的 pipeline，还有 Dockerfile，这种有规律的文件为什么不能抽象化，每次都要自己写。
- 每次使用都是通过 kubelet 加 shell 命令去做的构建部署，这样合理吗？
- 环境众多，开发、测试、预发、压测、生产，每个项目总有那么最少两三个环境吧，这个时候环境多了如何管理呢？
- 通过 K8s 的标准编排，很多服务配置文件都会以 ConfigMap，Secret 的形式存在，不同环境的配置都会不一致，那么如何去做统一管理呢？
- 研发人员的感知态如何做到？研发人员需要知道这个服务上了 K8s 是否启动成功，包含日志，事件信息，部署 Job 是否成功。这些能提供吗？
- 发版服务的时候，如何才能合理管理版本呢？
- 开发测试找你要环境，你该如何快速部署相应呢？
以上种种就是服务迁移 K8s 后所要面临的部分问题。Jenkins 很好，但是在新趋势的到来后，个人还是感觉心有力而力不足。
或许你会说可以使用 Jenkins+ArgoCD 来弥补相互之间的差距啊。但是我始终还是觉得，Jenkins+ArgoCD 并非是最理想的状态。
Jenkins+ArgoCD
Jenkins 可以做 CI，ArgoCD 可以做 CD，两者相辅相成，可以实现基本的 K8s 环境的 CI/CD。类似示例图如下：
两者结合固然是可以做到持续集成和持续发布的，但是我们还是要结合实际出发。我没有说不好，只是具体还要看使用场景和能够解决哪些问题。
现有很多 IT 公司都会有云资产，很多的正式环境都会放置在云端。这个时候就会有分歧——环境问题。
或许我开发测试使用本地机房，但是我云端因为是生产环境，会单独独立区分环境。那么按照环境区分原则，我会有 2 套环境，开发测试一套 Jenkins+ArgoCD，正式环境一套 Jenkins+ArgoCD。那么这个时候如果说公司对环境更为重视还会有预发，压测环境，那么又是一套 Jenkins+ArgoCD。好家伙，几套环境，上线一个服务都会在以上环境中乘以 3 的操作，直接带来的感觉就是：
- 效能降低
- 环境治理困难
- 服务配置文件难以管理
以上就是后续会面临的问题，还有一些问题就是，通过 Jenkins+ArgoCD 仅仅只能做到 CI/CD，更多的呢，能够做到吗？这里好像还要打一个问号。
为什么 Zadig 用的爽？
Zadig 就是专门用来做效能的一款开源 CI/CD 平台。我十分认可 Zadig 的使命：工程师是数字经济最重要的资产，Zadig 让工程师专注企业创新。他可以完美的解决我们迁移 K8s 后的一系列问题。如果加以规划和使用，可以用如下流程图来概括：
详细部署图如下：
通过一定的规划后可以实现 CI/CD 环境，一套主导所有。
这个时候可以算下成本，假设你环境之间是这样区分的：
其中正式环境 Jenkins 存在 slave 1 台，4核16G 云主机，包月：412元/月
其中压测，预发环境 Jenkins 存在 slave 1 台，4核16G 云主机，包月：412元/月
开发测试环境，4 个 slave ， 4 核 16G，本地机房虚拟机，共计消耗资源：16核，64G
如果统一了，那么降本增效不就出来了吗？
这个时候可能有人会说，小伙子是托儿，哈哈别急，让我慢慢道来。
Zadig 能解决企业数字化转型的什么难题？
现有主机环境问题？
很多企业在转型刚刚开始期间，或者说业务场景需要，会有部分业务存在容器部署。如果这个时候让你迁移，肯定不会一股脑的往 K8s 上塞，会慢慢的进行优化，这个时候 Zadig 支持主机环境的CI/CD，并且依靠 K8s 的弹性资源，能够根据需求创建 Job 执行构建部署任务，但是天下没有什么最好，只有更好，如果你微服务是多实例可能还真有点问题。那就是需要创建 2 个 Job。
弥补 Jenkins Job 单服务 2 任务的情况（一个构建打包，一个部署，通过 Git 修改协调（ArgoCD））
如果客官您使用的是 ArgoCD 那么我相信你肯定是基于 GitLab 去做的，Jenkins 肯定是在正式环境有 2 个 Job，一个负责构建上传镜像，另一个就是拉取 Git 仓库进行服务的更改。这个时候会显得很冗余，那么 Zadig 提供良好的构建部署的划分，只需要你运行工作流的时候轻轻点击是否构建即可。
提供完善的分支，PR 构建
好的 CI/CD 产品肯定是会对 Git PR 去做相关的适配的，Zadig 同样如此，能够在没有合并之前提前进行测试，无需完成合并。
环境复制，开发测试，提升效能
在微服务横行的今天，很多时候指不定那天就同时接了好几个需求去做，那么这个时候开发需要环境，测试需要环境，怎么保证环境不冲突呢？那就是给他们一个新环境，但是提供新环境需要投入人力成本进去，有没有什么办法快速构建一套环境出来开发测试，后续不使用的时候销毁？
以前可能有点麻烦，但是随着业务容器化加上 K8s 的弹性扩缩容，这个就很好实现了，只需要找到相应的镜像，YAML 更新到新的 Namespace 就可以了，但是这还是不够优雅。
Zadig 提供环境的全量复制操作，一键就是一个基准环境，配合 Istio 进行子环境测试，直接解放双手，原地起飞。
Istio 子环境参考：自测联调环境 | Zadig 文档 [1]
环境托管功能，一个工作流，一个构建发布所有托管环境
同项目，一直迭代，每个环节的服务都是一样的，为什么一定要区分开呢，通过相应的权限控制，一套构建，部署所有的服务不香吗？
环境配置（Ingress，ConfigMap，Secret）
项目中的配置等也有着较好的管理空间，可以直接抽象成为一个变量，每个环节的配置不同，但是引用的配置名相同，就可以实现环境之间的平滑迁移，比如：
- 上线中间件等连接依赖问题（ConfigMap + Service + Endpoint + CoreDNS）a. Service ExternalNameb. Service None + Endpoints
- 项目外部访问接口问题（Ingress）
- 中间件连接账号密码问题（Secret + env）
YAML，Dockerfile，Helm，服务构建模板管理
Zadig 有着良好的抽象能力，能够直接优化比较重复的动作，就比如 CI/CD 经常遇到的镜像 Dockerfile，YAML 等，通过抽象成为模板实现配置的统一和规范化管理。
YAML 模板化
Helm 模板化
这里偷懒没搞，其实我不太熟 Helm
Dockerfile 模板化
构建配置模板化
我个人提供两种思路：
- 服务模板化：所有的服务配置一次构建，后续上线新的服务，构建镜像的时候直接引用模板
- 语言模板化：按照语言区分进行构建模板的抽象，构建模板主要信息如下：a. 构建产物所需要的应用，比如：Go，Java，NodeJSb. 构建产物所需要配置的命令
Harbor 整合，配合正式环境的发布
可以通过对 Harbor 的整合，实现不同环境的发布，就比如：正式环境只需要托管，无需配置其他的构建信息，工作流执行构建上传到指定的 Harbor，正式环境不需要打包更新，直接更换镜像制品。
版本管理（发版的 tag 交付物追踪）
每个服务的 tag 制品发版管理，出现问题可快速回退相应的版本。
研发人员感知态
开发人员启动发版工作流后，执行成功会有相关的 IM 推送，例如常见的：
- 企业微信
- 钉钉
- 飞书
部署逻辑这里，需要等待相关的探针就绪之后才会让工作流进入下一步。
拓展功能点
测试功能的原生接入
代码扫描的支持
自定义工作流，连接万物
如果前面还有没能够解决老板您的问题，可以尝试用自定义工作流，自己编码业务实现逻辑，然后通过自定义工作流实现。以下我就举一个 RDS 慢日志查询的例子。
如果说，正式环境使用了云上的数据库，以阿里云为例，查询慢日志。规范起见，开发人员是没有阿里云账号的，运维人员有，但是运维人员一般都会基于 RDS 做相关的慢 SQL 监控，如果有那么就需要去检索慢 SQL 条目。
一般这个时候会不断找运维同学提供，但是如果说可以通过一条工作流实现，那么运维同学的负担就会降低，可以去做更多的事情。
以上是我提供的一个思路，当然自定义工作流可以使用的场景可不仅仅是这样，还有更多的场景需要大家一起发掘，也希望大家能够不断的输入场景给 Zadig。
CI/CD 可观测性
CI/CD 可观测性也是很核心的一点，它可以让研发大佬清晰的知晓公司的研发效能如何，构建规律如何，测试情况如何。很多时候都能够从这里读出一些后续工作方向出来，Zadig 的这个概览也是我十分喜爱的一个点，毕竟是自己打下的江山不是吗？
总结
IT 领域的演变，就是运维人员通过不断向上接手开发人员眼中“跟开发无关的杂活”，来不断为开发人员减负。开发人员在得到了解放后，可以将视角更多的聚焦在自己开发的业务系统上，释放出自己的创造力。但是运维人员也要不断的优化现有的基础设施架构，以及构建简单易用的平台化工程来给开发人员使用。平台化工程或许是未来 CI/CD 的一个趋势和演进方向吧。
参考链接
[1] https://docs.koderover.com/zadig/v1.15.0/env/self-test-env/
作者介绍
我叫唐启涛。目前就职于广州某公司，哈哈，刚刚入职没有多久，然后岗位应该算是运维还是运维开发，我也不知道。因为我工牌是运维开发，但是我企业微信又是运维，不过这个不重要，以下是我作为一个“Zadig 过来人”带来的一些使用分享、以及方案选型对比，希望对后续大家公司的 CI/CD 优化有所帮助。
