GoCD，一个开源的持续集成和持续交付系统。

诞生于2007年，但是目前很难搜索到中文资料，不知道是推广问题还是Jenkins已经足够强大！

笔者的一个产品线上使用了GoCD,有幸见识到如此一个简洁漂亮的软件，所以了解部署了一下，所有图片和概念均来自官网，如理解有误，请不吝指正。

架构简介：

Server and Agents

- Server负责控制一切（配置），轮询材料（如代码仓库）的变化，检测到材料变化需要触发Pipeline（流水线）时，将任务分配给Agent去执行

- Agent负责执行Server分配的任务（运行命令、部署等），并将状态报告给Server，由Server整理信息判断该任务的最终结果

- 每个部署业务的机器上都必须安装agent

 概念:

 1. Task（任务）

- 通常是一个单独的命令，如执行一个系统命令cat，ant构建等

2. Job（作业）

- 由多个Tasks(任务)组成

- Task执行方式为顺序执行，Task之间是相互独立的，即修改的环境变量不会影响到其它Task

- 一个Task失败，则该Job失败，除非另有说明，否则其余Task将不会运行

3. Stage（阶段）　　

- 由多个Jobs（作业）组成

- Job执行方式为并行，由于Job之间是相互独立的，某个Job失败后，其它的Job会被运行到完成

- 一个Job失败，则该Stage失败

4. Pipeline(流水线)

- 由多个Stages（阶段）组合而成

- Stage执行方式为顺序执行，一个Stage失败，将不会执行后续Stage

- 一个Stage失败，则该Pipeline失败

下面两张图分别为完整图和精简图

5. Materials and triggers(材料和触发)

- 使用Git、SVN等材料时，GoCD可以轮询检测资源变更，以触发Pipeline，也可以手动触发

- Pipeline可以有多个材料，任何一个材料变更都可以触发Pipeline

6. Pipeline dependency material (Pipeline依赖材料)

- Pipeline和Pipeline之间可以产生依赖关系，例如当Pipeline1完成之后触发Pipeline2

- Pipeline和Pipeline之间也可以通过上游Pipeline中的某个Stage完成后，触发下游Pipeline执行

7. Resources（资源）

- 资源是我们打在Agent的标签,以表示哪些Agent能运行这个Job

如图，我们运行一个需要Firefox资源的Job，那么只有Agent1和Agent3满足，如何知道Agent1和Agent3上有Firefox？在这两个Agent上打上标签"Firefox（or XXX）"

8. Environments（环境）

- GOCD中的“Environments”是对Pipeline和Agent进行分组和隔离的一种方式

如图，Pipeline1和Pipeline只能运行在Agent1、2、3上，而不能运行在Agent4和Agent5上，从而实现环境隔离

9. Environment Variables（环境变量） 

- 环境变量在各层级都可以配置，原则类似于全局变量和局部变量的概念，最底层的变量值会覆盖上层的变量值

注：此环境变量跟第8个概念Environment（环境）不要混淆，前者指a=1变量赋值，后者为运行环境

上图各变量的最终值为：

ENV_ENV => 1
ENV_PIP => 2
ENV_STG => 3
ENV_JOB => 4
MY_VAR => 4

10. Fan-out and fan-in(扇出和扇入)

Fan-out：

- 一个material（材料）的完成，触发下游多个Pipeline，该材料不一定是Pipeline依赖材料，可以是任何材料

Fan-in:

- 多个上游材料触发下游Pipeline，在触发下游Pipeline之前，GoCD将确保上游Pipeline的修订是一致的

如图，git触发Pipeline1和Pipeline2，而Pipeline1的Stage2的完成和Pipeline2的Stage1的完成是触发Pipeline3的条件，如果Pipeline2的Stage1的完成较快而Pipeline1的Stage2完成较慢，Pipeline会等待Pipeline1的Stage2的完成后被触发，以确保一致性。

11. Value Stream Map (价值流图)

- VSM是端到端的视图，详细描述了它的上下游依赖关系，在决定哪个Pipeline被触发时，GoCD的扇入扇出一直保持所有依赖关系

如图，当Repo1(git)中有新的提交时，GoCD不会立即触发Pipeline5，它将等待Pipeline1触发并成功完成，然后等待Pipeline4触发并成功完成，最后，

它将触发Pipeline5与Pipeline1使用相同的Repo1相同的修订版本。

12.  Artifacts（工件）

- GoCD中的工件是在Pipeline运行期间最常生产的文件或目录。Pipeline中的每个Job都可以配置发布自己的工件集，GoCD将确保这些工件从Agent端移动到Server端并存储在那里，以便随时检索。

- 通常，在Job运行期间，通过其中一个Job创建工件，由这些Job发布的工件可以被任何下游Pipeline或在同一Pipeline中产生该工件的Stage之后的任何阶段使用名称为

- 工件的一些示例为：测试报告、覆盖率报告、安装程序、文档、有关构建过程本身的元信息以及Pipeline完成后需要存储的其它任何内容。

"Fetch Artifact"的Task来获取和使用。

如图，第一个Job有两个文件和一个目录作为其工件，第二个Job一个文件和两个目录作为其工件。

如图，Pipeline1 Stage1中的Job会发布一些工件。在Stage2中，Fetch Artifact任务将获取在Stage1中发布的工件。然后，在Pipeline2中，Fetch Artifact Task将获取在Pipeline1中发布的工件。最后，在下游的Pipeline3中，Fetch Artifact Task通过Pipeline2获取来自Pipeline1的工件。

13. GoCD Server首页面貌

GoCD官网：https://www.gocd.org

GoCD概念篇