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

成都创新互联-专业网站定制、快速模板网站建设、高性价比盈江网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式盈江网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖盈江地区。费用合理售后完善，10多年实体公司更值得信赖。

一、前言

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

二、从0到1构建DevOps

​1、背景介绍

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

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

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

• 第二件事是服务重构，将之前由PHP编写的程序用Java重构了80%以上，同时引入以SOA为核心框架的架构体系。

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

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

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

• 构建标准化的研发流程，使整个交付过程可靠和规范。

• 能一键生成可部署工程，一来是为了避免开发重复造轮子，缩短他们的开发周期，二来是统一技术栈，规范研发，降低维护成本。

• 打造自动化的CI/CD流水线，替代人工部署，大幅度提升交付效率。

• 建立线网故障快速回滚机制，给高速生产可能出现的差错提供应对措施，提升全站可用性。

​2、标准化的研发流程

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

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

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

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

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

• 新产品上线流程：新产品第一次上线使用该流程，涉及需求评审，产品原型评审，安全评审，技术方案评审等

• 产品大版本迭代上线流程：产品重大变更使用该流程，涉及需求评审，产品原型评审，安全评审，技术方案评审等

• 产品功能迭代上线流程：产品功能模块日常迭代使用该流程

• bug修复流程：修复bug快速上线使用该流程

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

​3、一键生成可部署工程

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

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

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

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

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

​4、CI/CD流水线

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

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

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

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

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

流水线具有如下功能：

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获取构建状态和结果，实时更新推送记录的状态和日志。

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

​5、线网故障快速回滚机制

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

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

• 在git上生成tag，代表此次的代码是稳定的，可以上线的；

• 保存了一条记录，代码版本和制品版本以及本次tag的记录。

现在我们看看这种情况：

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

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

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

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

1）带来的意义与价值：

• 研发过程标准化，责任制管理研发生产资料，交付过程更可靠；

• 提供多种工程模板，无需从零搭建工程，降低开发成本的同时，统一技术栈，规范代码研发；

• CI/CD自动化，支持高频构建(支持500+研发人员日常构建)，降低运维成本(运维同学从40人减少到10人)；

• 线网故障快速回滚，提升全站可用率。

2）不足之处：

• 流水线执行过程不够灵活，导致负载过高，耗费更多资源；

• 工程全生命周期管理缺失关键路径，大量工程处于散养状态；

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

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

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

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

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

​1、重构流水线

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

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

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

• 同步任务串行执行，若失败会阻断流程；

• 异步任务并行执行，若失败，不会阻断流程。

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

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

4）Jenkins slave节点容器化

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

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

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

• 流水线执行任务更加灵活，可按照实际情况动态调整执行任务，实现“因地制宜”；

• 提升了流水线执行任务的成功率，实现高可用；

• 通过k8s特性实现Jenkins slave节点动态扩缩容，满足高并发的同时，节约服务器资源。

​2、工程全生命周期管理

1）工程创建阶段

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

2）工程研发阶段

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

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

3）工程上线阶段

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

4）工程运行阶段

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

5）工程下线阶段

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

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

​3、整合基础服务和工具

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

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

​4、高效研发工作流

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

• 首先是自定义流程信息，填写工作流的一些简单信息；

• 然后是自定义表单内容，我们提供了大量丰富的表单组件，如文本框、单选框、复选框等；

• 最后是自定义扭转节点，可以设置每个节点的经办人，如果是系统执行，则会根据工作流类型执行对应的后台任务。

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

2）三步创建工作流

• 首先是选择工作流模版；

• 然后是填写表单，就是对应工作流设置的表单；

• 最后提交，即可完成工作流的创建。

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

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

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

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

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

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

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

​5、研发成本管理系统

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

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

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

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

• 流水线2.0丰富灵活的原子任务支持各种业务场景，在支持高并发、高可用的同时，不造成资源浪费；

• 对工程进行全生命周期管理，保证研发资料100%掌控；

• 一站式管理基础服务和工具，减少开发人员负担；

• 强大高效的工作流系统，极大提升研发效率；

• 成本管理系统，在记录每一个产品的研发费用的同时，严格管控研发成本。

四、结语

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

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

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

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

名称栏目：这才是DevOps演进及CI/CD实践的正确打开方式！
网页路径：http://www.mswzjz.com/qtweb/news26/180576.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联