虽然我们经常说DevOps不仅仅是工具的组合，而是文化、实践和工具的结合，但是一个组织在进行DevOps实践的过程中对工具的选择是必不可少的一环。在如下图的纷繁复杂的DevOps工具中的首选必然是流程自动化工具。

工作流自动化是 DevOps 最基本的实践之一

相信大家都见到过下面这张体现DevOps本质的图，或者类似版本

回到DevOps本质上希望解决的问题（软件危机），即如下两条

1、如何更快更好的开发软件以满足日益增长的业务需求
2、如何维护不断膨胀的已有软件不出问题

解决以上问题的基本实践之一是将整个软件开发过程视为控制论中的反馈循环，不断迭代不断调整。当然，反馈原理也是现代管理的基本方法之一。由于整个反馈环都是为了一个共同的目的/目标，因此反馈在因果性和目的性之间建立了紧密的联系。反馈是否准确、快速，决定了管理是否有效。

因此，选择一个可以将软件开发各个过程串联起来并尽量实现自动化处理的流程工具则成为DevOps落地必不可少的前提条件。

什么是CI/CD/CO

当谈到DevOps中的流程，必然会提起CI/CD/CO等几个概念。这也是经常容易被混淆的几个概念，让我们来澄清一下。

持续集成（Continuous Integration）

持续集成概念的提出要在DevOps这个名词形成之前。经常有人会将持续集成中的“集成”理解成系统集成或集成测试的“集成”，其实持续集成指的是代码的集成。简单的说就是团队开发时，定期合并代码并保证代码的质量。

至于如何保证代码的质量，从最基本的每日构建(Daily build)到自动触发的单元测试、集成测试等手段不一而足。

持续交付/持续部署（Continuous Delivery/Continuous Deployment）

持续部署和持续交付的缩写都是CD。部署是一个Ops（运维领域）的技术操作，本质上就是将软件制品安装到不同的环境中，如测试环境、生产环境等。持续部署则是用自动化手段将部署过程简化，让部署可以随时进行，从而降低部署带来的风险。

持续交付中的交付来自于敏捷/精益思想，完善的DevOp团队持续交付的是用户价值。持续集成/部署都是为了完成价值交付而使用的技术手段。至于什么是价值，如何清晰的定义价值，已经超出了本文的范围。

持续运营（Continuous Operation）

从以上CI/CD的演变过程可以看出，DevOps的概念与范围在不断的外延。当DevOps的理念被延伸到更高层次的业务领域时，持续运营的概念应运而生。持续运营可以理解成是持续交付概念的具体落地，将研发团队之外的业务运营指标与研发流程联动，打造真正的价值流。

流程的类型

回到我们的主题，让我们回顾一下DevOps领域中的流程编排工具是如何发展和进化的。根据编排的方式不同，当前DevOps流程编排领域的工具所提供的流程类型，基本上可以分为Pipeline、DAG、Workflow三种。

Pipeline管道/流水线

众所周知，DevOps的理论基础最初是来自于制造业的“精益制造”。因此，DevOps中的Pipeline可以直观的理解为工厂的生产流水线。下面是一个Gitlab CI的Pipeline的例子：

主流的CI工具如Jenkins/Gitlab CI等提供的编排方式基本相同，都是以Stage为一级单位，Stage内包含的Job或Step为二级单位。有的工具会在Stage一级提供除串行外的编排模式，而大部分工具都是在Job或Step一级提供并行/串行的任务编排模式。

结合我们上面讲的CI/CD理念，此类工具用Stage定义不同的CI/CD阶段（类似工厂的不同生产车间），每个Stage最终的制品将流向下一个Stage。

DAG有向无环图

虽然Pipeline的流程编排方式虽然非常贴近DevOps最初的基础理论，但是在更复杂场景下逐渐难以满足需求。因此越来越多的工具开始支持用DAG的形式来编排任务，如Gitlab CI在去年的版本中引入了needs关键字、CircleCI则是在Workflow模式下引入requires关键字来实现任务的互相依赖。用DAG的方式进行流程编排非常适合表现依赖关系的场景，如：代码编译时的上游依赖或者项目部署时的环境依赖等。下图为CircleCI的workflow（DAG）示例：

当然，DAG的另一个使用领域是大数据领域的任务编排，如Airflow等。另外，有向无环图的结构隐含了并发执行的语义，而不用显式的定义并发。

Workflow工作流

如果说DAG编排方式的流行是应对更复杂的CI/CD场景的话，那么当DevOps理念逐渐延伸到CO时，无论是Pipeline还是DAG都难以满足更加复杂的业务场景。当DevOps流程需要跟众多的外部业务系统一起协调编排时，更复杂的Workflow编排模式自然而然的被提上日程。

当我们提到业务领域的工作流时，大家首先想到的应该是BPMN标准，以及为数众多的BPM引擎，如：Activiti、Flowable、Camunda等，但是当我们回到DevOps领域时，我们会发现BPMN标准过于繁琐。我们需要的是一款简化的、领域特定的、自动化优先的、支持GitOps最佳实践的工作流编排工具。

因此，我们开发了建木来支持复杂的流程编排，示例如下图所示：

当然，建木也支持最简化的Pipeline模式。

如果Pipeline或DAG的流程编排模式已经满足不了您的组织/公司的需求，那么可以来试试建木提供的流程编排。

建木是一个面向DevOps领域的极易扩展的开源无代码(图形化)/低代码(GitOps)工具。可以帮助用户轻松编排各种DevOps流程并分发到不同平台执行。