一個完整專案從 0 到上線

是什麼？（這課把前面所有觀念串成一條真實的路）

前面每一課——SDLC、需求與 User Story、架構切分、Clean Architecture、SOLID、測試、Git 策略、CI/CD、監控——你都單獨學過了。但真實工作裡，它們不是各自獨立的知識點，而是同一條河流上的不同河段。這堂課不教新觀念，而是用一個你看得到、摸得著的具體專案，把這些觀念按照真實發生的順序串起來，讓你看見一個專案從「一句話的想法」走到「在 Production 穩定運行並持續改進」的全貌。

專案設定

我們要做一個員工請假系統（Leave Request System）的 Web API。情境如下：

• 員工可以提出請假申請（請假類型、起訖日期、事由）。
• 系統依照剩餘特休天數與請假規則做驗證。
• 主管可以核准或駁回，員工會收到通知。
• HR 可以查詢全公司的請假紀錄與統計。
• 技術棧：ASP.NET Core Web API、EF Core + SQL Server、部署到雲端容器服務。

這個題目剛好夠複雜（有規則、有狀態、有角色），又夠單純（不會讓你陷在細節裡），很適合當作總整理的載體。

全流程里程碑

各階段實際做什麼

構想與需求/User Story。 一切從一句話開始：「我們要讓請假不用再寫紙本」。但這句話無法開發。如同〈需求與 User Story〉那一課，我們要把它拆成可驗收的故事，例如「身為員工，我想線上提出請假，以便不用跑到 HR 櫃台」，並補上驗收條件（Acceptance Criteria）：特休不足時要擋下、跨年度請假要分段計算。這一步偷懶，後面所有努力都會做錯方向。

技術選型與架構設計。 確認用 ASP.NET Core 後，依照〈Clean Architecture〉那一課把系統切成四層：Domain（LeaveRequest 實體，內含「已核准不可重複申請」這類核心規則）、Application（SubmitLeaveRequestUseCase、定義 ILeaveRepository 介面）、Infrastructure（EF Core 實作 Repository、寄通知）、Presentation（Controller）。依賴一律指向內，並用 SOLID 的 DIP 讓內層只依賴介面。

建 repo 與分支策略。 初始化 Git，採〈Git 策略〉提到的 Trunk-Based Development + 短命分支：每個 User Story 開一條活不過兩三天的 feature 分支，盡快合回主幹，避免長壽分支累積巨大的合併衝突。

開發（Clean Architecture + TDD）。 從 Domain 規則開始，先寫測試再寫實作。遵循〈測試〉那一課的測試金字塔：大量快速的單元測試（驗證請假天數計算、狀態轉換）、適量整合測試（驗證 Repository 真的存得進資料庫）、少量端對端測試（驗證 API 從請求到回應的完整路徑）。同時謹記 YAGNI——第一版不做「多公司多租戶」這種還沒人要的功能。

PR 與 Code Review。 每條分支以小顆 PR 提交，CI 先自動跑測試與靜態分析，再由同儕審查可讀性、邊界情況與安全性。小 PR 才審得動、審得快。

CI/CD 到部署。 推上去後，CI 自動建置、跑測試、做安全掃描、產出容器映像（對應〈CI/CD 基礎〉）。通過後 CD 自動部署到 Staging 測試環境做整合與 UAT，確認無誤才用漸進式發布（藍綠或金絲雀）推上 Production。

監控與迭代。 上線不是終點。導入結構化日誌與告警（對應〈監控〉），追蹤錯誤率、延遲、請假核准耗時等指標。從真實使用數據與使用者回饋，決定下一個迭代要做什麼——回到需求那一步，形成循環。

關鍵設定範例

一個 User Story 的範例寫法：

標題：員工提出請假申請
身為 一名正職員工
我想 在系統上選擇請假類型與日期並送出
以便 不用填紙本表單跑 HR 櫃台
 
驗收條件：
- 特休餘額不足時，送出被擋下並顯示剩餘天數
- 起始日不可早於今天
- 送出成功後，直屬主管收到待審通知

對應的 .NET 解決方案結構（Clean Architecture 四層）：

LeaveSystem.sln
├─ src/
│  ├─ LeaveSystem.Domain/          # 實體與核心規則，零外部相依
│  ├─ LeaveSystem.Application/     # Use Case 與介面（ILeaveRepository）
│  ├─ LeaveSystem.Infrastructure/  # EF Core、Repository 實作、通知
│  └─ LeaveSystem.WebApi/          # Controller / Minimal API、DI 組裝
└─ tests/
   ├─ LeaveSystem.UnitTests/        # 大量單元測試（測試金字塔底層）
   ├─ LeaveSystem.IntegrationTests/ # 整合測試
   └─ LeaveSystem.EndToEndTests/    # 少量 E2E

一段精簡的 CI 設定片段：

name: ci
on:
  pull_request:
    branches: [ main ]
jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: "8.0.x"
      - run: dotnet restore
      - run: dotnet build --no-restore --configuration Release
      - run: dotnet test --no-build --configuration Release --collect:"XPlat Code Coverage"

整體流程圖

注意最後那條從監控指回開發者的箭頭——這就是讓專案持續變好的回饋迴圈，而不是上線即結束的單行道。

上線檢查清單

正式推 Production 前，逐項確認：

• 測試全數通過：單元、整合、E2E 在 CI 上綠燈。
• 覆蓋率達標：關鍵商業邏輯（請假計算、狀態轉換）覆蓋率符合團隊門檻。
• 安全掃描通過：相依套件弱點掃描、靜態分析無高風險項目。
• 設定與密鑰管理：連線字串、API 金鑰放在密鑰庫（如 Key Vault），不寫死在程式或 repo。
• 回滾計畫：知道出事時如何在數分鐘內退回上一版，且已實際演練過。
• 監控與告警就緒：日誌、指標、錯誤率告警都已接好並驗證會發出通知。
• 文件更新：API 文件、部署手冊、變更紀錄與 README 已同步。

常見誤區

實戰補充

Q：MVP（最小可行產品）該包含什麼？ A：只包含「能驗證核心價值」的最小功能集。以請假系統來說，MVP 就是「員工能送出申請、主管能核准/駁回」這條主線。報表、多語系、行事曆整合都可以晚點再做。判斷標準：拿掉它，這個產品還能不能驗證「數位化請假是否真的省事」？能，就先不做。

Q：第一版要不要做到完美？ A：不要。追求第一版完美會掉進過度設計（呼應 YAGNI），把時間花在還沒被驗證的需求上。正確做法是先做出夠用的版本上線，從真實使用中拿到回饋，再用一輪輪迭代逼近「對的」產品。能上線並持續改進，遠勝過完美卻遲遲不上線。

理解測驗

重點整理