这才是DevOps演进及CI/CD实践的正确打开方式！

发布时间：2025-11-05 09:24:25 来源：云智核 作者：应用开发

一、进及前言

从2016年底发布的实践式第一个版本到如今能够完全支撑猪八戒网500+研发人员的日常研发工作，DevOps团队经历了不断的确打试错和改进总结。本文侧重于解决方案，开方更多细节可以关注八戒技术团队公众号获取，进及希望对即将实践DevOps和正在实践DevOps的实践式团队有所帮助。

二、确打从0到1构建DevOps

2015年，进及历经10年步步为营，实践式稳定发展的确打猪八戒网厚积薄发，迎来了业务的开方快速增长，随之而来的进及就是公司人员的壮大，研发团队从几十人扩张到了几百人，实践式而正是确打人才的引入和业务增长的迫切需求，使得猪八戒网开始了一场轰轰烈烈的改革运动，而这样的运动，在过去的十年里已经搞了6次，因为公司的网站模板取经文化，我们将这样的运动称之为“腾云行动”。

而这次的腾云行动，我们主要做了两件事情：

第一件事是服务拆解，把庞大的单体应用根据业务划分，模块功能划分，拆解成一个个独立的小应用进行部署；

而这两件事情，将交付周期从之前的月，缩短至周，甚至为天。这无疑对我们的交付能力提出了严峻的考验。

于是，经过充分的调研和准备，以及慎重的决定，在2016年第三季度，研发团队抽调了部分运维人员和开发人员组建了devops团队，亿华云计算这个团队的目标只有一个，那就是满足频繁的交付，随时随地地交付。

而要实现这个目标，就必须要做到以下几点：

我们将猪八戒网的业务拆成了一条条业务线，现在将这些业务线抽象成一条条产品线，然后产品线下面有子产品线，免费源码下载子产品线下面就是具体的产品，从而形成了一棵层次分明、业务清晰的产品树。

接着我们引入了产品责任制的概念，我们可以看到，每一个产品都包含了一些基本信息，这里需要注意的是，每一个产品都必须有一个产品经理，而产品经理也是有归属部门的，于是我们就得到了一条责任链，产品-产品经理-归属部门。

然后，我们又引入了工程责任制概念，同理，我们每个工程也包含了一些信息，如源码地址、开发语言、运维配置信息，以及我们的工程负责人，每个工程负责人也有归属部门，这样我们也得到了一条责任链，工程-工程负责人-归属部门。

我们现在将产品与工程关联起来，并规定每一个工程必须关联一个产品，这样就保证了每一个产品都能找到实实在在的生产源码。

而做到这些还不够，我们还需要一个东西，把这些全部穿起来，于是我们使用jira构建了四种标准的需求发布流程：

现在有了产品树、产品责任制、工程责任制，以及需求发布流程，我们最后就建立了需求-产品-工程的标准研发生产线。

要做到这点，我们需要实现四个功能：

1）创建源码仓库：根据用户填写git祖名和工程名自动创建git仓库。

2）提供各种技术栈的工程模版：根据用户填写的开发语言提供对应的工程模版，并在创建git仓库后，完成初始化，提交到git仓库。

3）生成部署配置信息：根据用户填写的基本信息和系统预设配置动态生成流水线配置信息。

4）生成配置中心信息：生成各环境配置中心信息。

流水线做的其实总结起来就四件事：拉取源码，编译构建，将制品上传制品库，将制品部署到服务器。

而为了使这个过程可靠、可控以及规范，我们加入了校验任务，校验一些准入准出。

其次，再加入了测试任务，如自动化测试等。

然后就形成了这么一条流水线：

最后应用到各个环境后，便成为了以下的流水线：

流水线具有如下功能：

1）支持虚拟机容器两种发布方式

虚拟机发布，在完成编译构建之后，把生成的制品上传到文件服务器，这个文件服务器就相当于是虚拟机发布工程的制品库，文件服务器上保存了这个工程发布的历史制品版本，在上传到文件服务器后，接着会从文件服务器将制品同步到代码源，最后，虚拟机服务器上的守护进程会检测代码的代码是否发生变更，如果变更，便主动拉取代码，然后重启服务。

而容器发布，则会在编译构建完成之后，根据用户提供的dockerfile文件构建镜像，然后将镜像上传到公司内部的hub仓库，接着组装元数据，调用容器云接口，部署到k8s集群。这里的容器云是猪八戒网自己基于k8s做的二次封装，主要的功能，就是将元数据拿来处理生成deploy文件，然后调用k8s执行部署操作。

容器发布&虚拟机发布构建打包示意图

2）多分支开发，主干上线

在测试阶段，可以用各种分支进行开发测试，测试通过后，就必须合并到主干，然后用主干进行发布上线。

3）一次构建处处使用

考虑到设置的分支策略，于是我们规定，测试环境的制品只能用于测试环境使用，这样一来就需要在预发布再进行一次构建操作，而此次的制品因为是经过测试而合并到主干的代码生成的，所以认为是稳定可靠的，于是在后续的环境中，将不需要再次构建，而直接使用预发布生成的制品。

4）使用Jenkins作为后台构建作业机器

采用多master，多slave的Jenkins集群方案，其中master只做调度，slave执行确定任务，我们预先在jenkins master上创建了流水线对应的job，图中的左边是我们自研的流水线服务，用Java编写的，通过调用jenkins API触发构建，jenkins master调度slave节点执行job,然后左边的流水线服务定时调Jenkins API获取构建状态和结果，实时更新推送记录的状态和日志。

现在，我们将需求发布流程和流水线结合起来，就能得到下图所示的标准生产过程。

上面我们讲了流水线，现在来讲一下，如果上线出现了问题，如何进行回滚。不知道大家有没有注意到上图的一个细节，那就是在预发布的时候，有一个任务——打tag，而这个操作就是我们实现回滚的关键。

这个打tag主要做了两件事情：

现在我们看看这种情况：

比如现在我们发布了一次线上，发布的tag版本是v1.3.35，对应的代码版本是a，镜像是A，这次发布是成功的，没问题的。

然后我们又发布了一个版本到线上，v1.3.36,对应的版本是a，镜像是A，当发布到线上后，发现服务异常，于是需要进行回滚操作，选择上一次成功的版本v1.3.35,因为保存了这个版本对应的代码信息和镜像信息，所以当选择这个版本时就能找到这个正确的制品，然后触发一次流水线，就进行了回滚。整个过程可以控制到几十秒内，让线网故障导致的损失降到最低。

最后，我们看一下整个devops的生态链：

至此，我们的devops第一阶段完成。

1）带来的意义与价值：

2）不足之处：

基础服务和工具众多，需要多个平台间切换，增加开发人员负担；

没有高效自助执行的研发类工作流，大量实际工作需要人工处理；

缺乏成本管控手段，服务器成本居高不下。

三、从DevOps到一站式研发平台

我们针对以上不足做了以下改造：

1）把流水线的任务拆解成一个个独立的原子任务，并将原子人按功能划分为校验类和执行类。

2）根据工程的开发语言，发布方式，以及推送环境，预设了一套流水线任务列表。

可以看到，这里面有两种箭头，分别代码同步任务和异步任务：

3）自研了Jenkins rabbitMQ插件，实现流水线服务与Jenkins之间通过消息队列通信。

重构之前，前面讲到是通过调用Jenkins API的方式实现的，而重构之后，流水线服务组装好构建信息后将消息发布到队列里，jenkins 插件消费消息，然后调度slave执行任务，同时将状态和结果生成消息也发布到队列中，流水线服务消费消息更新日志和状态，这种方式极大地提升了成功率。

4）Jenkins slave节点容器化

重构之前，所有的slave节点都是虚拟机，这样就导致节点数量固定，要么造成资源浪费，要么无法满足高并发，而且维护成本较高，一旦涉及改动，需要人工更改每一个节点。

重构之后，我们利用k8s 插件，链接我们的k8s集群，创建slave节点。利用k8s特性，可动态调整节点数，既满足高并发，又不造成资源浪费，并且维护简单，一旦涉及改动，只需要重新构建slave镜像应用即可。

重构之后的流水线有如下特点：

1）工程创建阶段

定义六大工程类型，完全覆盖所有研发需求，且配置简单，一键创建。

2）工程研发阶段

根据工程类型生成配套组件，研发阶段全面赋能。

配套组件有工程权限管理、工程服务管理、工程资源管理、配置中心管理、调度任务管理、域名管理、安全管理等。

3）工程上线阶段

统一需求发布流程，cicd流水线标准生产，保证每一步的可靠性。

4）工程运行阶段

实时监控服务，多种维度的异常告警机制。

5）工程下线阶段

智能检测中心检测无用工程，360度检查工程依赖项，一键下线，操作简单。

由此我们实现了工程的全生命周期管理：

1）提供一站式查询和使用

2）提供各类工具使用文档

1）三步自定义工作流模版

有了工作流模版，我们就可以创建工作流了。

2）三步创建工作流

3）实时记录工作流状态和执行过程

当创建完一条工作流后，这条工作流所有的执行状态以及过程都会被清晰地记录下来，如图从发起到各个节点的扭转，以及执行结果、执行时间。

4）数十种系统自动执行节点任务

如果经办人是系统，那么就会根据当前工作流类型执行对应的系统任务，我们预置了几十种系统执行任务，基本覆盖了所有的研发需求，如数据库相关操作、运维相关操作。

5）实时通知经办人和进行催办

在扭转到某个节点的时候，我们通过系统通知和用户催办，尽可能地缩短工作流的办理时间。

至此我们得到高效扭转的研发工作流。

1）产品纬度统计各部门服务器成本费用。

前面我们提到，每一个工程都会关联到一个产品，而每个产品都有归属部门，由此我们便能更具产品纬度统计部门的服务器成本费用，当然，不仅是服务器成本费，也可以是其他费用，如代运维费，开发人员成本等，都可以照此计算。

2）监控每个部门的服务器成本是否超过预算，若超过预算则不允许发布上线。

至此，我们的devops第二阶段完成，总结一下成果和价值：

四、结语

DevOps实践之路还在继续，因为不同公司有不同的业务场景，而同一公司的业务也会随着时代的发展不断变化，只有适合自己的才是最好的，只有能拥抱变化的才是最好的，但万变不离其宗的，我觉得应该有以下几点：

1）DevOps应该是以提高研发效率为目标的实践，脱离了这个目标，做得再好也只是炫技。

2）DevOps应该是紧贴业务的，因为业务的不同，要求的技术架构也会有所不同，随之而来，要求的交付方式也会有所不同。

3）DevOps应该是以人为本的，我们应该尽可能地将一切繁琐的过程交给程序去执行，而人只需要“坐享其成”或者做少量的决策即可。​

相关文章