我該如何開始導入 CICD

DevOps 相信已經是很多人聽到有點疲乏的名詞。

尤其是在資訊爆炸的現在，

最不缺的就是知識的獲取管道。

有人說 DevOps 是一種文化，

有人說 DevOps 是自動部署，

這些說法我也許都同意。

不過有些人真正想問的是：「我到底該如何開始？」

或者更明確地說：

我該如何導入自動部署的機制？

對一些人來說，不是不想做，

而是不知道第一步應該踩在哪裡。

因此這篇不討論晦澀難懂的名詞，

也不討論那些短期內不確定能否落地的文化口號。

我會用比較實際的方式說明，

在開始談 DevOps 之前，

我們可以如何先從 CI/CD 開始，

讓日常開發與部署工作變得更穩定、更順手。

為什麼是 CI/CD

CI 是 Continuous Integration，中文通常稱為持續整合。

CD 則是 Continuous Delivery 或 Continuous Deployment，中文稱為持續交付或持續部署。

DevOps 可以討論的事情很多。

為什麼我們應該先從 CI/CD 開始？

或者更明確地說，為什麼應該先從 CD，也就是自動部署開始？

原因其實很簡單：

這是最容易立即看見效果的地方。

你會看到這篇文章，並且看到這裡，

表示你大概對目前的工作流程有一些期待，

也希望自己能夠成長，並改善團隊的開發與交付流程。

討論文化、打破開發與維運之間的隔閡，

通常需要管理階層介入，也需要組織願意配合。

在基礎機制都還沒建立起來以前，

更不用說要進一步統一管理日誌、建立告警機制、制定 SLO 或導入事件管理流程。

這時候最需要的不是漂亮的名詞，

而是自動化。

更明確地說，

就是先把程式部署自動化。

當其他同仁看到部署錯誤減少，

甚至開始接近零失誤，

團隊才會更願意相信這套做法，

也才有機會往後討論 DevOps、SRE 或平台工程的其他實作。

如何導入自動部署

程式碼進版控

有些人看到這裡可能會覺得詫異。

現在都已經是 AI 時代了，

Git 也不知道是幾年前的東西了，

竟然還需要提醒程式碼要進版控？

很不幸地，

除了大公司以外，

有些小公司，甚至公司內只有一位工程師的團隊，

還真的可能沒有把程式碼放進版控系統。

例如 AWS Lambda 的開發。

AWS Cloud Console 提供了很方便的環境，

讓開發者可以直接在 AWS Lambda 上修改程式。

甚至 Python 開發者可以直接使用套件包 AWSLambdaPowertoolsPythonV2，

連 requirements.txt 都不需要特別撰寫，

就可以讓程式跑起來。

這種方便性很容易讓人忽略一件事：

程式碼可能根本沒有進版控。

即使使用 AWS Lambda 本身的 Versions，

它的實際行為也是將 runtime、environment variables 和 Lambda 設定做成一份快照。

這並不是我們期待的程式碼版控。

當我們需要修改環境變數，

或是設定 VPC、Security Group、IAM Role 這類配置時，

就可能因為變更項目太多，

導致回滾時需要重新設定，

或是留下大量難以辨識的 Version。

在早期還沒有使用 SVN 和 Git 的時候， 如果程式碼沒有進 Git 做版控，會怎麼管理系統？ 通常是透過 SSH 或遠端桌面連線進入伺服器， 到檔案所在目錄， 把當天要修改的檔案先更名備份， 然後讓它一路留在機器上， 直到某天大家都忘記那些檔案到底能不能刪。

index.php
index.php_20260616
index.php_20260616_2

所以 CI/CD 的第一步不是寫 YAML，

也不是先挑 Jenkins、GitLab CI、GitHub Actions 或其他工具。

第一步是確保程式碼真的進入版控，

而且團隊能夠從 Git 裡知道：

• 現在正式環境跑的是哪一版
• 這次改了哪些內容
• 誰在什麼時間改了什麼
• 出問題時應該回到哪一個版本

沒有版控，後面的 CI/CD 其實都只是把不穩定的流程包成自動化而已。

自動部署

要實作自動部署，

建議先掌握三個部分：

部署流程、環境變數 和 目標環境存取權限。

部署流程

部署流程必須可以重複執行。

而且不只是第一次可以成功，

第二次、第三次，甚至執行無限次都應該可以成功。

不管是 SIT 環境、UAT 環境，還是正式環境，

各個環境都應該盡量使用一致的流程。

不應該因為環境不同，

就需要改變部署步驟。

也不應該因為某個環境缺少初始資料，

就導致整個部署系統崩潰。

一個好的部署流程至少要能回答幾個問題：

• 從哪個 Git branch 或 tag 取得程式碼
• 如何安裝相依套件
• 如何執行測試
• 如何打包或建置 artifact
• 如何把 artifact 部署到目標環境
• 部署失敗時如何停止或回滾

一開始不需要追求完美。

如果團隊從來沒有 CI/CD，

第一版流程可以很簡單。

例如先做到：

push code → 執行測試 → 部署到測試環境

等這個流程穩定後，

再逐步加入正式環境部署、審核機制、版本標籤、回滾策略與通知。

環境變數

相信各位在不同環境中，

應該會使用不同的資料庫連線。

就算為了省錢，

測試環境 和 正式環境 共用同一台資料庫主機，

至少也應該拆分不同的資料庫名稱或 schema。

因此，我們不應該把這些資訊寫死在程式碼中。

比較好的做法是將設定獨立出來，

透過設定檔、環境變數、Secret Manager、Parameter Store，

或其他組態管理方式，

讓不同環境載入不同設定。

如果資料庫連線、API Key、第三方服務 URL 都寫死在程式碼裡，

每次按需求部署時，

就很容易因為手動修改造成失誤。

更糟的是，

機敏資訊還可能被 commit 到 Git 裡，

變成另一個資安問題。

對新手來說，

最基本的原則是：

• 程式碼描述行為
• 環境變數描述環境差異
• Secret 不要出現在 Git 裡
• 測試環境與正式環境要能清楚區分

當這些界線切清楚後，

CI/CD 才能真正做到同一份程式碼部署到不同環境。

目標環境存取權限

目標環境存取權限可能是帳號密碼，

也可能是不同的 private key，

也可能是在不同環境安裝 agent，

再讓 agent 主動或被動取得部署內容。

不管採用哪種方式，

重點都是 CI/CD 系統必須具備部署到目標環境的權限。

不過權限不是越大越好。

新手在剛導入時，

很容易為了讓流程先跑起來，

直接給 CI/CD 系統過大的權限。

短期看起來很方便，

長期卻會變成風險。

比較好的做法是採用最小權限原則。

CI/CD 需要部署 Lambda，

就給它部署 Lambda 所需的權限。

CI/CD 需要上傳 artifact 到 S3，

就給它對應 bucket 的必要權限。

CI/CD 需要重啟某個服務，

就只給它操作該服務的權限。

部署權限本身也應該被管理與追蹤。

因為當 CI/CD 開始能夠修改正式環境時，

它就不再只是開發工具，

而是正式環境變更流程的一部分。

從最小可行流程開始

如果你完全不知道該從哪裡開始，

可以先用最小可行流程作為第一個目標。

不要一開始就想把所有事情都自動化。

也不要一開始就追求非常完整的平台工程體驗。

先讓一個服務可以透過 CI/CD 部署到測試環境，

再讓同一套流程可以部署到正式環境。

例如：

1. 程式碼進 Git
2. push 或 merge request 觸發 pipeline
3. pipeline 執行基本測試
4. pipeline 打包部署 artifact
5. 自動部署到測試環境
6. 人工確認後部署到正式環境
7. 部署結果通知團隊

這樣的流程看起來不華麗，

但它已經足以改善很多日常問題。

例如：

• 不再需要手動複製檔案
• 不再需要登入伺服器改程式
• 不再需要靠記憶判斷部署了什麼
• 不再需要每次部署都擔心漏步驟
• 出問題時更容易追蹤是哪一次變更造成的

當這個流程穩定後，

你自然會開始看到下一步要補什麼。

也許是自動化測試不足，

也許是環境變數管理混亂，

也許是部署後沒有健康檢查，

也許是沒有告警與日誌追蹤。

這些問題浮現時，

才是繼續往 DevOps、SRE 或平台工程推進的好時機。

結論

導入 CI/CD 不需要一開始就把自己想像成成熟的大型技術團隊。

對還沒開始的人來說，

最重要的是先建立一條可靠、可重複、可追蹤的部署流程。

只要程式碼有版控，

部署流程可以重複執行，

環境差異可以透過設定管理，

目標環境權限也能被妥善控管，

團隊就已經往更成熟的工程流程前進了一大步。

DevOps 不是從口號開始，

而是從開發與維運能夠共同信任同一套交付流程開始。

SRE 不是一開始就要建立完整的可靠性工程體系，

而是先讓每一次變更都更可控、更可觀測，也更容易回復。

平台工程也不是一開始就要做出龐大的內部平台，

而是逐步把團隊反覆執行、容易出錯的事情產品化、自助化。

所以，如果你正在思考該如何開始，

不要先被 DevOps、SRE、平台工程這些名詞嚇到。

先從一條最小可行的 CI/CD pipeline 開始。

讓部署變得穩定，

讓變更變得可追蹤，

讓團隊慢慢相信自動化。

當這件事做起來後，

後面的文化、可靠性與平台化，

才會有真正落地的基礎。