作者：王浩
背景
在 PingCode 我的项目启动之初，咱们采纳的是通过 Jenkins 来进行的公布治理，实现了下载代码、代码编译、部署等过程的自动化。
因为 PingCode 采纳的是微服务架构，在 Jenkins 上每个服务都会对应一条流水线，每个服务都能够独自部署，当开发有部署需要时，通过 Worktile 提交申请单，运维人员这边手动触发线上环境的部署。当服务数量不多，并且部署频率不高时，运维人员还是能应酬过去的。
然而当服务数量越来越多，部署频率越来越高后，就导致运维人员须要破费大量工夫来解决要部署的利用，每次公布的时候，为了可能跟踪每个申请单的状态，运维人员须要在 Worktile 部署申请单和 Jenkins 之间频繁切换，既消耗了大量工夫，又容易呈现谬误。
在这种状况下，咱们迫切需要构建一套部署申请和流程控制系统，首先开发人员提交申请，而后流转到运维人员，运维人员部署实现后，再次流转到开发人员进行确认，如果部署失败，能够再次流转到运维人员，再次执行部署，反复之前的流程，这样的话，运维人员就不须要记住每个服务的部署状态，也不须要再间接告诉相应开发人员，整个过程流程化，主动解决各个环节，会极大进步工作效率。
凑巧这个时候，咱们在调研运维平台，当在钻研蓝鲸时，发现它有一个流程服务的利用，看介绍，和咱们的需要很符合，于是决定通过它来实现咱们的流程治理。
实现
梳理需要
首先，须要先梳理咱们本人的公布场景。
流程服务外围性能
和内部服务交互
钻研发现，蓝鲸流程服务能够通过调用蓝鲸作业平台的执行计划或是调用内部 API 来和其它零碎交互，在咱们这个场景中，一方面要和 Jenkins 交互，触发流水线，另外一方面是要和 Worktile 交互，发送音讯到相应群组。
审批性能
流程节点中反对审批等性能，这样的话，一般开发人员提交申请后，流转到利用负责人进行审批，审批通过后，流转到运维人员这边，运维人员审批通过后，触发 Jenkins 流水线进行部署。
逻辑判断
在流程中，会有很多时候须要用到逻辑判断，比方 RC 部署胜利和失败的后续不同操作，胜利后，会持续部署线上，失败后，则再次流转动 RC 部署环节。
流程全景图
有了上边这些元素后，就能够开始设计流程了，以下是咱们团队应用的流程的全景图，看着很简单，是因为为了实现部署失败回到初始阶段重新部署等这些性能，减少了很多判断的逻辑。
最初
日常工作中会遇到很多重复性的工作，咱们团队会将其梳理，并做成相应的流程，或是自动化工具，帮忙咱们提高效率，能够抽出更多的工夫，对系统进行优化，从而使咱们的服务更加稳固高效。