為什麼要先建立部署流程？

在過去的接案經驗中，我常常是把所有功能都寫完才開始考慮部署，結果遇到很多問題：

• 環境差異：本地運行正常，部署後出現各種問題
• 除錯困難：沒有容器化，問題很難重現
• 整合延遲：外部服務（如第三方支付 API）到最後才測試

這次學乖了，先建立完整的部署流程，再逐步完善業務邏輯。這樣每個功能完成後就能立即部署測試。

檢視現有專案實作

經過前三天的建置，我們已經有了：

✅ 完整的 Monorepo 結構

kyong-saas/
├── apps/
│   ├── kyo-otp-service/    # Fastify + TypeScript
│   └── kyo-dashboard/      # React + Vite
└── packages/
    ├── kyo-core/          # OTP 服務邏輯
    ├── kyo-types/         # Zod schemas
    └── kyo-config/        # 設定工具

✅ OTP 核心業務邏輯

• OTP 生成與驗證
• Redis 速率限制 (Token Bucket)
• 三竹簡訊 API 整合 (Stub + 實際)
• ORPC 型別安全 API

讓我檢查一下核心功能是否完整：

# 測試 OTP 服務
cd kyong-saas
pnpm -w --filter kyo-otp-service dev

檢視現有容器化基礎

讓我們看看目前專案的容器化狀況：

1. 現有的 Dockerfile

# apps/kyo-otp-service/Dockerfile (目前狀況)
FROM node:20-alpine AS base
WORKDIR /app
COPY . .

# Placeholder build (actual depends on workspace tooling)
CMD ["node", "dist/index.js"]

這是一個基礎版本，我們需要優化它來支援 pnpm workspace：

2. 現有的 Docker Compose 環境

# docker-compose.yml (目前狀況)
version: '3.9'
services:
  redis:
    image: redis:7-alpine
    ports:
      - '6379:6379'
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: kyo
      POSTGRES_PASSWORD: kyo
      POSTGRES_DB: kyo
    ports:
      - '5432:5432'

目前的設定很簡潔，提供了基本的 Redis 和 PostgreSQL 服務。

檢視現有的簡訊整合

讓我們看看 @kyong/kyo-core 中已經實作的簡訊功能：

// packages/kyo-core/src/sms.ts (已存在)
// 包含 MitakeSmsProvider 和 StubSmsProvider 的實作

目前已經有 Stub 和實際的 Mitake 整合，可以透過環境變數切換。

本地測試流程

3. 基本測試

# 啟動基礎服務
docker-compose up -d

# 啟動 OTP 服務（本地開發模式）
cd kyong-saas
pnpm -w --filter kyo-otp-service dev

# 測試基本 API（如果已實作健康檢查）
curl http://localhost:3000/api/health

目前專案的核心邏輯已經完整，主要是容器化和部署的部分需要逐步完善。

今日成果檢查

✅ 基礎容器化：Docker Compose 提供 Redis + PostgreSQL
✅ 核心業務邏輯：OTP 服務已可本地運行
✅ API 結構：REST API 基礎框架完成
✅ 外部服務整合：三竹簡訊 API 支援（Stub 模式）

目前的開發策略

我們採用 "核心邏輯優先" 的策略：

1. 先確保業務邏輯正確：OTP 生成、驗證、速率限制
2. 再完善部署流程：容器化、CI/CD、監控
3. 最後優化與擴展：效能優化、進階功能

這樣的好處是可以快速驗證產品可行性，避免過早最佳化。

下一步規劃

明天（Day5）我們將：

1. 完善 Dockerfile，支援 pnpm workspace 建置
2. 建立 AWS ECR Repository
3. 初步設定 ECS Task Definition