标签：构建 stage trigger 修改 一致性 tag 运行环境 部署 赋值
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
标签：构建 stage trigger 修改 一致性 tag 运行环境 部署 赋值
原文地址：http://www.cnblogs.com/elisun/p/7071536.html
