---
layout: post
title: "我該如何開始導入 CICD"
description: "寫給還沒有開始導入 CI/CD 的新手，從程式碼版控、自動部署流程、環境變數與目標環境權限開始，逐步建立可重複、可追蹤、可回滾的交付流程。"
author: Mark_Mew
categories: [CICD]
tags: [CICD, DevOps, SRE, Platform Engineering]
keywords: [CICD, CI, CD, DevOps, SRE, Platform Engineering, 自動部署]
date: 2026-06-16
---

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 提供了很方便的開發環境，

讓開發者透過網頁的 IDE 修改程式後就可以直接佈署。

甚至 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
> ```
{: .prompt-info}

所以 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 開始。

讓部署變得穩定，

讓變更變得可追蹤，

讓團隊慢慢相信自動化。

當這件事做起來後，

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

才會有真正落地的基礎。