經過前六天的 AI-DLC Sprint 實踐，我們完成了從需求到開發的完整流程。今天進入最後也是最關鍵的環節：Deployment（部署上線）。

但這次不是手動部署，而是讓 AI 幫我們設計一套完全自動化的 CI/CD Pipeline。更重要的是，我們要實現「push 即部署」的夢想。

Solo Sprint 的部署哲學

零會議、零等待、零溝通成本

部署也是這樣。不應該有複雜的流程、不應該需要 DevOps 團隊、不應該讓你在凌晨三點還在擔心部署會不會出問題。

PocketSmart 作為 Next.js 應用，我們的部署目標很明確：

• 前端：靜態資源 + SSR
• 後端：Next.js API Routes
• 資料庫：Supabase（已經是雲端服務）
• 部署平台：Vercel（Next.js 的親兒子）

聽起來很簡單？但魔鬼藏在細節裡。

AI 協助設計部署策略

我打開 Claude Code，開始了今天的第一個對話：

我：

PocketSmart 現在是 Next.js + Supabase 的架構。
我希望實現自動化部署，每次 push 到 main 就自動上線。
但我還沒做完 MVP，所以先幫我設計部署流程，
包括 GitHub Actions 的 workflow。

Claude：

了解你的需求。基於 Next.js + Supabase 的特性，
我建議分階段部署策略：

階段一：基礎 CI/CD（今天完成）
- 程式碼檢查（ESLint）
- 型別檢查（TypeScript）
- 自動部署到 Vercel

階段二：品質閘門（MVP 完成後）
- 單元測試
- E2E 測試
- 效能檢查

讓我先幫你設計基礎的 GitHub Actions workflow...

GitHub Actions Workflow 的誕生

第一版：最簡部署

Claude 給了我第一版的 workflow，非常精簡：

# .github/workflows/deploy.yml
name: Deploy to Production

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          
      - name: Install dependencies
        run: npm ci
        
      - name: Build
        run: npm run build
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}
          NEXT_PUBLIC_SUPABASE_URL: ${{ [secrets.NEXT](http://secrets.NEXT)_PUBLIC_SUPABASE_URL }}
          NEXT_PUBLIC_SUPABASE_ANON_KEY: ${{ [secrets.NEXT](http://secrets.NEXT)_PUBLIC_SUPABASE_ANON_KEY }}

第二版：加入程式碼品質檢查

但我不滿足於此。既然是 AI-DLC Sprint，品質也很重要：

我：「幫我加上 ESLint 和 TypeScript 檢查，確保程式碼品質。」

name: CI/CD Pipeline

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

jobs:
  quality-check:
    name: Code Quality Check
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      
      - name: Install dependencies
        run: npm ci
      
      - name: Run ESLint
        run: npm run lint
        
      - name: Type check
        run: npm run type-check
  
  build:
    name: Build Verification
    needs: quality-check
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      
      - name: Install dependencies
        run: npm ci
      
      - name: Build application
        run: npm run build
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}
          NEXT_PUBLIC_SUPABASE_URL: ${{ [secrets.NEXT](http://secrets.NEXT)_PUBLIC_SUPABASE_URL }}
          NEXT_PUBLIC_SUPABASE_ANON_KEY: ${{ [secrets.NEXT](http://secrets.NEXT)_PUBLIC_SUPABASE_ANON_KEY }}

第三版：Preview 部署

這是最棒的部分。我希望每個 PR 都能有獨立的預覽環境：

name: Deploy Pipeline

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

env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}

jobs:
  quality-check:
    name: Code Quality
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm run type-check

  deploy-preview:
    name: Deploy Preview
    if: github.event_name == 'pull_request'
    needs: quality-check
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to Vercel Preview
        run: |
          npm i -g vercel
          vercel pull --yes --environment=preview --token=${{ secrets.VERCEL_TOKEN }}
          vercel build --token=${{ secrets.VERCEL_TOKEN }}
          vercel deploy --prebuilt --token=${{ secrets.VERCEL_TOKEN }}

  deploy-production:
    name: Deploy Production
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    needs: quality-check
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to Vercel Production
        run: |
          npm i -g vercel
          vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
          vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
          vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}

實際部署流程圖

讓我用 AI 產生一個部署流程的視覺化：

開發者 push 程式碼
         ↓
GitHub Actions 觸發
         ↓
   ┌────────────┐
   │ 品質檢查   │ → ESLint + TypeScript
   └────────────┘
         ↓
   ┌────────────┐
   │ Build 驗證 │ → Next.js Build
   └────────────┘
         ↓
    分支判斷
    ↙      ↘
PR 分支     Main 分支
   ↓           ↓
Preview 部署  Production 部署
   ↓           ↓
測試環境      正式環境

資料庫遷移的處理

這是一個重要但容易被忽略的問題：資料庫 schema 變更怎麼辦？

我問 AI：「Supabase 的 schema 變更要怎麼跟部署整合？」

Claude 的回答：

Supabase 有幾種方式處理 schema 遷移：

方案一：Supabase Dashboard（適合早期）
- 直接在 Supabase Dashboard 修改
- 簡單直覺，適合快速迭代

方案二：Supabase CLI + Migration Files（推薦）
- 把 schema 變更寫成 migration files
- 加入 CI/CD pipeline
- 可追蹤、可回溯

我建議現階段用方案一，
MVP 穩定後再導入方案二。

這個建議很實際。Solo Sprint 就是要快，不要被流程綁死。

Solo Sprint 的部署心法

經過今天的實踐，我體會到 Solo Sprint 部署的幾個原則：

1. 選對平台，事半功倍

Next.js + Vercel 的組合讓部署變得極其簡單。如果我選 Express + AWS，可能要花三天處理部署。

2. 自動化優先，手動零次

一旦設定好 GitHub Actions，之後每次 push 都是自動的。這就是 AI-DLC Sprint 的精神：讓電腦做重複的事。

3. Preview 部署超級重要

每個 PR 都有獨立環境，可以讓測試者（或未來的自己）先看看效果，大大降低了「上線即災難」的風險。

4. 監控可以晚點做，但要先規劃

現在不需要複雜的監控系統，但要知道未來怎麼加。這就是為什麼 AI 幫我設計了 /api/health endpoint。

當 MVP 完成時，我只需要：

git add .
git commit -m "feat: MVP complete"
git push origin main

30 秒後，PocketSmart 就上線了。

AI-DLC Sprint 第六環節的收穫

Deployment 不只是「把程式碼放到伺服器上」，而是：

• 建立可靠的自動化流程
• 確保程式碼品質
• 提供安全的測試環境
• 規劃未來的擴展性

AI 在這個環節扮演了三個角色：

1. DevOps 顧問：設計最適合的部署策略
2. 自動化工程師：撰寫 GitHub Actions workflow
3. 風險管理師：提醒潛在的問題和解決方案

寫在最後

回顧這七天的 AI-DLC Sprint：

• Day 1：從模糊想法到清晰需求
• Day 2：PRD 文件化
• Day 3：Event Storming + BDD 場景
• Day 4：UI/UX 設計哲學
• Day 5：架構設計
• Day 6：Solo Sprint 極速開發
• Day 7：自動化部署

我們走完了完整的產品開發流程。雖然 PocketSmart 還沒完成，但框架已經建立。接下來只需要填充功能，一步一步實現 User Story。