昨天我們聊了第 1 代的 CI/CD Pipeline，今天讓我們繼續看下去。

首先，絕對要提的重要事件有兩個：

• 第一是 2008 GitHub 與 Bitbucket 出現。
• 第二是 2011-2012 出現的 CircleCI、Travis CI 與 GitLab CI

GitHub 的出現為何如此重要？大家應該都知道 GitHub 的別名吧？

（圖片擷取自 Google 搜尋。）

GitHub 可是一個跨時代的超級服務！它的出現我認為實現了幾個重要的事情：

1. 將 Git 與版控觀念推廣至全世界。
2. 世上多了一個能跨越地區的平台，串連起全世界的軟體工程師。
3. 同上，世上多了一個能跨越地區的平台，讓新的思維與觀念可以被互相影響與傳播。

Git 版本控制可說是實踐 CI/CD Pipeline 不可或缺的重要技術之一，也是實踐 CI/CD Pipeline 的第一步。因此 GitHub 與 Bitbucket，甚至是能夠自行架設的 GitLab，這些工具的出現，不只是滿足了實務上的工具需求，同時它們也是讓版本控制這項重要觀念與思維被廣為推廣的重要推手。

第二點的 CircleCI、Travis CI 與 GitLab CI，則是為 CI/CD Pipeline 的管理與使用帶來了一個新的境界——即是 Pipeline as Code。

原來我們可以同樣用類似寫程式的方式建立所需的 CI/CD Pipeline！

至此，我認為這時候出現了第 2 代的 CI/CD Pipeline！

什麼是第 2 代的 CI/CD Pipeline？

我覺得最關鍵的差異當然是 Pipeline as Code。也就是說，軟體工程師們再次捨棄了 GUI，改為用寫 Code 的方式定義 Pipeline。軟體工程師可以直接撰寫一個 YAML 檔案，在檔案中定義 Pipeline 的面貌，最後將 YAML 與應用程式的 Source Code 一起送入版控；接著 CI Service 會自動檢查 Git repository 是否含有此 YAML 檔案，並且自動根據檔案的內容，產生 Pipeline 及執行其中的 CI Job。

對軟體工程師而言，as Code 提供了一種更方便、快速的方式創建 Pipeline；也提供了一種新的工具整合方式，讓版控與自動化工具更直接無痛的整合在一起；並省去了一些設定自動化 Worker 所需的瑣碎操作。

as Code 讓 Pipeline 本身能被版控所管理與保護，並且 as Code 也代表未來 Pipeline 本身有機會可以被更吻合軟體工程的方式管理、使用與重構。

但其實在第二代剛出來時，雖然它是一種 as Code，可是離真正的 Code 還有一段距離，能做的彈性與變化也很有限，真正讓 Pipeline as Code 能發揮威力，我覺得要等到下一波的技術演進，這部分內容就留到明天我們再來繼續聊嘍～

無論如何 Pipeline as Code 確實是一項創舉，也是一種示範，讓世界上更多人發現「原來將某些東西 as Code 的話，似乎可以帶來一些意想不到的好處！」

今天 DevOps 輕鬆聊，就聊到這裡啦，想知道更多 CI/CD Pipeline 的演變，就請抖內、按讚、訂閱、開啟小鈴鐺嘍～（謎之音：抖內與小鈴鐺在哪？）