Concourse 是一套 CI/CD 工具，由 Cloud Foundry 所開發。主要是因為 Cloud Foundry 在處理 CI/CD 問題時發現現有的工具無法解決他們的需求，因此開發 Concourse 這套 CI/CD 工具。

在 Concourse 中是以 Pipeline 為核心概念來設計的。這是因為 Cloud Foundary 在他們的開發流程上，面臨到的問題事經常需要部署到不同的環境以及生成給不同作業系統使用的檔案。

那麼 Cloud Foundry 為何不使用 Jenkins、 Tracis CI、GoCD 而設計 Concourse 呢？

Jeninks

在 Cloud Foundry 使用 Jenkins 時碰到了設定檔破碎化的情況，每一種設定都分散在 Jenkins 的 UI 裡面不同文字欄位中，而難以集中管理和維護。至於另一方面 Jenkins 對 Pipeline 的支援也並不是足夠完善的，即使大多數功能可以靠插件來解決，但是插件的相容性跟穩定性卻不是完全穩定的。

Tracis CI

在 Cloud Foundary 的使用中
，雖然Tracis CI 將設定檔都集中在 .travis.yml 中，解決了設定檔的破碎化問題。但是 Tracis CI 實際上是沒有 Pipeline 的功能，對一般的專案也許是沒有什麼問題，但是對 Cloud Foundary 的專案就不是這麼適合。

GoCD

而 GoCD 雖然作為跟 Jenkins 一樣是老牌的 CI/CD 工具，但是相對其他 CI/CD 工具卻是難以設定。而 Agent 的配置和佔用的資源也是相對上的多。

相對於上述的 CI/CD 工具，在 Concourse 針對下面的特性做了設計。

以 Pipeline 為核心設計

Concourse 是一套基於 Pipeline 所設計的 CI/CD 工具，一個專案就是由一個 Pipeline 所構成。不論是測試還是部署，所有的任務都可以透過定義 Pipeline 完成。

不使用插件

Concourse 並沒有插件的概念，但是卻保有著高度的可自訂性。對 Concourse 來說所謂的擴充性是透過 Resource 來達成的，基於 Resource 和 Job 的組合就可以做到各種多變的 CI/CD 配置。

單一設定檔

為了解決破碎化的問題，Concourse 和 Travis CI 一樣選擇了透過單一的設定檔來處理。但是不同的是 Concourse 是透過設定來產生類似程序化的功能，而不是單純的配置 CI/CD 動作而已。

最後，我們先來看看 Concourse 運作的樣子。

官方提供了一個非常簡潔的 UI 來呈現 Pipeline 的狀態，其中沒有深藍色的結點就是 Resource 而有顏色（綠色、紅色）的則是 Job。

下一篇文章會針對 Concourse 的基礎概念 Tasks / Resource / Job 來做討論。