會選擇以 Concourse 作為主題，是因為筆者在使用 Jenkins 碰到許多困難。不過畢竟不是專精在 DevOps 領域的，對於 Jenkins 的 UI 以及 Plugin 的規劃難以理解，所以只好去尋求其他解決方案。

雖然 Gitlab CI 作為企業內部的解決方案是非常適合的，但是有一部份開源的專案在 Github 上，受到這一局限的關係在不選擇 Jenkins 並且能夠確保建置節點的穩定性，就必須要自行架設對應的伺服器才能處理。

就這方面而言，以 Concourse 來說其實是足夠優秀，並且可以對應問題的。

以筆者的公司來說，是一間開發 Rails 網站為主的公司，所以測試通常集中在針對網站的測試。也就常常需要有像是 PostgreSQL、Redis 等環境服務，就這方面 Travis CI 和 Gitlab CI 對測試提供「Service (服務)」的設定，可以獨立將這些資料庫和第三方服務分離開來讓專案的測試變得乾淨這一點，其實是有非常大的加分。

相對於老牌的 Jenkins 以及為了解決建置問題的 Concourse 兩者在處理這類型的問題就截然不同，若要測試 Rails 網站就只能選擇封裝一個有完整環境的 Docker Image 或者預先建置好一個內建環境的節點才行。

就這一層面上，其實相對於 Gitlab CI / Travis CI 是不方便的，但是若是在建置的 Pipeline 方面，其實並沒有任何不妥。透過集結各專案的原始碼，放到一個預先設計好的建置環境中，然後自動化的生成對應的執行檔和相關文件，最後再自動的發佈出去。

從這個角度來看，其實 CI 工具還是有區分偏向的性質以及適用的領域。雖然基礎的設計是相同的，透過不同的解決方案一樣能處理問題。不過對於像是網站類型的方案，利用 Gitlab CI / Travis CI 其實是相對容易配置的。不過這兩者也同時有著 Concourse 希望解決的問題，在建置軟體時因為有繁複的操作步驟和流程，建構 Pipeline 的設定集中在一個檔案是難以管理的問題。

就上述這些分析來看 Concourse 用來建置軟體、遊戲等比較能獨立運作的專案，會比網站專案還好用許多。

那麼，再來回顧一下 Concourse 的幾項功能。

資源

原始碼、網路服務等都被視為一個資源。我們透過 check in out 三個不同的動作，分別對「檢查更新」「取得資源」「修改資源」來做處理。

同時資源也是 Concourse 的拓展，任何額外的功能夠可以透過變化 check in out 的使用來實現，像是 time 資源的 check 用於檢查上一次時間跟目前時間的差距，就可以產生定時觸發的效果。

工作

工作是一連串的操作集合，從開始工作前要取得什麼資源。然後做什麼任務到結束後將生成的產物發佈出去，都是屬於工作的管轄範圍。

任務

在工作之下的就是任務，也就是明確定義一個工作該做什麼的細節。一般會指定執行這個任務需要的環境，以及「單一指令」也就是說雖然我們可以利用 sh 的特性放入多行指令。但實際上這個動作更像是執行某個指令做某件事情的動作。

也因次，一個工作中會有多個任務是很正常的。假設建置專案要執行三個步驟，比起將其集中在一個任務處理，實際上是更偏向分成三個任務單獨執行。

整個 Concourse 就圍繞在這三個概念中不斷延伸，而且這三個概念都是非常抽象而且獨立的。也因為這樣，我們可以用像是堆積木的方式組建出各種不同變化的流程。

最後，使用工具的還是人。能否將這個工具用適合和有趣的方式使用，還是由我們使用的人決定。