前言
我们知道，目前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模型主要包含以下字段：
模型应用
有了上述模型，我们可以很容易获知：
部署实例展示：
进一步，可以对研发工作效率和质量进行评估：
总结
本文重点讨论了持续集成和持续部署流程在CMDB模型中的设计和应用，识别出了其中最重要的两个模型Version和Deploy，并详细定义了这两个模型的字段信息，特别是定义了Version模型的状态和Deploy模型的步骤/阶段两个重要字段。
该设计能够灵活地控制流程的各个步骤，并能准确地反映流程和状态之间的作用关系。最终，能够方便地将持续集成和持续部署流程进行可视化，将相关数据进行分析后还可用于评估研发人员工作质量和效率，甚至验证产品需求等。
admin
