紐西蘭是我們的金絲雀：Octopus Deploy 老兵 Robert Erez 聊十年 CI/CD 的真心話

TL;DR

CI/CD 有四個成熟階段：YOLO 直接推 prod、持續整合（CI）、持續交付（continuous delivery）、持續部署（continuous deployment）。不是每家公司都該衝到最後一階，但前面的苦工不能省。
GitOps 名字裡有 Git，但它的四大支柱其實一條都沒提到 Git。把「所有東西都塞進 Git」當教條，反而會出事，最經典的就是有人想把密碼也放進去。
Kubernetes 不只是雲端的東西，很多公司拿它跑 on-prem，連零售店的收銀機、出海好幾個月的研究船上都在跑 K8s 叢集。
Rollback 是個陷阱。只要牽涉到資料庫 schema 變更，「回滾」這個安全網根本是假的。正確姿勢是 roll forward，搭配 feature toggle。
AI 大量產出程式碼之後，pipeline 的瓶頸會從「跑多快」轉向「怎麼降低風險」，feature toggle 會變成更重要的工具。

先認識一下這集的兩個人

這集在 2026 年 6 月 17 日上線的 The Pragmatic Engineer，是 Gergely Orosz 主持的工程師訪談節目，基本上是軟體工程圈的技術情報站，專門找在第一線打滾很久的人來拆解硬核工程問題。

這集的來賓 Robert Erez（節目裡大家叫他 Rob）是 Octopus Deploy 的 Principal Engineer，做 CI/CD 這個領域超過十年。有趣的是，他跟主持人在 2014、2015 年還是同事，一起在 Skype 做過 Outlook.com 的外掛，那個產品一個月有四億用戶。後來 Rob 回澳洲，十年前加入 Octopus Deploy，當時是第八、九號員工。Octopus Deploy 是一家 2011 年在澳洲布里斯本由 Paul Stovell 創立的部署自動化工具公司，專門幫團隊管軟體上線這件事，連 CEO 本人都是工程師出身。換句話說，Rob 不是在講理論，他是真的幫銀行、政府、甚至出海的研究船處理過部署這件髒活累活。

紐西蘭，世界上最稱職的金絲雀

先講一個我很喜歡的故事。

當年在 Skype，他們團隊維護的那個四億用戶外掛，照規矩每週只能上線一次，而且要跑去開一個叫 Change Advisory Board 的東西，拿到簽核才能推。Rob 說他一直覺得這件事很怪：程式碼是我們寫的，跑在 Azure 上，我們有完整權限隨時可以推，結果中間一週做好的東西都要硬憋著。

所以他們做了一件很工程師的事：偷偷繞過這個流程。程式碼準備好就建置、就推，而且推之前會先做一種 canary deployment，只放給一小部分用戶試水溫。他們挑的白老鼠是哪裡？紐西蘭。

理由很實際。紐西蘭是第一個跨進新日期的有規模國家，午夜一過，第一個進到隔天的就是它；他們講英文，出問題的 bug 回報看得懂；而且紐西蘭夠小，真的推出 bug 趕快修也沒人會太計較。Rob 在節目裡還特地跟紐西蘭聽眾道歉。

這個故事我覺得很有味道。很多現在大家朗朗上口的現代軟體實踐，其實早就被一群「只是想趕快把軟體推出去、受不了審核委員會拖時間」的工程師在野外跑過了。

CI/CD 到底是哪幾個 C？

很多人把 CI 跟 CD 講得好像可以互換，或乾脆黏成一個詞「CICD」。Rob 把它拆成四個成熟階段，我覺得這個分法很乾淨：

階段	在做什麼
YOLO	直接 SSH 進 prod 改檔案，我們都幹過
持續整合 CI	程式碼不斷合進同一條分支，持續跑測試
持續交付 Continuous Delivery	隨時按下按鈕就能上 prod，重點是把「部署流程本身」也測過
持續部署 Continuous Deployment	連按按鈕都不用，合併完自動上 prod

中間有個觀念很容易被忽略：持續交付測的不只是程式碼，是「部署流程本身」。你平常測 unit test、integration test，但部署這個動作有沒有被測過？持續交付就是要確保你任何時候按下去，它都能順順地到 production。

至於要不要衝到最後的持續部署，Rob 的態度很務實。工程師當然想程式碼一好就推出去，但這不適合每家公司。如果你在受高度監管的產業，上線時間、在場的人、合規要求都得對，那保留人工那一下按鈕是合理的。重點是前面那些苦工你都做了，風險都降到最低了，那「一週只能按一次按鈕上 prod」也完全 OK。這整套流程的核心精神就一句話：盡早感受到痛，把任何會出錯的東西在最後上線前就先排掉。

GitOps 最大的誤會，是那個 Git

這段是我這集學到最多的。

Rob 說 GitOps 這個詞是 Weaveworks 在 2017 年左右造出來的，後來在 2020 年代被歸納成四大支柱：第一，宣告式（declarative），你描述你要的狀態長什麼樣；第二，版本化且不可變（versioned and immutable）；第三，用拉的不是用推的（pull not push）；第四，持續調和（continuous reconciliation），有人手動改了叢集它會自己修回來。

然後他丟出一句讓我愣了一下的話：這四條，沒有任何一條真的提到 Git。

「版本化、不可變」這幾個字一出來，大家直覺反應就是「啊那不就是 Git」。但 Git 真的不可變嗎？你可以 rewrite history、可以改 tag。更關鍵的是，GitOps 社群裡永遠在吵一件事：密碼要放哪？沒有人會說放 Git（雖然真的有人搞出把密碼加密塞進 Git 的方案，Rob 說聽起來就是個爛主意）。這恰恰說明了，有些東西本來就不該進 Git，只要你能保證它有版本控制跟不可變就夠了。

Rob 的判斷很接地氣：很多人去研討會聽到「GitOps 是你該做的事」，回來就把它當成唯一解，看什麼都像釘子。但你部署前後常常還要跑 smoke test、發通知、做資料庫更新，這些步驟根本不適合塞進「所有東西都宣告在 Git 裡」的模型。大部分客戶要的其實只是把軟體推出去，他們不在乎你叫它什麼名字。GitOps 能端到端搞定就用，搭配一些比較命令式的步驟更順手就那樣搭，沒有那麼多教條。

Kubernetes 跑在收銀機跟研究船上

Kubernetes 是當下的平台王者，這個沒什麼好爭的。它從 Google 內部的 Borg 演化出來，當年跟 Nomad、Docker Swarm、CoreOS 的 fleet 一票對手廝殺，最後勝出。Rob 跟主持人都認同一個說法：Google 把它開源，某種程度是為了拉平自己跟 AWS 的差距，因為有了 K8s，工作負載要在雲端之間搬就容易多了，選 Google Cloud 或 Azure 不再是高風險的決定。

但真正讓我意外的是 on-prem 的部分。大家整天講 Kubernetes 是 cloud native，可是 Octopus 很多客戶其實是拿它跑自己機房的。金融業特別常見，因為他們要對整套基礎設施有端到端的控制權。

Rob 舉的兩個例子很有畫面：有客戶在幾百家門市的收銀系統（POS）裡各跑一個小小的獨立 K8s 叢集，數量一上千、又走 GitOps 從 Git repo 拉狀態，結果 Git repo 本身變成瓶頸、開始被限流。另一個更狂，有客戶把 K8s 叢集裝在出海的研究船上，船一出去可能好幾週甚至幾個月，要更新只能等船回港再抓。這種「冷板凳上的邊緣運算」遇到的問題，跟你在雲端遇到的完全是兩個世界。

Platform team：別再讓工程師抽籤搞 Jenkins

接著聊到平台團隊（platform team）的崛起。Rob 把脈絡講得很清楚。

以前是 dev 跟 ops 分家，寫完程式往牆那邊一丟。後來 DevOps 興起，大家發現讓工程團隊參與營運、自己痛自己修，回饋迴路更快。但規模一大又出問題：每個應用團隊各搞各的部署方式，全都從頭刻一遍，工程師被迫變成各種雲端工具的專家。

主持人講了一段我超有共鳴的：以前在 mobile team，五個人裡得有人專門搞 Jenkins 設定，大概半個人力綁在上面，而且是用抽籤決定誰來做的，因為沒人想做，大家只想寫 code。

平台團隊就是來解這題的。它跟舊的 DevOps 團隊不一樣，不是把整條流程整碗端走，而是定義最佳實踐、提供自助式的內部開發入口（IDP），讓應用團隊用模板自己開專案。標準由平台團隊定，但實際營運的擁有權還留在各團隊手上，DevOps 那種貼近程式碼、出事會痛的好處沒丟掉，工程師卻不用再去當各種部署方式的專家。Rob 也補一句：不是每家公司都該有平台團隊，小公司就是 app 團隊自己兼著做。

Rollback 是假的安全網

這段最辣。

Octopus 常被客戶問：你們怎麼沒有 rollback 按鈕？我就想回滾，能有多難？Rob 的答案是：在完全無狀態的系統，回滾很簡單，git revert 推回去就好。問題是真實世界的系統幾乎都有狀態，最典型的就是資料庫。

一旦你回滾程式碼，但資料庫的 schema 已經改了，兩邊對不上，你就爆了。你或許可以為每個 migration 準備一個反向 migration，但這不是永遠做得到。所以 Octopus 給客戶的建議很反直覺：盡量別講 rollback，永遠想 roll forward。出了 bug，往前修一版推出去，version 2 出問題，你的解法不是退回 version 1，而是做出修好的 version 3。這時候快速回饋迴路、hot fix 流程就是為這刻存在的。

Rob 說，很多客戶嘴上講「我們常常 rollback 啊」，一問到「那遇到 schema 變更怎麼辦」就卡住了，這才意識到自己只是運氣好，從來沒撞上而已。

那理想中的回滾長什麼樣？答案是 feature flag。透過切換程式碼路徑來「還原」，跟你當初推出功能一樣簡單，按一下就好。

Feature toggle 為什麼常常比 canary 好用

Rob 在 progressive delivery（漸進式交付）這段，明顯偏愛 feature toggle 勝過 canary。

先快速定義。Progressive delivery 是持續交付的下一步，目的是用更受控的方式釋出。常見手法有三種：canary deployment，把 version 2 跟 version 1 並排跑，用流量管理器導一小部分流量過去、慢慢加碼，名字來自礦坑裡的金絲雀（牠先不叫了，你就知道該逃了，紐西蘭就是這隻鳥）；blue-green，新舊版本並存，新版先驗證完再把流量整批切過去；還有 feature toggle。

Rob 說 feature toggle 對應用層交付有幾個 canary 比不上的優勢。第一，變更單位超細，可以細到單行程式碼，其他全部不動；canary 的變更單位是整個 app，你這次累積了 20 個 commit，一推就是 20 件事一起測。第二，鎖定目標精準，你可以下「所有德國、購物車裡有某商品的用戶」這種複雜規則，用網路流量規則根本做不到。第三，回滾以秒計，按一個鈕立刻生效，不用重新部署舊版。第四，它把「部署」跟「釋出」解耦了，你可以禮拜一先把程式碼推上去，禮拜二進公司、日誌都備好了再開功能，而不是被部署的時間點綁死、還要跟另外十個團隊同時盯著 log。

當然 feature toggle 不是萬靈丹。碰到資料庫 schema 變更，這就是所有 progressive delivery 共同的大魔王，這也是 Octopus 自己最頭痛的地方，因為他們同時有 SaaS 和 on-prem 兩種版本。SaaS 你完全掌控版本，可以分階段做 expand and contract；on-prem 你根本不知道客戶從哪一版升上來，可能直接從 version 1 跳到 version 6。

Feature flag 是會上癮的，記得拔草

不過 feature toggle 有個後遺症，主持人在 Uber 看過一百次：一旦開始用，程式碼裡到處都是 flag，拔都拔不掉。Rob 笑說這像吸毒，開始了就停不下來。

Octopus 自己的做法是在 toggle 上掛 metadata：標記哪個團隊擁有、設一個到期日。時間到了不會有壞事發生，但 CI 流程會發通知提醒那個團隊「這個 toggle 好像沒在用了」。他用了一個我很喜歡的比喻：在程式碼裡用「園藝」這個隱喻時，清 feature flag 就是除草，你得持續盯著。順帶一提，Rob 坦白自己名下八成也有一堆該拔沒拔的 flag，登進去大概會收到一串通知。這種「我也還沒做到」的自嘲，反而讓建議更可信。

關於 AI 大量寫程式碼這件事怎麼衝擊 pipeline，他的判斷蠻清醒的：現在還很早，CI/CD 的衝擊會落後於開發團隊怎麼用 AI。但有個方向很明確，當大部分程式碼是 AI 產的、工程師早就 context switch 去做下一件事了，pipeline「跑 30 分鐘還是 20 分鐘」就沒那麼重要，反正 AI agent 可以自己顧著流程、看到問題再丟修正。重點會從「速度」轉向「降低 AI 產碼帶來的風險」，而 feature toggle 正好讓你能把程式碼推得飛快、卻獨立控制功能何時真正釋出。這跟之前在OpenAI 工程師零行人寫程式、百萬行上線的 Harness Engineering 實戰聊到的方向是同一條線：人不再盯著每一步，重點變成怎麼設計讓 agent 安全地跑。

On-prem 沒有死，反而是個生意機會

最後聊 Octopus 同時養 SaaS 和 on-prem 的現實。

Rob 挖過數據：他們推一個新版本，on-prem 客戶平均要 200 天才有 50% 升級上去，到 75% 要 400 多天，還有人在跑五六七年前的版本。所以每次出新版，他們得確保軟體能從 2023.1 一路升到 2026.4，背負一堆 schema 升級的包袱。

那為什麼不學一堆新創直接 all-in SaaS、砍掉舊版支援？因為 Octopus 大多數客戶就是 on-prem，銀行、金融機構、政府，他們要對系統有完整控制權。Rob 點出一個我覺得對創業者很有用的觀察：如果你做的基礎設施軟體也支援 on-prem，你的競爭對手可能少很多，因為有一群客戶是「願意掏錢就為了能跑在自己機房」的。SaaS 比較好做，所以那邊競爭也更激烈。

而且那些五年沒升級的客戶，從某個角度看是「天啊他們在幹嘛」，但換個角度，只要東西能用、他們持續付錢，這就是你最忠誠的一批客戶。If it ain't broke, don't fix it。這點在 AI 時代只會更明顯，Cursor 的 coding 模型據說每五小時更新一次、一直變強，但你調教好、寫好指令的那套，常常一換大版本就壞了。會有愈來愈多團隊願意花錢把模型 pin 住、跑在自己的基礎設施上，等我自己想換再換。

寫到這我自己的 takeaway 是：這集從頭到尾都在打同一個東西，研討會上人人喊的「best practice」「everything in the cloud」「everything in Git」，到了真實世界都會被各種奇怪的限制磨成不一樣的形狀。大部分團隊只是想把軟體推出去而已。Rob 給想踏進 progressive delivery 的人的建議也很樸素：別想太多，先加一個 feature toggle，親自體驗一次「線上爆炸、手一伸就把它關掉、止血、再慢慢查」的感覺，你就回不去了。

這類把產業老手的實戰經驗拆給你看的內容，我會繼續寫，訂閱 wilsonhuang.xyz 就不會錯過。