GoCD中的概念
本页面解释了GoCD的一些基本概念。如果你想更多地了解持续集成和持续交付，可以参考Martin Fowler关于此主题的文章：持续集成和持续交付.
如果你对GoCD非常陌生，那么入门指南是一个很好的起点，在实际的GoCD实例上尝试的同时，可以更好地理解这些概念。
索引
任务
任务或构建任务是一个需要执行的动作。通常，它是一个单独的命令。
下图中显示的任务设置为运行命令ant -Dmodule=A compile，当由GoCD执行时。
工作
一个工作包含多个任务，每个任务将按顺序运行。如果一个工作中的任务失败，那么该工作被认为失败，除非另有说明，该工作中的其余任务将不会运行。
下图中显示的工作有三个任务。首先运行的是ant任务，然后是rake任务，最后运行的是shell脚本。
工作中的每个任务作为一个独立程序运行，因此，任务对其环境变量所做的更改不会影响后续任务。但是，任务在文件系统上所做的更改对后续任务可见。
阶段
一个阶段包含多个工作，每个工作可以独立运行。这意味着GoCD会并行化阶段中的工作执行。如果一个工作失败，那么该阶段被认为失败。然而，由于工作之间相互独立，阶段中的其他工作将继续运行至完成。
下图中显示的阶段有两个工作，一个构建模块A，另一个构建模块B。第一个工作的成功或失败不会影响第二个工作的成功或失败。
管道
一个管道包含多个阶段，每个阶段将按顺序运行。如果一个阶段失败，那么该管道被认为失败并且后续阶段将不会启动。
下图中显示的管道有三个阶段，第一个阶段有两个工作，第二个阶段有三个工作，第三个阶段有一个工作。如果第一个阶段失败，则第二和第三阶段将不会运行。
由于管道的图像可能变得相当大，本文档的其余部分将使用稍微较小的管道表示形式，隐藏工作和任务。这种表示形式如下所示。
材料和触发器
（或“这些任务、工作、阶段和管道什么时候运行？”） do these tasks, jobs, stages and pipelines run?”)
材料是导致管道运行的原因。通常是源代码材料存储库（Git、SVN、Mercurial等）。GoCD服务器连续轮询配置的材料，当发现新的更改或提交时，相应的管道会被运行或“触发”。
有不同的材料类型。以下是一个Git材料的例子。当向Git材料中配置的仓库提交时，管道被触发。
类似地，下面显示了一个SVN材料。GoCD支持多种不同类型的源代码材料，以及用于扩展其所支持材料类型的插件端点。
“计时器触发器”是一种特殊的材料，在指定的时间或间隔触发管道。
管道甚至可以配置为具有多种材料。下图中显示的管道配置了一个Git材料和一个SVN材料。当任一仓库有新的提交时，管道就会被触发。
管道依赖材料
当一个管道中的阶段用作另一个管道的材料时，材料真正开始变得强大。
在下图中，Pipeline 1的Stage 2被配置为Pipeline 2的材料。每当Pipeline 1的Stage 2成功完成时，Pipeline 2都会被触发。在这种设置中，Pipeline 1被称为上游管道，Pipeline 2被称为下游管道。Pipeline 1的Stage 2被称为Pipeline 2的上游依赖。
任何阶段都可以用作材料。在下图中，只要Pipeline 1的Stage 1成功完成，Pipeline 2就会触发并开始。现在，Pipeline 1的Stage 2和Pipeline 2的Stage 1可以同时运行。
分散与聚合
当材料的完成导致多个下游管道触发时，称该材料“分散”到下游管道，如下图所示。引起分散的原因不必总是管道依赖材料。它可以是任何材料。
“扇入”是指需要多个上游材料来触发下游管道，如下图所示。扇入的一个重要且有趣的方面是，GoCD将在触发下游管道之前确保上游管道的版本是一致的。
在下图中，这意味着如果管道1的第2阶段较慢，而管道2的第1阶段较快，则管道3将在触发之前等待管道1完成。即使管道2快速完成，它也不会使用不一致或旧版本的管道1进行触发。
价值流图 (VSM)
价值流图 (VSM) 是管道的端到端视图，包括其上游依赖项和触发的下游管道。在决定触发哪些管道时，GoCD 的扇入和扇出解析将始终处理所有依赖项。
例如，在下图中，当在存储库1（git）中检测到新提交时，GoCD不会立即触发管道5。它将等待管道1成功触发并完成，然后等待管道4成功触发并完成。最后，它将使用与管道1相同的存储库1修订版触发管道5。
构建产物
每个作业Go 中的任务可以可选地发布“制品”，这些是文件或目录。任务运行后，GoCD 将确保指定的制品被发布并提供给用户以及其它下游阶段和管道使用。
制品的表示如图所示。如图所示，每个任务都可以有制品。在这种情况下，顶部的任务有两个文件和一个目录作为其制品，而下面的任务有两个目录和一个文件作为其制品。
获取构件
GoCD 提供了一种名为“获取制品任务”的特殊任务，允许从任何上游管道（即当前管道的上游管道）获取并使用制品。GoCD 将确保获取正确版本的制品，而不考虑系统中可能发生的其他情况。
在下图中，管道1的第1阶段中的任务发布了一些制品。在第2阶段，一个“获取制品任务”获取了第1阶段发布的制品。然后，在管道2中，“获取制品任务”获取了管道1发布的制品。最后，在更下游的管道3中，“获取制品任务”通过管道2从管道1获取了一个制品。
代理
（或“这些任务、作业、阶段和管道在哪里运行？”） do these tasks, jobs, stages and pipelines run?”)
GoCD 代理是 GoCD 生态系统中的工作者。系统中配置的所有任务都在 GoCD 代理上运行。GoCD 服务器会轮询材料的变化（这发生在 GoCD 服务器本身），然后，当检测到变化并且需要触发管道时，相应的作业会被分配给代理，以执行任务。
代理会拾取作业，执行任务并向 GoCD 服务器报告作业的状态。然后，GoCD 服务器将汇总来自不同作业的所有信息，并据此决定阶段的状态。
下图中用一个监视器来表示代理。
资源
代理和作业可以通过“资源”进行增强。资源是自由形式的标签，帮助 Go 决定哪些代理能够拾取特定的作业。
在下图中，Firefox® 和 Tux 图标代表了代理上的资源。这些资源可以被视为代理广播其能力的方式。资源由管理员定义，可以表示管理员希望它们表示的任何内容。在这个例子中，这可能表示该代理安装了 Firefox 用于运行功能测试，并且它是一个 Linux 系统。
当作业分配了资源时，资源变得非常有用。对于作业来说，资源可以被视为它们在代理中需要的能力，以便成功运行。
在下图中，Job 1 声明它需要具有 Firefox® 资源的代理。Job 2 声明它需要具有 Linux® 资源的代理。Job 3 声明它需要具有两者的 Firefox® 和 Linux® 资源。Job 4 声明它不需要任何资源。
对于上述图像中的情况：
-
Job 1 可以由 GoCD 服务器分配给代理1或代理3。
-
Job 2 只能分配给代理1（因为它是我们唯一提供 Linux 资源的代理）。
-
Job 3 只能分配给代理1（因为它是我们唯一提供两者资源的代理）。
-
Job 4 可以分配给任何三个代理，因为该作业不需要任何特殊资源匹配。
注意，代理3拥有 Apple® 资源这一事实并不会阻止它被分配作业。它只是一个作业显示中不需要的资源。
环境
在 GoCD 中，“环境”是一种将管道和代理分组和隔离的方式。环境的规则是：
-
一个管道最多可以关联到一个环境。
-
一个代理可以与多个环境关联，或者不与任何环境关联。
-
一个代理只能拾取与其关联的环境中所属管道的工作。
-
与环境关联的代理无法拾取未与任何环境关联的管道中的工作。
在下面表示环境的图像中，环境1由管道1、管道2、代理1、代理2和代理3组成。环境2由管道3、管道4、代理3和代理4组成。管道5、6和7以及代理5不属于任何环境。
在如上图所示的情况下：
-
管道1和2中的作业只能由代理1、2和3拾取。
-
管道3和4中的作业只能由代理3和4拾取。
-
管道5、6和7中的作业只能由代理5拾取。
除了与环境匹配相关的限制外，代理和作业之间的资源也需要匹配，详情见章节。资源.
环境变量
环境变量经常与“环境”混淆。它们不是直接相关的。在GoCD中，“环境变量”是用户在配置中定义的变量。这些环境变量就像操作系统中的其他环境变量一样被提供给任务。
环境变量可以在多个级别定义：在环境内、在管道内、在阶段内和在作业内。它们遵循一个级联系统，其中在“环境”级别定义的环境变量会被在管道级别定义的环境变量覆盖，依此类推。
在下图中，有4个环境变量在环境级别定义，3个在管道级别定义，每个阶段和作业级别各定义了2个。环境变量ENV_ENV在环境级别设置为1，ENV_STG在管道级别设置为2，依此类推。
提供给此作业中每个任务的环境变量将是：
ENV_ENV => 1
ENV_PIP => 2
ENV_STG => 3
ENV_JOB => 4
MY_VAR => 4
例如：ENV_PIP在环境级别设置（值为1）被ENV_PIP在管道级别设置（值为2）覆盖。由于ENV_PIP没有在阶段和作业级别定义，ENV_PIP的值将是2。其他环境变量也可以以相同方式推断。
模板
模板化有助于创建可重用的工作流，以便更轻松地完成创建和维护分支以及管理大量管道等任务。可以从Admin菜单的模板部分管理管道模板。
对此页面提出编辑建议