Release Tracker 流程深度分析

2026-02-23

Release Tracker 流程深度分析

📋 概述

這是一個完整的軟體發布管理流程（Release Management Flow），主要使用 Notion 作為核心管理工具，搭配 Slack 通知、n8n 自動化，以及多個手動流程節點。

全體成員名單

姓名職稱 / 角色主要職責
David專案負責人Linear 環境建置、導入計劃推進
SherridyPO、RM（流程顧問）提供 Release Tracker 流程知識、協調版本發布
ShawnPO、送審人功能規劃、App Store 送審
Fei ChenQA測試流程、品質把關
JimmyQA（自動化測試）Fundamental Automated Testing
EzouCTO重要功能 Code Review
RichardiOS RDiOS 開發
EriciOS RDiOS 開發
TolynAndroid RDAndroid 開發
KennethAndroid RDAndroid 開發
XiangServer RDServer 開發
KeithServer RDServer 開發
TommyServer RDServer 開發
MattWeb RDWeb 開發
TiffanyPD（產品設計師）視覺設計
ZiPD（產品設計師）視覺設計

🎯 核心工具生態系統

主要工具

輔助工具

🔄 完整流程圖（13 個主要節點）

graph LR
    A[Planning] --> B[RM 決定版本號與列車週期]
    A --> C[QA 展測項]
    B --> D[In Development]
    C --> D
    D --> E[Ready for Test]
    E --> F[Testing]
    F --> G{測試結果}
    G -->|通過| H[測試報告 → Ready for Release Build]
    G -->|失敗| I[測試報告 → Ready for Fix]
    I --> J[Bug fix → 包版本]
    J --> E
    H --> K[Ready for Release Build]
    K --> L[Ready for Release]
    L --> M[Release]
    M --> N[Released]

📝 各節點詳細解析

1️⃣ Planning（規劃階段）

負責人：PO

觸發時機：Sprint Planning 完成後

主要操作：

  1. 在 Notion Release Tracker Database 新增功能項目

  2. 填寫必要資料：

    • Title（功能名稱）
    • 簡述功能
    • 系統（iOS/Android/Server/Web）
    • 負責工程師
    • 功能狀態：Planning
    • 測試注意事項（PO 初始填寫，RD 在開發中持續補充）
    • 預計交付時間
    • 負責設計師

  3. 頁面內容包含：

    • Epic
    • 設計文件（Figma spec）
    • Dev 文件
    • 埋點列表
    • Issue report

完成標準：功能狀態設為 Planning

🔑 測試注意事項欄位說明：

「測試注意事項」是一個持續更新的欄位，生命週期橫跨多個節點：

  • Planning 階段（PO 填寫）：從需求角度說明哪些場景需要特別測試
  • In Development 階段（RD 補充）：從技術實作角度補充，例如：依賴的 API 邊界條件、特定裝置相容性問題、舊資料遷移邏輯等
  • QA 展測項 / Testing 階段（QA 讀取）：QA 在展列測項和執行測試時，都要參考此欄位的最新版本

這個欄位是 PO 和 RD「主動告知 QA 要特別注意什麼」的溝通管道，讓測試更有針對性。

相關自動化：

2️⃣ RM 決定版本號與列車週期

負責人：RM（Release Manager）

協作角色：PO

觸發時機：

主要操作：

  1. 盤點 QA 產能與各版本列車剩餘座位
  2. 填入該功能的：
    • 版本號（例如：5.7.0）
    • 測試修復週期（測試+修復的時間範圍）
  3. （原本規劃通知 PO，但目前未執行）

完成標準：

相關自動化：

注意事項：

3️⃣ QA 展測項

負責人：QA

觸發時機：

主要操作：

步驟 1：建立測試報告模板

步驟 2：展列測項

🔑 測試注意事項在 QA 展測項中的用途：

「測試注意事項」是工程師（PO 和 RD）特別附註給 QA 的說明，主要內容包括：

  • 這個功能的重點觀測項目（哪些地方最容易出問題）
  • 特殊邊界條件（哪些情況下行為會不同）
  • 技術實作上的注意事項（如：依賴的 API、相容性限制）
  • 已知限制（哪些行為是預期的，不需要當 bug 回報）

QA 在展列測項時，應把「測試注意事項」裡的每一條，都轉換成具體的測試項目或測試情境，確保這些特別注意的點都有被測試覆蓋。

注意：由於 RD 在開發過程中會持續補充測試注意事項，QA 在實際測試（收到 Ready for Test 通知）時，應再次確認此欄位是否有新增內容，不要只看展測項時的舊版本。

步驟 3：合併同版本測試報告

步驟 4：標記完成

完成標準：

待確認問題：

David 提問：QA 展測項時，是否已有版本號？並依據版本號建立測試報告的測項內容？

  1. Planning 後到版本號出來前，先使用 展列測試大綱用 展列每個功能的測項
  2. 該功能確定版本號後，把所有相同版本號的 展列測試大綱用 文件整合成一個包含版本號的測試報告 Forest.now 測試報告（版本號）
  3. 後續進行測試或修復，皆以測試報告為主
  4. Sherridy 補充：-> 不用一定等版本號就可以展測項了，只是會在版本號確認時把測項合併到該版本號的測試報告

4️⃣ In Development（開發中）

負責人：RD（工程師）

觸發時機：Planning 完成後

主要操作：

  1. 根據功能內容進行開發（以功能為單位）
  2. 開發過程中補充「測試注意事項」欄位（詳見下方說明）
  3. 開發完成後進行 PR Review
  4. 視功能範圍決定是否包版，提供 PO/PD Review
  5. 通過 PO/PD Review 後包版

需要資料：

完成標準：

🔑 RD 在開發中補充「測試注意事項」：

RD 在開發過程中，如果發現任何 QA 在測試時需要知道的事，應即時補充到 Release Tracker 的「測試注意事項」欄位。

典型的 RD 補充內容包括：

  • 這個功能依賴了哪個 API，建議測試時確認 API response 的各種狀態（成功、失敗、網路錯誤）
  • 特定 OS 版本或裝置型號的相容性注意事項
  • 舊資料遷移邏輯，需要特別驗證升級情境（從舊版本升級到新版本時）
  • 已知的限制或暫時的 workaround（QA 不需要當成 bug 回報的情況）
  • 某個功能的邊界條件（例如：輸入超過 100 個字時會截斷，是預期行為）

這個補充動作是 RD 對 QA 的主動告知，有助於提升測試品質，減少因資訊不對稱造成的誤報或漏測。

相關自動化：

平台差異注意事項：

5️⃣ Ready for Test（準備測試）

負責人：RD

協作：n8n automation

觸發時機：開發完成並包版

iOS 流程：

  1. RD 於 Firebase 包版
  2. RD 在 #forest_ios_testcenter 手動發訊息： 
    [版本號] in Firebase for QA
（版本內容）
  3. MessageTracker bot 自動發出訊息（n8n automation）： 
    @Fei Chen @jimmy 請開始測試這個版本
QA Checklist:
- Item1
- Item2

Android 流程：

  1. RD 於 GitHub 發送版本（release branch push 帶 tag）
  2. GitHub Actions 自動執行 CI/CD
  3. Test Center Bot 自動發送訊息到 #forest_android_testcenter：
    • App 名稱：Forest Android
    • App 版本：5.7.0-ALPHA4
    • App 連結：APK 下載連結（GP 版、CN 版）
    • 測試報告連結
    • 版本資訊
    • @ QA 成員
  4. MessageTracker bot 自動發出 QA Checklist

🔑 Android ALPHA 版本號機制說明：

Android 的 Ready for Test 自動通知是透過版本號後綴觸發的，不是 RD 手動發訊息。

觸發條件：版本號符合 [版本號]-ALPHA[序號] 格式

  • 格式範例：5.8.0-ALPHA2、5.7.1-ALPHA1
  • 只有版本號包含 -ALPHA 後綴的 Build，才會自動觸發通知給 QA
  • 不含 -ALPHA 的版本號（如正式版 5.8.0）不會觸發此機制

這個機制讓 Android 的測試通知完全自動化，RD 只要打正確格式的版本號，Bot 就會自動通知 QA，不需要手動發 Slack 訊息（這是 iOS 和 Android 流程最大的差異之一）。

Server & Web 流程：

  1. RD 手動在 #forest_serverweb_testcenter 通知功能上 Staging
  2. 訊息範例： 
    [同步] Backend 服務 5 分鐘後會將以下功能更新上 staging
任務系統 bug 修復
Note: 麻煩 @Fei Chen 再複驗一下
cc/ @Shawn @Sherridy @jimmy @Fei Chen
  3. 無自動化訊息

預估耗時：依版本內容不同，約 2-5 分鐘（推估）

完成標準：

相關自動化：

6️⃣ Testing（測試中）

負責人：QA（Fei Chen, Jimmy）

協作角色：RD, PO（需要釐清問題時）

觸發時機：

主要操作：

  1. QA 收到通知後，開啟測試報告 Forest.now 測試報告（版本號）
  2. 依照測試報告中的 ▶︎此次功能測試 測項逐項測試
  3. 測試過程中記錄問題：
    • 在 Slack Thread 留言確認問題
    • 在 Notion 測試報告透過 Comment 備註
  4. 完成所有測項測試
  5. 判斷測試結果：
    • ✅ 沒問題 → 更改狀態為 Ready for Release Build
    • ❌ 需要修復 → 在測試報告列出問題，更改狀態為 Ready for Fix

需要資料：

預估耗時：依功能大小與測項數量而定

完成標準：

決策分支：

相關自動化：

注意事項：

測試過程中發現的問題，多先在 Slack Thread 與 RD & PO 討論與確認細節。若訊息過多，需要花額外時間尋找該訊息內容。

7️⃣ 測試報告（Testing 完成後的產出）

負責人：QA

通知對象：RD, PO

觸發時機：

主要操作：

步驟 1：建立測試報告頁面

步驟 2：填寫測試報告 Metadata

步驟 3：撰寫測試報告內容結構

步驟 4：根據測試結果更新狀態

✅ 若所有測試通過：

  1. 更新狀態為 Ready for Release Build
  2. 觸發自動化，在 Test center slack channel 發佈： 
    @iosdevs iOS 測試完畢囉，東西都沒問題了五告讚，可以包版或是上正式環境啦！
測試報告: [Notion 連結]
附上 QA Checklist

❌ 若測試發現問題：

  1. 在 Test Issue 資料庫記錄所有問題
  2. 更新狀態為 Ready for Fix
  3. 觸發自動化，在 Test center slack channel 發佈： 
    @iosdevs iOS 測試完畢囉，點擊測試報告以查看 issue
測試報告: [Notion 連結]

步驟 5：自動化發送 Slack 通知

步驟 6：RD 查看測試報告

預估耗時：依測試範圍不同

完成標準：

相關自動化：

注意事項：

少數情況下 QA 會手動在 Slack Channel 填寫版本的測試狀態，若有注意到特定項目，通常會在 Slack Thread 留言詢問

8️⃣ Ready for Fix（需要修復）

負責人：QA

通知對象：RD

觸發時機：

主要操作：

  1. QA 完成測試後，發現功能有問題
  2. 在測試報告中列出需要修復的內容：
    • 問題描述
    • 截圖或錄影
    • 嚴重程度標註
  3. 在 Notion Release Tracker 將功能狀態更新為 Ready for Fix
  4. 自動化發送 Slack 通知：
    • iOS：@iosdevs iOS 測試完畢囉，點擊測試報告以查看 issue + Notion 連結
    • Android：Android 測試完畢囉，點擊測試報告以查看 issue + Notion 連結
    • Server/Web：@serverdevs @matt server/web 測試完畢囉，點擊測試報告以查看 issue + Notion 連結
  5. RD 收到通知後，點擊測試報告連結查看問題
  6. RD 對問題有疑問時，在 Slack Thread 討論
  7. RD 排程修復，重新包版，回到 Ready for Test 狀態

預估耗時：5-10 分鐘（更新狀態與記錄問題）（推估）

完成標準：

決策分支：

相關自動化：

9️⃣ Ready for Release Build（準備包正式版）

負責人：QA, RD

觸發時機：

主要操作：

步驟 1：QA 更新狀態

步驟 2：Notion 自動化發送 Slack 通知

iOS（自動化 25）：

@iosdevs
iOS 測試完畢囉，東西都沒問題了五告讚，可以包版或是上正式環境啦！
附上 Notion 功能文件連結

Android（自動化 24）：

@androiddevs
Android 測試完畢囉，可以包正式版
附上 Notion 功能文件連結

Server/Web（自動化 26）：

@serverdevs
Server/Web 東西都沒問題了五告讚，可以包版或是上正式環境啦！

步驟 3：RD 開始包正式版

步驟 4：RD 包版完成後更新狀態

需要資料：

預估耗時：待確認（包版時間因平台而異）

完成標準：

決策分支：

相關自動化：

注意事項：

🔟 Ready for Release（準備提交審核）

負責人：RD

執行提交審核：Shawn

觸發時機：RD 完成 Ready for Release Build 階段的包版作業

主要操作：

步驟 1：RD 確認版本已準備好

步驟 2：RD 更新 Notion 狀態

步驟 3：iOS 手動通知

步驟 4：等待 Shawn 提交版本到商店審核

需要資料：

預估耗時：5 分鐘（更新狀態）（推估）

完成標準：

決策分支：

注意事項：

1️⃣1️⃣ Release（正式發布）

負責人：Shawn（提交審核與發布）

通知對象：全團隊（透過 #forest_log）

觸發時機：Notion 功能狀態為 Ready for Release，Shawn 提交審核

主要操作：

步驟 1：Shawn 提交版本到商店審核

步驟 2：等待商店審核

步驟 3：審核通過後，執行正式發布

步驟 4：Shawn 在 #forest_log 頻道發布通知

iOS v[版本號] released
[發佈內容]

Android v[版本號] released
[發佈內容]

步驟 5：Notion 自動化更新功能項目

需要資料：

預估耗時：待確認（iOS/Android 不同）

完成標準：

決策分支：

相關自動化：

注意事項：

1️⃣2️⃣ Rolling Release（漸進式發布）

狀態：目前已少用

相關自動化：

1️⃣3️⃣ Released（已發布）

觸發時機：正式版本已在 App Store / Google Play 釋出

相關自動化：

🤖 自動化清單（26 個自動化）

Notion 自動化

編號名稱觸發條件執行動作
1測完通知 (SHDY)功能狀態 = Ready for FixSlack 通知 Sherridy
2測完通知 (Shawn)功能狀態 = Ready for FixSlack 通知 Shawn
3開始 rolling 時間功能狀態 = Rolling設定開始 Rolling 日期
4發布時間功能狀態 = Released設定正式發布日期
6Rolling 日期編輯通知開始 Rolling 日期被編輯Slack 通知
7發布日期編輯通知正式發布日期被編輯Slack 通知
8Auto generate released_at功能狀態 = Released設定 released_at
9Auto generate rolled_at功能狀態 = Rolling設定 rolled_at
10Auto link with DORA Dashboard已新增頁面建立 CFR、LT 等連結
11iOS 版本號編輯通知iOS 版本號被編輯Slack 通知 + Webhook
12Android 版本號編輯通知Android 版本號被編輯Slack 通知 + Webhook
13QA Finished → Ready for Release Build多國翻譯已勾選 + QA status 特定狀態設定功能狀態
14Ready for Test → QA status功能狀態 = Ready for Test設定 QA status
15QA status → Ready for FixQA status = Ready for Fix設定功能狀態
16QA status → Ready for FixQA status = Ready for Fix設定功能狀態
17Ready for Test 通知功能狀態 = Ready for TestSlack 通知 QA
18QA Finished → Waiting for TranslationQA Finished + 多國翻譯未勾選設定功能狀態
19Testing 狀態同步QA status = Testing設定功能狀態 = Testing
20QA Finished → Ready for Release BuildQA status = Finished + 多國翻譯已勾選設定功能狀態
21Server/Web 測完通知功能狀態 = Ready for FixSlack 通知 + Webhook
22Android 測完通知功能狀態 = Ready for FixSlack 通知 + Webhook
23iOS 測完通知功能狀態 = Ready for FixSlack 通知 + Webhook
24Android 可包正式版功能狀態 = Ready for Release BuildSlack 通知 + Webhook
25iOS 可包正式版功能狀態 = Ready for Release BuildSlack 通知 + Webhook
26Server/Web 可包正式版功能狀態 = Ready for Release BuildSlack 通知 + Webhook

n8n 自動化

👥 角色職責對照表

角色全名/說明主要職責
POProduct Owner功能規劃、需求定義、Review
RMRelease Manager (Sherridy)版本規劃、列車週期管理、QA 產能管理
RDResearch & Development (工程師)功能開發、包版、送審準備
QAQuality Assurance (Fei Chen, Jimmy)測試計畫、執行測試、測試報告
PDProduct Designer設計 Review
MKMarketing多國翻譯確認
Shawn送審負責人提交商店審核、正式發布

🔑 關鍵決策點與分支

1. 測試結果判斷（Testing 之後）

2. 多國翻譯檢查（Ready for Release Build 之前）

3. 商店審核結果（Release）

📊 平台差異對照表

流程節點iOSAndroidServer/Web
測試版發布FirebaseGitHub Actions → APKStaging 環境
通知方式手動訊息自動化 Bot手動訊息
正式版準備TestFlightAPK/AAB + Jimmy 自動化測試直接發佈
審核流程App Store ConnectGoogle Play Console無需審核
送審負責人ShawnShawnRD 直接發佈

✅ 已確認問題（原待確認）

David 提問 × Sherridy 確認記錄：

  1. QA 展測項時間點 ✅ 已確認：

    Q：QA 展測項時間點是在 RM 決定版本號後？還是同時可以進行？

    A（Sherridy 確認）：不用一定等版本號就可以展測項了。QA 在 Planning 完成後即可開始展測項，先以「展列測試大綱用（功能名稱）」命名。版本號確認後再把同版本的測項合併到正式測試報告。

  2. 測試報告整合流程 ✅ 已確認：

    標準流程：

    1. Planning 後到版本號出來前，先使用「展列測試大綱用」展列每個功能的測項
    2. 該功能確定版本號後，把所有相同版本號的「展列測試大綱用」文件整合成一個包含版本號的測試報告 Forest.now 測試報告（版本號）
    3. 後續進行測試或修復，皆以測試報告為主

  3. 測試注意事項的更新責任 ✅ 已確認：

    • PO 在 Planning 時填寫初始版本
    • RD 在 In Development 階段持續補充（技術實作角度的注意事項）
    • QA 在展測項時和收到 Ready for Test 通知時，都應確認最新版本

  4. Android Ready for Test 觸發機制 ✅ 已確認：

    Android 透過版本號加上 -ALPHA 後綴自動觸發通知（如 5.8.0-ALPHA2），不需要 RD 手動發 Slack 訊息。這與 iOS 手動通知的方式不同。

📌 核心流程總結

完整生命週期（正常流程）

Planning (PO)
    ↓
RM 決定版本號與列車週期 (RM)
    ↓
QA 展測項 (QA)
    ↓
In Development (RD)
    ↓ PR Review + PO/PD Review
Ready for Test (RD 包版 + 通知)
    ↓
Testing (QA)
    ↓ 撰寫測試報告
Ready for Release Build (QA → RD)
    ↓ RD 包正式版
Ready for Release (RD → Shawn)
    ↓ Shawn 提交審核
Release (Shawn)
    ↓ 審核通過 + 發布
Released (完成)

異常流程（修復循環）

Testing (QA)
    ↓ 發現問題
Ready for Fix (QA → RD)
    ↓ RD 修復
Bug fix → 包版本 (RD)
    ↓ 重新包版
Ready for Test (回到測試)

💡 Linear 導入建議

詳細的 Linear 系統建置方案已獨立成文件： 👉 請參閱：Linear 系統建置方案

該文件包含：

🔗 相關文件與資料庫

Notion 資料庫

  1. Release Tracker Database（核心）

    • 功能追蹤
    • 狀態管理
    • 版本號管理

  2. 測試報告庫

    • 測試報告模板
    • 測試項目清單
    • 問題記錄

  3. Test Issue 資料庫

    • 問題追蹤
    • 嚴重性分級
    • 優先級管理

  4. Test Build 資料庫

    • 測試版本記錄

  5. Forest 優化測項資料庫

    • 標準測試情境

  6. 測試進度確認

    • 任務進度追蹤

Slack Channels

📝 流程優化建議

目前痛點識別

  1. iOS 手動訊息較多

    • 建議：增加自動化，如 Android 的自動化流程

  2. Slack Thread 討論訊息多

    • 建議：考慮使用 Linear Comments 集中討論

  3. 測試報告整合流程複雜

    • 建議：使用 Linear Sub-issues 自動整合

  4. 跨平台流程不一致

    • 建議：統一自動化流程

潛在改善方向

  1. 導入 Linear 作為主要 Issue Tracker

    • Notion 專注於文件與 Knowledge Base
    • Linear 專注於 Issue 追蹤與 Workflow

  2. 強化自動化

    • GitHub Actions → Linear 自動更新
    • TestFlight 上傳完成 → Linear 自動通知

  3. Dashboard 改善

    • 使用 Linear Insights 取代 DORA Dashboard
    • 即時追蹤版本進度

🎓 關鍵學習與洞察

這個流程的優勢

  1. ✅ 完整的追蹤機制：每個階段都有明確的負責人與完成標準
  2. ✅ 自動化通知完善：26 個自動化減少人工溝通成本
  3. ✅ 測試報告規範化：統一的測試報告格式
  4. ✅ 版本管理清晰：RM 統一管理版本號與列車週期

可能的挑戰

  1. ⚠️ 流程複雜度高：13 個主要節點，新人學習曲線陡峭
  2. ⚠️ 平台差異大：iOS/Android/Server/Web 流程不完全一致
  3. ⚠️ 手動步驟仍多：特別是 iOS 與 Server/Web
  4. ⚠️ Notion 效能：大量自動化可能影響 Notion 效能

📚 參考資料

最後更新：2026-02-13 整理者：Claude (AI Assistant) 版本：v1.0