CI/CD 是什麼？程式碼寫完不是直接上線——自動化部署完整指南

工程師跟你說：「這個功能我改好了，等 CI 跑完就能上線。」你心想——CI 是什麼？為什麼改好了還不能直接上線？

又或者，你的產品每次更新都要等工程師手動部署，一等就是半天。客戶反映的 bug 修好了，卻要等到下週才能上線。你不禁懷疑：難道沒有更快的方法嗎？

有。這個方法叫做 CI/CD（持續整合 / 持續部署）——讓程式碼從「寫完」到「上線」的過程全自動化。這篇文章用白話文幫你搞懂它是什麼、為什麼重要、以及它怎麼影響你的專案品質和速度。

CI/CD 就像工廠的自動化產線

想像你開了一間糕餅工廠：

以前，每個師傅手工做完一批糕餅，要自己搬去品管部門檢查、自己包裝、自己搬上貨車出貨。整個過程又慢又容易出錯——忘了檢查的、包裝貼錯標籤的，時有所聞。

現在，你裝了一條自動化產線：師傅把麵團放上輸送帶，後面的烘焙、品管、包裝、出貨全部自動完成。師傅只需要專心做好麵團，其他的流程機器會搞定。

CI（持續整合）：每次改程式碼，自動幫你抓 bug

CI 的全名是 Continuous Integration（持續整合）。它的核心概念是：

每當工程師提交一段新程式碼（通常是透過 Git 和 PR），系統會自動做以下事情：

1. 編譯程式碼——確認程式碼語法沒有錯誤

2. 執行自動化測試——跑幾十到幾百個預先寫好的測試案例，確認新功能沒有弄壞舊功能

3. 程式碼品質檢查——自動檢查程式碼風格、安全漏洞、效能問題

如果任何一步失敗，工程師會立刻收到通知，必須修好才能繼續。這就像工廠產線上的品管站——有問題的產品不會流到下一關。

CD（持續部署）：測試通過，自動上線

CD 有兩種意思：

大多數團隊會從 Continuous Delivery 開始（保留人工確認的按鈕），等流程成熟後再升級到 Continuous Deployment。

CI/CD 完整流程：從程式碼到使用者手上

整個流程從工程師提交程式碼到使用者能看到新功能，可以在 10-30 分鐘內 完成。相比傳統手動部署的幾小時到幾天，效率提升是巨大的。

沒有 CI/CD 的團隊，風險有多大？

如果你的開發團隊還在手動部署，以下是你可能面臨的風險：

1. 「在我電腦上可以跑」症候群——工程師在自己電腦上測試沒問題，但部署到正式環境就爆炸。CI/CD 會在統一的環境中測試，避免這個問題。

2. 上線就是在賭博——沒有自動測試，每次上線都在祈禱不要出事。有了 CI，每次提交都會自動驗證，大幅降低風險。

3. 修 bug 的速度跟不上客戶抱怨的速度——手動部署可能要半天，客戶等不了。CD 讓修好的 bug 幾分鐘就能上線。

4. 工程師把時間花在「搬磚」而不是「蓋房」——手動部署是重複性工作，讓工程師去做這件事是浪費人才。

這些問題如果不處理，長期下來會變成技術債——系統越來越難維護，成本越來越高。

CI/CD 常用工具——你不需要會用，但要知道名字

如果你在選開發公司，記得問他們用什麼 CI/CD 工具。如果答案是「沒有」或「手動部署」，這是一個警訊。

CI/CD 對你的報價單有什麼影響？

你可能會問：建置 CI/CD 要額外花錢嗎？

答案是：初期會多一些設定成本，但長期省下的錢遠超過投入。

• 設定成本：通常需要 8-24 小時的工時來建置 CI/CD 流程，依專案複雜度而定

• 工具成本：GitHub Actions 免費方案每月有 2000 分鐘，小專案通常夠用

• 節省的成本：每次部署從 2 小時縮短到 10 分鐘，一個月部署 20 次就省下 40 小時工時

詳細的費用結構可以參考系統開發費用拆解。

選好了 CI/CD 工具，下一步就是選部署平台。如果你正在考慮用什麼平台跑你的服務，可以看看我們的五大 PaaS 部署平台完整比較，從 Vercel 到 Zeabur 一次看清楚。

下一步：確保你的專案有自動化品質把關

CI/CD 是任何認真做軟體的團隊都該有的基本配備，並非大公司專屬。如果你正在規劃或重新評估你的開發專案，歡迎免費諮詢恆遠的技術團隊。我們會幫你評估現有的部署流程，找出可以自動化的環節。