CI/CD流程在CMDB模型中的设计与应用-技术圈

原文链接：https://www.jianshu.com/p/67ff73372db9

前言

我们知道，目前CMDB一般用于管理IT基础资源和应用相关资源，所管理的都是实体对象，如IDC、机柜、服务器、网络设备、IP地址、应用、集群、域名等等。当然，单纯的记录这些信息是没有多大意义的，我们的目标是要利用这些元数据来满足运维的业务场景，在此基础上实现例如持续部署、监控、变更、生命周期管理等各种操作和流程。而对于DevOps实践来说，持续集成和持续部署则是其最重要的流程。

在现有的各种CMDB方案中，很少有对流程进行深入讨论的。一方面是对于服务管理类流程已经有ITIL、ITSM等一套方法论来描述，所以不会着太多笔墨；另一方面对于持续集成和持续部署流程，有一种情况是直接被交给其他工具或平台来完成了，比如Jenkins pipeline，没有和CMDB紧密结合，所以也基本不需要讨论。

Jenkins Pipeline方案

目前一种比较流行的持续集成和部署方案是通过Jenkins的Pipeline来实现。Jenkins本质上是一个构建工具，它提供了非常多的插件，通过这些插件来执行像是拉取代码、编译、打包、邮件通知等操作，来完成构建任务。而Pipeline则能将这些操作组装成流水线，自动地完成从构建到部署整个流程。

看上去很美对不对？但是，这种方案有有一个很大的不足，就是无法很好地控制各个步骤的进行，而且也很难做到“一次构建、到处运行”。举个实际的例子，一个新版本部署的时候肯定是先部署到测试环境，测试没问题了才能部署到生产环境，那测试通过后如何部署到生产环境？是要重新构建吗？还是改jenkins脚本？所以说，想要把流控控制在手里就必须自己设计流程模型，自己实现流程。当然，流程中的具体步骤可交给专门的工具来做，但绝不能把整个流程拱手相让。

流程分析

在实际的运维场景中，我们需要知道这个流程进行到哪一步，是成功还是失败、如何增加审批功能等等，因此，我们需要将这个流程用模型把它描述出来，识别出它的每一个步骤，以及相应的状态变化，从而能够掌握并控制整个流程并在此基础上增加一些高级功能例如对整个持续集成、持续部署进行可视化。

首先我们来梳理一下这个过程：

上图描述了持续集成和部署的最简单流程。开发人员提交代码到代码仓库，触发构建工具进行构建（相比于普遍的自动触发做法，我觉得此处手动触发更实用），构建完成后，将应用包部署到测试环境，然后测试人员对版本进行测试，测试通过后，再部署到生产环境并验证。

模型设计

根据上面的梳理和分析，应将一个版本从构建到部署当做一次完整的流程，即同一版本的代码只构建一次，就能根据实际结果决定部署到测试或生产环境。

首先，每次提交代码都会产生一个版本，用Version（版本）模型来描述。

其次，将持续集成和部署过程抽象为一个广义的Deploy（部署）模型。Deploy模型继承自Version模型，与Version模型是一对一的系。Deploy模型用于管理Version的整个生命周期。

Version模型主要包含以下字段：

项目
版本号，指定的版本标识
包路径，该版本构建出来的制品的路径
版本修改说明
状态，描述该版本所处的环境/名字空间
其中状态有以下值：
开发，版本处于开发状态，默认值
测试，版本处于测试状态
挂起，版本发布到测试环境后，又有新版本发布到测试环境，那么该版本就处于挂起状态
中止，当有版本部署到生产环境时，处于挂起状态的老版本会变成中止状态。
上线，版本部署到生产环境后就处于上线状态
下线，上线的版本被新的版本上线代替后，变成下线状态

开发作为Version模型生命周期的开始，中止、上线及下线三个状态作为Version模型生命周期的结束。

Deploy模型主要包含以下字段：

步骤/阶段，当前版本的部署流程处哪个阶段
各阶段的时间戳
步骤/阶段有以下取值：

提测
构建
部署测试
测试
部署生产
验收

模型应用

有了上述模型，我们可以很容易获知：

某个项目/应用的所有版本状态
所有部署的当前进度
根据该模型的设计，实现的某个项目/应用实例的版本信息展示：

部署实例展示：

进一步，可以对研发工作效率和质量进行评估：

评估某个版本的需求效果。比如某个版本部署到测试环境后很久都不上线，那我们有理由怀疑这个新版本的需求是无用的。
通过分析Deploy每个阶段的时间戳，可以评估开发/测试人员的工作效率
对可能影响重大的步骤进行人工审批，比如部署生产环境的步骤。
分析所有未结束生命周期的Deploy实例（处于中止和挂起状态的实例）的数量，来评估开发人员的工作质量。
对持续集成和持续部署进行可视化，多少处于测试状态、多少处于挂起状态，一目了然。

总结

本文重点讨论了持续集成和持续部署流程在CMDB模型中的设计和应用，识别出了其中最重要的两个模型Version和Deploy，并详细定义了这两个模型的字段信息，特别是定义了Version模型的状态和Deploy模型的步骤/阶段两个重要字段。

该设计能够灵活地控制流程的各个步骤，并能准确地反映流程和状态之间的作用关系。最终，能够方便地将持续集成和持续部署流程进行可视化，将相关数据进行分析后还可用于评估研发人员工作质量和效率，甚至验证产品需求等。

- END -

 推荐阅读 

31天拿下K8S含金量最高的CKA+CKS证书！ 
神器 Nginx 的学习手册 ( 建议收藏 )
运维必备的DevOps工具链大盘点
大规模微服务利器：eBPF 与 Kubernetes
互联网公司使用 Redis 的16个应用场景
Nginx配置中一个不起眼字符"/"的巨大作用，失之毫厘谬以千里
企业级日志系统 ELK 原理与实践详细介绍
编写 Dockerfile 最佳实践
运维工程师不得不看的经验教训和注意事项
终于搞懂了服务器为啥产生大量的TIME_WAIT！
Kubernetes 网络方案之炫酷的 Cilium
12年资深运维老司机的成长感悟
搭建一套完整的企业级 K8s 集群（v1.20，kubeadm方式）


点亮，服务器三年不宕机