從 PR 到上線：完整部署流程

你以為的「功能上線」vs 實際發生的事

你在下午三點提了一個需求：「幫我在商品頁加上庫存剩餘數量的提示，讓用戶有緊迫感。」

工程師回你：「好，我大概需要三天。」

三天後，你問：「功能好了嗎？什麼時候可以上線？」

工程師說：「Code 好了，PR 還在等 review，review 完要 merge，merge 完 CI/CD 才會跑，build 完再 deploy 到 staging，你們測完才能 deploy 到 prod。」

你一頭霧水。

這一課，就是把這整個過程攤開來，讓你看清楚每個步驟在做什麼。

---

完整流程圖

[工程師寫 Code]
       │
       ▼
[推上 Git Branch]
       │
       ▼
[發 PR（Pull Request）]── 等 Code Review ──▶ 有問題 ──▶ 修改後回來
       │（Review 通過）
       ▼
[Merge 進 main/master branch]
       │（自動觸發）
       ▼
[CI 跑自動化測試]── 測試失敗 ──▶ 通知工程師修復
       │（測試通過）
       ▼
[CD 自動 Build 映像檔]
       │
       ▼
[推送映像檔到 Registry]
       │
       ▼
[自動 Deploy 到 Staging 環境]
       │
       ▼
[QA / PM 在 Staging 測試]── 有問題 ──▶ 回 PR 流程
       │（測試通過）
       ▼
[Deploy 到 Production 環境]
       │
       ▼
[監控：確認指標正常]── 有異常 ──▶ Rollback！
       │（正常）
       ▼
[✅ 功能正式上線]

---

每個步驟的詳細說明

Step 1：工程師寫 Code & 推上 Git Branch

工程師在自己的電腦開發功能，完成後推到 Git 上一個獨立的分支（branch）。

你看到的： 什麼都看不到，功能還沒有任何環境能測。

如果卡住： 工程師說「開發中」超過預期時間，可以請他更新進度。

---

Step 2：PR（Pull Request）與 Code Review

工程師發起一個 PR，請其他工程師 review 程式碼。這是品質把關的重要步驟。

你看到的： 如果公司用 GitHub/GitLab，你可能看到 PR 的連結。

如果卡住： 沒有人 review 或 review 來回太多次，這是 PM 可以推動的點——提醒 review 的優先順序，尤其是有活動期限的功能。

---

Step 3：Merge 進主線

Review 通過後，工程師把這個 Branch 的改動合併（merge）進主要分支。

這個動作通常會自動觸發 CI/CD 流程。

---

Step 4：CI（持續整合）— 自動跑測試

CI（Continuous Integration）是一套自動化系統。Merge 完成後，它會：

• 自動執行所有單元測試
• 跑靜態程式碼分析
• 確認這次的改動沒有把舊功能壞掉

如果 CI 失敗： 自動通知工程師，不會繼續往下走。這是好事——問題被卡在這裡，比上線後才發現要好。

---

Step 5：CD（持續部署）— 自動 Build 和 Deploy

CI 通過後，CD（Continuous Deployment/Delivery）接手：

• 自動執行 Build，把新 Code 打包成映像檔
• 把映像檔推到 Registry
• 自動 Deploy 到 Staging（測試環境）

Staging 是一個跟正式環境盡量相同的測試環境，讓你在真實用戶看到之前先測試。

---

Step 6：QA / PM 在 Staging 測試

這裡就是你出場的時候了。

你在 Staging 環境測試新功能：

• 功能是否符合需求？
• 有沒有 UI 問題？
• 有沒有影響其他既有功能？

如果有問題： 回報給工程師，走修改 → PR → Merge → CI/CD 的循環。

---

Step 7：Deploy 到 Production

測試通過後，工程師（或 CD 自動）把映像檔 Deploy 到正式環境（Production），也就是真實用戶使用的系統。

需要多少時間： 通常幾分鐘。但有些公司有「滾動部署（rolling deploy）」，確保在部署過程中服務不中斷，時間可能長一點。

---

Step 8：監控與確認

部署完成後，工程師會盯著監控指標看幾分鐘：

• 錯誤率有沒有升高？
• 訂單成功率正常嗎？
• 伺服器的 CPU / 記憶體有沒有異常？

如果指標異常： 立刻 Rollback 回上一個版本，然後再查原因。

---

PM 在這個流程裡能做什麼？

階段	PM 的行動
PR Review 期間	確認 review 進度，如有死線請主動協調
Staging 測試	準備測試清單，確保核心 user flow 都跑過
決定上線時機	避開高流量時段（例如：大促期間不要 deploy 非必要功能）
上線後監控	觀察業務指標（轉換率、訂單數），不只看技術指標
出問題時	快速判斷是 Rollback 還是等工程師修，避免決策癱瘓

---

常見的「部署失敗」排查思路

當工程師說「deploy 失敗了」，身為 PM 你可以問：

1. 是 build 失敗還是 deploy 失敗？ — 影響後續修復時間不同
2. CI 的測試有沒有通過？ — 如果沒過，代表改動有問題
3. Staging 上有沒有驗過？ — 如果 staging 就有問題，為什麼走到 prod deploy？
4. 這次 deploy 包含幾個 PR 的改動？ — 改動越多，找問題越難；推動小批次部署
5. 可以 rollback 嗎？影響多大？ — 業務判斷，不是純技術判斷

---

練習題

---

AI 協作：學了這個，跟 AI 怎麼配合？

了解完整部署流程，讓你能和 AI 一起制定上線計畫、撰寫事後復盤報告，或分析哪個流程環節最常出問題。

你的人類優勢：

• 你知道業務的優先順序：哪個功能必須在特定日期上線，哪個可以推遲，AI 沒有這個業務 context
• 你能判斷 rollback 的業務代價：回滾一個版本會不會讓已上線的優惠活動失效、影響已下單的用戶

可以這樣跟 AI 說：

我們公司電商平台的部署流程是：開發 → PR Review → Merge → CI/CD → Staging 測試 → Production。最近每次 deploy 都要花 2-3 天等 Staging 測試。請幫我設計一份 Staging 測試清單範本，讓 PM 能在 2 小時內完成核心功能的驗收，覆蓋：商品瀏覽、加入購物車、結帳、訂單查詢四個核心流程。