GoCD 简介

本页解释了GoCD的一些基本概念。 如果你想了解更多关于持续集成和持续交付,一般来说,你可以参考Martin Fowler关于这个问题的文章:持续集成持续交付

如果您对GoCD非常陌生,那么在GoCD帮助页面上的入门指南是一个很好的起点,可以在尝试时理解这些概念 一个真正的GoCD实例。

Index

任务

任务或构建任务是需要执行的操作。 通常,这是一个单一的命令。

下图中显示的任务被设置为在由GoCD执行时运行命令ant -Dmodule = A compile

图 1: 任务
图 1: 任务

工作

工作由多个任务组成,每个任务将按顺序运行。如果作业中的任务失败,则认为作业失败,除非另行指定,否则作业中的其余任务将不会运行。

下图显示的工作有三项任务。 “ant”任务将首先运行,然后执行“rake”任务,最后运行shell脚本。

图 2: 工作
图 2: 工作

作业中的每个任务都是作为一个独立的程序来运行的,因此,任务对其任何环境变量所做的更改都不会影响后续任务。 后续任务可以看到文件系统任务所做的任何更改。

阶段

一个阶段由多个工作组成,每个工作可以独立于其他工作。这意味着GoCD可以并且在一个阶段并行执行工作。如果一个工作失败,那么这个阶段被认为是失败的。但是,由于工作是相互独立的,所以阶段中的其他工作将会完成。

下图所示的阶段有两个作业,一个是构建模块A,另一个是构建模块B.第一个作业的成功或失败不会影响第二个作业的成败。

图 3: 阶段
图 3: 阶段

管道

管道由多个阶段组成,每个阶段都将按顺序运行。如果一个阶段失败,那么管道将被认为失败,接下来的阶段将不会启动。

下图中显示的管道有三个阶段,第一个是两个作业,第二个是三个,第三个是一个。如果第一个阶段失败,那么第二个和第三个阶段将不会运行。

Figure 4: 流水线
Figure 4: 流水线

由于管道的图例可以变得非常大,因此本文的其余部分将使用稍微小一些的管道表示,这将隐藏作业和任务。这个表示如下所示。

Figure 5: Pipeline (small representation)
图 5: 流水线 (小图示)

材料和触发器 (or "这些任务、工作、阶段和管道何时运行?")

材料是管道运行的原因。通常,它是一个源代码存储库(Git、SVN、Mercurial等)。GoCD服务器不断地轮询配置的物料,当发现新的更改或提交时,相应的管道将运行或“触发”。

有不同种类的材料。这是一个Git材料的例子。当对在Git材料中配置的存储库进行提交时,管道将被触发。

Figure 6: Material - git
图 6: 材料 - git

同样,SVN材料如下所示。GoCD支持许多不同类型的源代码材料,以及一个插件端点来扩展它所支持的各种材料。

Figure 7: Material - SVN
图 7: 材料 - SVN

“定时器触发器”是一种特殊的材料,它可以在指定的时间或指定的时间间隔触发管道。

Figure 8: Timer trigger
图 8: 定时触发器

管道甚至可以配置多种材料。下面显示的管道配置了Git材料和SVN材料。当任何一个存储库有一个新提交时,管道就会被触发。

Figure 9: Multiple materials
图 9: 混合材料

管道依赖材料

当管道中的一个阶段被用作另一条管道的材料时,材料就开始变得强大起来。

在下图中,管道1的第2阶段被配置为管道2的材料。当管道1的第2阶段成功完成时,管道2触发。在这样的设置中,管道1被称为上游管道,管道2被称为下游管道。管道1的第2阶段被称为管道2的上游依赖性

Figure 10: Pipeline dependency - Last stage
图 10: 管道依赖-最后阶段

管道的任何阶段都可以用作材料。在下图中,当管道1的第1阶段成功完成时,管道2将触发并启动。现在,管道1的第2阶段和管道2的第1阶段都可以同时运行。

Figure 11: Pipeline dependency - Any stage
图 11: 管道依赖——任何阶段

扇出和扇入

一种材料被称为“扇出”到下游管道,当材料的完成导致多条下游管道触发时,如下图所示。一个扇出的原因并不一定是管道依赖的材料。它可以是任何材料。

Figure 12: Fan-out
图 12: 扇出

当需要多个上游材料来触发下游管道时,“扇入”是指,如下图所示。fan-in的一个重要且有趣的方面是,GoCD将确保上游管道的修订是一致的,然后才会触发下游管道。

在下图中,这意味着如果管道1的第2阶段是缓慢的,而管道2的第1阶段是快速的,管道3将等待管道1在触发之前完成。它不会触发与管道1的不一致或旧的修改,只是因为管道2很快完成了。

Figure 13: Fan-in
图 13: 扇入

价值流图(VSM)

价值流图(VSM)是一个管道的端到端视图,它的上游依赖关系和它触发的下游管道。在决定触发哪个管道时,GoCD的fan-in和fan-out解决方案将始终如一地处理所有依赖项。

例如,在下图中,当在Repo 1 (git)中发现新的提交时,GoCD将不会立即触发管道5。它将等待管道1启动并成功完成,然后等待管道4触发并成功完成。最后,它将触发管道5与管道1使用的Repo 1相同的修订。

Figure 14: VSM
图 14: VSM

工件

Go中的每一个(工作)都可以选择发布“工件”,即文件或目录。在运行作业之后,GoCD将确保已发布指定的工件,并向用户和其他下游阶段和管道提供。

下面显示了工件的表示。如图所示,每个作业都可以有工件。在这种情况下,顶部的作业有两个文件和一个目录作为其工件,下面的作业有两个目录和一个文件作为其工件。

Figure 15: Artifacts
图 15: 工件

抓取工件

GoCD提供了一种特殊的任务,称为“获取工件任务”,它允许从任何祖先管道中提取和使用工件,即当前管道上游的任何管道。GoCD将确保获取工件的正确版本,而不考虑系统中可能发生的任何其他事情。

在下图中,管道1的第1阶段的作业发布了一些工件。在阶段2中,Fetch工件任务获取在阶段1中发布的工件。然后,在管道2中,一个Fetch工件任务获取在管道1中发布的工件。最后,在更下游的管道3中,一个Fetch工件任务从管道1中获取一个工件,通过管道2。

Figure 16: Fetch Artifact Task
图 16: 抓取工件

代理 (or "这些任务、工作、阶段和管道在哪里运行?")

GoCD的代理商是GoCD生态系统的工人。系统中配置的所有任务都运行在GoCD代理上。GoCD服务器轮询物料的变化(这发生在GoCD服务器本身),然后,当检测到更改并需要触发管道时,相应的作业被分配给代理,以便他们执行任务。

代理选择分配给他们的工作(工作),在工作中执行任务,并向GoCD服务器报告工作状态。然后,GoCD服务器整理来自不同作业的所有信息,然后决定阶段的状态。

代理由下图中的监视器表示。

Figure 17: Agent
图 17: 代理

资源

代理和工作可以通过“资源”增强。资源是自由格式的标签,帮助决定哪些代理能够找到特定的工作。

在下图中,Firefox®图标表示代理上的资源。资源可以被认为是代理广播其功能。资源是由管理员定义的,可以表示管理员想要的任何东西。在这种情况下,这可能表明这个代理已经安装了用于运行功能测试的Firefox,并且它是一个Linux框。

Figure 18: Resources on an agent
图 18: 资源代理

当工作分配到资源时,资源变得非常有用。就工作而言,资源可以被认为是它们在代理中需要的功能,以便它们能够成功运行。

在下图中,Job 1声称它需要一个带有Firefox®的代理;资源。Job 2声称它需要一个具有Linux®的代理;工作3声称它需要一个有的代理;和Linux®资源。Job 4声称它不需要任何资源。

Figure 19: Agents, jobs and resources
图 19: 代理、工作和资源

如上图所示:

1.任务1可以由GoCD服务器分配给代理1或3。

2.作业2只能分配给代理1(因为它是提供Linux资源的唯一代理)。

3.作业3只能分配给代理1(因为它是提供这两种资源的唯一代理)。

4.工作4可以分配给任何三个代理,因为这个工作不需要特殊的资源匹配。

注意,代理3有一个Apple®资源并不能阻止它被分配工作。它恰好是一种资源,它不需要任何显示的工作。

环境

GoCD中的“环境”是一种对管道和代理进行分组和隔离的方法。环境的规则是:

1.管道可以与最大的一个环境相关联。

2.代理可以与多个环境或任何环境相关联。

3.代理只能在其关联的环境中提取属于管道的作业。

4.与环境相关联的代理不能在与任何环境无关的管道中获取作业。

在下图所示的环境中,环境1由管道1、管道2、代理1、代理2和代理3组成。环境2由管道3、管道4、代理3和代理4组成。管道5、6和7和代理5不属于任何环境。

Figure 20: Environments
图 20: 环境

如上图所示:

1.管道1和管道2中的作业只能由代理1、2和3获得。

2.管道3和管道4中的作业只能由代理3和4获得。

3.管道5、6和7中的作业只能被拾取。

除了与环境匹配相关的限制之外,资源还需要在代理和作业之间进行匹配,如资源小节中的详细内容。

环境变量

环境变量常常与“环境”混淆。他们没有直接关系。在GoCD中,“环境变量”是在配置中定义的用户定义变量。这些环境变量对于任务来说是可用的,就像在操作系统中运行的其他环境变量一样。

环境变量可以在多个级别上定义:在环境中、管道内、阶段内和工作中。它们遵循一个级联系统,在“环境”级别定义的环境变量被定义在管道级别上的环境变量覆盖。

在下图中,环境级别定义了4个环境变量,3个在管道级别,2个在阶段和工作级别。

环境变量ENV_ENV被设置为1在环境级别上的值,“ENV_STG”已经设置为2级,等等。

Figure 21: Environment Variables
图 21: 环境变量

这个工作的每个任务所提供的环境变量将是:

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。其他环境变量也可以用同样的方式进行推理。

模板

这一节正在进行中。

Image attributions

results matching ""

    No results matching ""