昨天談到了第 3 代的 CI/CD Pipeline，並且在最後拋了兩個提問給大家，不知道大家的想法是什麼？有任何想法，歡迎與我聊聊喔。

今天就讓我們對這連續多日的「從歷史看 CI/CD Pipeline」做一個收尾吧！

首先讓我們回顧一下每一代的 CI/CD Pipeline

• 第 1 代：地端 VM 為主，使用操作上較為煩瑣的 GUI 建構 Pipeline。
• 第 2 代：依然以 VM 為主，開始運用 Cloud 資源，Pipeline as Code 初出茅廬，可以用 Code 建構 Pipeline。
• 第 2.5 代：VM 為輔，運用 Container + Cloud 資源，將 Pipeline 中合適的工作遷移至 Container 與 Cloud 處理。另外，也出現了方便且不煩瑣的 GUI 工具能協助建構 Pipeline。
• 第 3 代：原生擁抱 Cloud Native 的 Pipeline。

如果仔細探究，其實上面每一代的分類並不嚴謹，筆者在這個系列主要想傳達的一項重點是——思維及技術演進之間的相互影響。

相信大家都聽過類似上圖的江湖傳言——「程式與架構是持續演化來的。」

那麼作為貫穿軟體開發、交付、部署及維運的 CI/CD Pipeline，難道不也是在「持續演化」嗎？

當然，我們都知道有時候「老東西」並不是這麼容易改變，而且「老東西」也不一定需要改變。

可是別忘了大環境的持續演化與改善，是不等人的。

以第 2.5 代 CI/CD Pipeline 為例，筆者自己在私下的場合詢問，收集到的數據是大部分的團隊都還在 2.5 代；但在 DevOpsDays Taipei 2022 演講時收集到的公開數據，反倒是第 3 代的數量最多。

（筆者在 DevOpsDays Taipei 2022 演講現場收集的數據。）

這結果其實有些跌破我的眼鏡，因為我自己原本的推測是作為過渡期的 2.5 代，應該會是最多人卡住的現況；只有新產品、新團隊才比較有機會直接擁抱的第 3 代，應該會是第二多的才對。
（當然也有可能筆者自己私下調查的對象同值性太高，所以才會有上述的想法。）

因此從上面的調查結果來看，是否我們可以說，隨著這幾年 Cloud、Container、K8s 的普及，它們能帶來的優勢實在過於吸引人，已經吸引了夠多的企業與團隊採用這些技術。

（在 2016 年，我們已經在感嘆 Container 會帶來巨大的改變，到了 2022 年，同樣的感嘆依然是持續進行中。）

最後，讓我們回到昨天的那兩個提問吧！

1. 在目前的當下，你的團隊或組織如果要實踐 GitOps，會遇到的難題是？
2. GitOps 解決了什麼問題？這些問題是「新的問題」？還是原來「既有的問題」？

不曉得你有想到哪些答案呢？筆者這裡就提供幾個想法。

首先是難題，在我個人的看法當中，我認爲 GitOps（特別聲明這裡指的是 CNCF 那一派人們提倡的 GitOps）也是一種第 3 代的 Pipeline。因此這個難題其實就跟從第 2.5 代要遷移至第 3 代是雷同的。

• 你的團隊（Dev、Ops、Infra）是否具備 Cloud Native 的相關能力？
• 你的應用程式及 infrastructure 架構是否能夠擁抱 Cloud Native？

第二點，我覺得 GitOps 解決的是「既有的問題」，GitOps 為我們展現了，在仰賴 K8s 生態系的狀況下，該生態系能為我們帶來的一種更標準化與具備一致性的工作流程。而它所解決的一樣是軟體開發、交付、部署與維運的議題；Dev 端可以用更一致的方式交付程式，而 Ops 端可以用更一致的方式部署及維運程式，甚至是 Infra 端也能用更一致的方式提供 infrastructure 以便支撐讓程式能正常運作提供服務。
（當然如果你要仔細切分，你也可以說 GitOps 解決的是新的問題啦，畢竟 K8s 生態系本身就是一個巨大的新問題啦）

最後，從這幾篇「從歷史看CI/CD Pipeline」一路看來，我還是想套用那句「全是廢話」。在理解了各時代的時空背景之後，你不覺得這一切都是一種必然的演進與持續改善嗎？只不過在進展到第 3 代時，這次的進化劇烈了些，但說是劇烈，其實 Cloud 與 Container 也發展超過 10 年了，包含 Twelve-Factor App methodology 也超過 10 年了，所以我們並不是在一夜之間遭遇劇變，是有時間跟著時代持續演進的。

最後的最後，讓我再問一個提問做收尾吧！

你覺得 CI/CD Pipeline 是公司請一位 DevOps 工程師就能搞定的東西嗎？

歡迎跟我分享你的想法喔！DevOps 輕鬆聊，我們明天見～（放晚安音樂～）