今日目標

昨天我們成功透過 Docker 將 AI 個人財務追蹤器打包成輕量、獨立的容器，解決了跨環境「在我電腦上可以跑」的經典魔咒。但在現代軟體工程中，總不能每次修改一行程式碼，就要手動 SSH 上伺服器去 git pull 並重新 build 容器吧？

今天我們正式進入自動化發布的核心環節——CI/CD Pipeline（持續整合與持續部署）~~

我們要運用 AI 幫我們撰寫 GitHub Actions 工作流程（Workflow），讓專案在每次推送（git push）或發起 Pull Request 時，自動執行 Day 10 與 Day 18 寫好的單元測試、E2E 測試，並自動完成專案 Build 檢測。讓機器人幫我們把關品質，確保每一行送進主分支的程式碼都是健全可用的！

Human vs. AI 實戰記錄

GitHub Actions 的 YAML 語法繁雜、各種 Action 動作版號（如 actions/checkout@v4）更新頻繁，而且需要處理環境變數與 Secret 注入。這類配置工作交給 AI 最適合，但若不注意細節，AI 常常會寫出「每次推送都花費 15 分鐘重跑全部測試」且容易因為資料庫未就緒而失敗的低效 Pipeline。

1. 給 AI 的指令 (Prompt)

我們希望 AI 幫我們打造一個高效的 GitHub Actions Workflow，包含安裝依賴、執行 Lint、跑 Jest 單元測試，以及在容器服務（Service Container）中啟動 PostgreSQL 來跑整合測試與 Next.js Build。

Plaintext
你是一位資深 DevOps 專家。請幫我的 Next.js ( App Router + Prisma + PostgreSQL ) 專案撰寫一組 GitHub Actions CI 流程 (.github/workflows/ci.yml)。

需求如下：

1. 觸發條件：當推送到 main 分支或針對 main 發起 Pull Request 時觸發。
2. 執行步驟：
   • Checkout 程式碼並設定 Node.js (v20) 與 npm 快取。
   • 安裝專案依賴 (npm ci)。
   • 執行 ESLint 與 TypeScript Type Check (npm run lint / tsc)。
   • 啟動 PostgreSQL 16 的 Service Container，並自動執行 Prisma Migration 與 Seed 測試。
   • 執行單元與整合測試 (npm test)。
   • 執行 Next.js 生產建置 (npm run build) 以確保打包無誤。

2. AI 產出的結果 (Code)

AI 給出了一份結構完整的 .github/workflows/ci.yml 設定檔：

YAML
name: CI Pipeline

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    services:
      postgres:
        image: postgres:16-alpine
        env:
          POSTGRES_USER: test_user
          POSTGRES_PASSWORD: test_password
          POSTGRES_DB: test_db
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run Lint and Type Check
        run: |
          npm run lint
          npx tsc --noEmit

      - name: Run Database Migrations
        env:
          DATABASE_URL: postgresql://test_user:test_password@localhost:5432/test_db?schema=public
        run: npx prisma migrate deploy

      - name: Run Tests
        env:
          DATABASE_URL: postgresql://test_user:test_password@localhost:5432/test_db?schema=public
        run: npm test

      - name: Build Application
        env:
          DATABASE_URL: postgresql://test_user:test_password@localhost:5432/test_db?schema=public
          OPENAI_API_KEY: mock_key_for_build
        run: npm run build

3. 修正與翻車紀錄 (Debug Experience)

這份 CI 設定看起來很完美，但在 GitHub Actions 實際跑起來時，卻立刻遇到了兩個讓人抓狂的「CI 翻車現場」！

翻車點一：Next.js Build 時缺少環境變數導致 Static Generation 崩潰

當 CI 走到 npm run build 階段時，Next.js 的 App Router 開始嘗試進行頁面的靜態預渲染（Static Prerendering）。這時專案中某些 Server Component 因為在頂層呼叫了資料庫或找不到真實的 NEXTAUTH_SECRET 與 OPENAI_API_KEY，直接噴出 Error: Environment variable not found: NEXTAUTH_SECRET，導致整個 CI 流程在最後一刻功虧一匱！

翻車點二：Prisma Client 未在 Build 前自動生成

AI 將 npx prisma migrate deploy 放在測試前，但在 npm run build 之前，雖然執行了 npm ci，卻漏掉了關鍵的 npx prisma generate。這導致 Next.js 在編譯時抓不到正確的 Prisma Client 型別與底層引擎，報出找不到 @prisma/client 的錯誤。

介入修復！

我們引導 AI 補齊建置時所需的 Mock 環境變數，並在建置步驟前明確加入 Prisma Client 生成指令：

注入 CI 專用 Mock 環境變數：在 Build 步驟中加入預設的 NEXTAUTH_SECRET 與 NEXTAUTH_URL，避免靜態檢查因缺少金鑰而崩潰。

調整步驟順序：確保在 npm run build 之前一定會先執行 npx prisma generate。

善用 GitHub Actions Cache：對 Next.js 的 .next/cache 進行快取，大幅縮短每次 Push 後的等待時間。

修正後的 Workflow 配置：

YAML
name: CI Pipeline

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    services:
      postgres:
        image: postgres:16-alpine
        env:
          POSTGRES_USER: test_user
          POSTGRES_PASSWORD: test_password
          POSTGRES_DB: test_db
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Generate Prisma Client
        run: npx prisma generate

      - name: Run Lint and Type Check
        run: |
          npm run lint
          npx tsc --noEmit

      - name: Run Database Migrations
        env:
          DATABASE_URL: postgresql://test_user:test_password@localhost:5432/test_db?schema=public
        run: npx prisma migrate deploy

      - name: Run Tests
        env:
          DATABASE_URL: postgresql://test_user:test_password@localhost:5432/test_db?schema=public
          NEXTAUTH_SECRET: ci_mock_secret_for_testing
        run: npm test

      - name: Cache Next.js build
        uses: actions/cache@v4
        with:
          path: |
            .next/cache
          key: ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json') }}-${{ hashFiles('**.[jt]s', '**.[jt]sx') }}
          restore-keys: |
            ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json') }}-

      - name: Build Application
        env:
          DATABASE_URL: postgresql://test_user:test_password@localhost:5432/test_db?schema=public
          NEXTAUTH_SECRET: ci_mock_secret_for_production_build
          NEXTAUTH_URL: http://localhost:3000
          OPENAI_API_KEY: sk-mock-openai-key-for-ci-build
        run: npm run build

JavaScript / AI 學習小結

CI 流程是專案健康的「自動照妖鏡」：
在沒有 CI 之前，程式碼有沒有 Bug、型別有沒有對齊、環境變數有沒有漏掉，全靠工程師的手氣與人工檢查。有了 GitHub Actions，任何不小心寫錯的 TypeScript 語法或漏掉的 Prisma Generate，都會在推送的瞬間被機器人攔截，徹底解放了工程師的心智負擔。

AI 在 DevOps 配置中的盲點：
AI 擅長組合標準的 GitHub Actions 步驟（如 Checkout、Setup Node），但它往往不了解 Next.js 在打包時會對環境變數進行靜態分析。工程師必須親自點出「Build 階段需要 Mock 金鑰」以及「Prisma Generate 順序」的痛點，才能讓 CI 順利跑通。

自動化防線建立完成，每一次程式碼提交都有了最嚴格的品質保證！明天 Day 26，我們將迎接全棧開發的最高潮——一鍵部署上雲，將我們的 AI 個人財務追蹤器正式推向公開網際網路！