Day 25 — 從 CI/CD 開始的 Docker 大遷徙與資料庫重生

今天的故事是這樣開始的——
當我終於把 CI/CD pipeline 規劃到一個階段性完成，
我望著那閃亮亮的 GitHub Actions workflow，心想：

「該是時候進軍 UAT 和 Prod 了。」

結果一開工，就變成一場「環境大搬家」。
沒錯，我決定要把開發與測試環境都搬進 Docker 裡，
讓它們乾淨、可重現、還能跟 pipeline 無縫接軌。

🐳 一切從 Dockerfile 開始

我先整理了所有部署檔，包括：

• Dockerfile：重新設計 build stage
• docker-compose.yml：拆成 dev / test / uat / prod 多版本
• .env：統一環境變數格式，避免 pipeline 與 local 落差

CI/CD 的邏輯是：

build → test (E2E) → push image → deploy to UAT/PROD

為了讓這整條鏈穩定，我需要讓 dev/test 也跑在相同的容器中。
於是我開始大搬遷：
API、Redis、PostgreSQL，全都進了 container。
開發機瞬間變成一座迷你雲端 ☁️

💾 搬遷的代價：資料庫重建

當我把資料庫搬進 Docker 時，才發現世界沒那麼單純。
schema 已經在過去幾天的開發中偷偷「進化」了。
index、enum、測試資料，全都和前一版不同。

那一刻，我只能接受命運——

「好吧，重建吧。」

我按下：

DROP DATABASE teamsnotify;
CREATE DATABASE notification_center;

接著用 migration 重跑 schema，
再一個一個加回初始化資料。

🧱 一步步的修復與驗證

搬遷過程中，我遇到不少「小坑」：

1. Index 差異：開發環境的 index 設計和舊版本不符。
   → 調整 migration scripts，補上 CREATE INDEX CONCURRENTLY。

2. Enum 差異：bot_status_summary 在不同版本間型別不一致。
   → 手動修正 enum casting。

3. 初始化資料：有的 seed 資料不再相容。
   → 加入 ON CONFLICT DO NOTHING 讓 seeding 可重入。

4. 測試資料：測試用 destination 缺欄位。
   → 新增完整的初始化腳本 init_seed.sql。

這些改完後，我重新跑了 migration，Postgres 終於給我一句溫暖的回覆：

All migrations applied successfully.

那一刻，整個人都 Zen 了。🧘‍♂️

🧪 驗證階段：E2E 測試再啟動

環境建好後，我直接在 Docker 內重跑 E2E 測試。
步驟大概是這樣：

make docker-up
make test-e2e
make test-report

結果：
15 個測試案例，全數通過 ✅
Redis、API、Postgres 彼此都活著、對話順暢。

甚至連外部 Teams 通知也照樣運作：

notification queued (3 destinations)

我當場笑出聲。
這比 pipeline 綠燈還療癒。

🔧 最後的修整：部署與設定同步

趁著 CI/CD 範本已經成形，我也順手同步：

• 部署設定：統一開發、測試、UAT、Prod 的變數檔
• 環境變數：TEAMS_BOT_APP_ID, TENANT_ID, BOT_PASSWORD
• 測試報告：整合到 pipeline 的 artifacts 裡
• 健康檢查：/health endpoint 監控容器狀態

當所有容器啟動、E2E 全綠，我靜靜看著螢幕上那句話：

API /health ✅ OK

這不只是系統穩定，更是工程師的成就感。

🧾 今日成果

💡 結語：重建的價值

今天最大的感觸是——
「有時候重建不是浪費，而是確認自己走在對的路上。」

當我把開發、測試、資料庫全搬進 Docker，
再看著 CI/CD 一次次跑通，
那種穩定、乾淨、可重現的幸福感，
真的會讓人上癮。