身為開發者，你是否經歷過這種循環：改完程式 → 本地測試 OK → 手動打包 → 用 FTP/SSH 傳到伺服器 → 重啟服務 → 然後發現「咦，怎麼上線的是上一版的程式？」手動部署不只慢，更可怕的是人為失誤。《從 Docker 開始》那篇我們學會了把應用裝進容器，今天要接著往前一步：用 GitHub Actions 把「測試 → 建置 → 部署」這條路全自動跑起來，讓你 push 一個 commit，剩下的交給機器人。
一、為什麼要自動化部署？
手動部署的三大痛點：
- 慢：每次都要重複十幾個步驟。
- 易錯：漏傳一個檔案、環境變數設錯就炸。
- 不可重現：同事的電腦能跑，你的卻不行。
CI/CD（持續整合 / 持續部署）的本質，就是把這些流程寫成程式碼，每次都用一模一樣的環境執行，結果可預測、可重來。
二、GitHub Actions 核心概念
先認識三個名詞，後面才好懂：
- Workflow（工作流程）：放在
.github/workflows/下的 YAML 檔，定義「什麼時候、做什麼」。 - Job（作業）：一個 Workflow 可含多個 Job，彼此預設並行執行。
- Step（步驟）：Job 裡的單一動作，例如「安裝 Node.js」、「跑測試」。
三、步驟 1：準備專案與 Secrets
假設我們有個 Node.js 專案要部署到伺服器。先在 GitHub 倉庫的 Settings → Secrets and variables → Actions 新增機密：
HOST：伺服器 IP 或網域SSH_KEY：登入用的私鑰DEPLOY_PATH：伺服器上的部署目錄
重點：這些敏感資料絕對不要寫進程式碼，一律走 Secrets 管理。
四、步驟 2：撰寫第一個 Workflow
建立 .github/workflows/deploy.yml：
name: Deploy
on:
push:
branches: [main]
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm ci
- run: npm run build
- name: Deploy via SSH
uses: appleboy/ssh-action@v1
with:
host: ${{ secrets.HOST }}
username: deploy
key: ${{ secrets.SSH_KEY }}
script: |
cd ${{ secrets.DEPLOY_PATH }}
git pull
npm ci --omit=dev
pm2 restart app
五、步驟 3：觸發與查看執行結果
只要 git push origin main，GitHub 就會自動在 Actions 分頁跑這個 Workflow。綠色勾勾代表成功，紅色代表失敗——點進去能看到每一步的即時日誌，比在本機盲猜快得多。
六、重點：常見坑與最佳實踐
- 先用測試擋住壞程式：在 deploy 之前加一個 test job，失敗就不部署。
- 鎖定版本：
actions/checkout@v4這種 pin 版號，避免上游更新破壞你的流程。 - 密碼用 Secrets，永遠別 commit 私鑰。
- 部署前先備份或採用「零停機」策略（如藍綠部署），出事能秒回滾。
寫好一次，從此每次上線都只是「推一行程式」的事。把重複勞動交給機器，把腦力留給真正重要的事。
互動話題：你現在的部署流程是自動還是手動？如果還在手動上線，最想先自動化哪一段？歡迎留言聊聊你的部署痛點！