基于蓝鲸流程服务实现发布管理

作者：王浩

背景

在 PingCode 项目启动之初，我们采用的是通过 Jenkins 来进行的发布管理，实现了下载代码、代码编译、部署等过程的自动化。

由于 PingCode 采用的是微服务架构，在 Jenkins 上每个服务都会对应一条流水线，每个服务都可以单独部署，当开发有部署需求时，通过 Worktile 提交申请单，运维人员这边手动触发线上环境的部署。当服务数量不多，并且部署频率不高时，运维人员还是能应付过来的。

但是当服务数量越来越多，部署频率越来越高后，就导致运维人员需要花费大量时间来处理要部署的应用，每次发布的时候，为了能够跟踪每个申请单的状态，运维人员需要在 Worktile 部署申请单和 Jenkins 之间频繁切换，既耗费了大量时间，又容易出现错误。

在这种情况下，我们迫切需要构建一套部署申请和流程控制系统，首先开发人员提交申请，然后流转到运维人员，运维人员部署完成后，再次流转到开发人员进行确认，如果部署失败，可以再次流转到运维人员，再次执行部署，重复之前的流程，这样的话，运维人员就不需要记住每个服务的部署状态，也不需要再直接通知相应开发人员，整个过程流程化，自动处理各个环节，会极大提高工作效率。

恰巧这个时候，我们在调研运维平台，当在研究蓝鲸时，发现它有一个流程服务的应用，看介绍，和我们的需求很契合，于是决定通过它来实现我们的流程管理。

实现

梳理需求

首先，需要先梳理我们自己的发布场景。

流程服务核心功能

和外部服务交互

研究发现，蓝鲸流程服务可以通过调用蓝鲸作业平台的执行方案或是调用外部 API 来和其它系统交互，在我们这个场景中，一方面要和 Jenkins 交互，触发流水线，另外一方面是要和 Worktile 交互，发送消息到相应群组。

审批功能

流程节点中支持审批等功能，这样的话，普通开发人员提交申请后，流转到应用负责人进行审批，审批通过后，流转到运维人员这边，运维人员审批通过后，触发 Jenkins 流水线进行部署。

逻辑判断

在流程中，会有很多时候需要用到逻辑判断，比如 RC 部署成功和失败的后续不同操作，成功后，会继续部署线上，失败后，则再次流转动 RC 部署环节。

流程全景图

有了上边这些元素后，就可以开始设计流程了，以下是我们团队使用的流程的全景图，看着很复杂，是因为为了实现部署失败回到初始阶段重新部署等这些功能，增加了很多判断的逻辑。

最后

日常工作中会遇到很多重复性的工作，我们团队会将其梳理，并做成相应的流程，或是自动化工具，帮助我们提高效率，可以抽出更多的时间，对系统进行优化，从而使我们的服务更加稳定高效。