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概念篇