NewAile 研發團隊協作與自動化操作規範

目標：提升效率、透明度與標準化

日期：2025年9月

我們為何需要這套規範？

核心目標

  • 減少手動更新：讓開發與測試人員專注於核心工作，無需頻繁手動更新 Jira 狀態。
  • 提升流程透明度：讓產品經理 (PM)、主管等所有利害關係人，能直接在 Jira 上看到功能的真實進度。
  • 確保流程一致性：標準化的自動流程能避免因人為疏忽導致的狀態不一致問題。
  • 強化可追溯性：從 Jira 工單可輕鬆追溯到所有相關的程式碼分支、提交、合併請求 (MR) 及部署紀錄。

議程

  1. 核心概念：分支管理策略
  2. 自動化核心：環境部署流程
  3. 實戰演練：標準化開發工作流程
  4. 特殊情況處理
  5. 現場操作示範
  6. Q&A

第一部分

核心概念：分支管理策略

主要分支定義

我們的程式碼庫圍繞兩個核心分支運作：

main (生產環境分支)

  • 極其穩定，只反映當前已成功部署到生產環境的程式碼。
  • 不允許直接提交。所有變更都必須透過從 release 或 hotfix 分支的合併請求 (Merge Request) 匯入。

release (預發布/整合分支)

  • 開發的核心分支，所有新功能開發的最終目的地。
  • CI/CD 流水線會持續監控此分支。
  • 是觸發向所有測試環境 (DEV, QA, UAT) 部署的來源。

臨時性分支

功能開發與修復在這些短期分支上進行：

feature/<ticket>-<desc> (功能開發分支)

  • 用途：開發單一功能或任務。
  • 來源：從 release 分支建立。
  • 終點：開發完成後合併回 release 分支。
  • 範例：feature/PROJ-123-add-user-login。

hotfix/<ticket>-<desc> (緊急修復分支)

  • 用途：修復生產環境的緊急 Bug。
  • 來源：從 main 分支建立。
  • 終點：修復後，必須同時合併回 main 和 release 分支。

分支管理流程圖

點擊此處在新分頁中查看分支管理流程圖

將在新視窗中開啟外部連結。

流程解說：

  • 所有新功能 (如 feature/PROJ-123) 皆由 release 分支出發。
  • 完成後合併回 release，並依序部署至 DEV, QA, UAT 環境。
  • release 分支驗證完畢後，再合併至 main 分支進行生產部署。
  • 緊急修復 (hotfix/PROD-126) 直接從 main 分支出發，修復後合併回 main 與 release。

第二部分

自動化核心：環境部署流程

各環境部署觸發機制

DEV (開發環境): 自動。feature 分支合併到 release 時觸發。

QA (測試環境): 手動。由 QA 主管在 release 分支上建立 qa-v1.1.0-01 格式的 Tag 觸發。

UAT (驗收環境): 手動。由 QA 主管在 release 分支上建立 uat-v1.1.1 格式的 Tag 觸發。

Production (生產環境): 自動。release 分支合併到 main 時觸發。PM 負責最終審批。

第三部分

實戰演練：標準化開發工作流程

Jira 狀態生命週期總覽

To Do ➔ Delivered ➔ Developing ➔ Developed ➔ QA-Testing ➔ PM-Testing ➔ Done

此流程的目標是讓 Jira 狀態自動反映程式碼的真實進度。

Step 1 & 2：從需求到開發

Step 1: 需求確立 (To Do ➔ Delivered)

  • 負責人：PM / 開發主管。
  • 操作：PM 在 Jira 上建立工單 (To Do)，當規劃進 Sprint 後，手動將狀態改為 Delivered。

Step 2: 開發開始 (Delivered ➔ Developing)

  • 負責人：開發人員。
  • Git 操作：從 release 分支建立新的 feature 分支。
  • 關鍵自動化規則：分支命名必須遵循 feature/<jira-issue-id>-<description> 格式。
  • 自動化效果：當此分支被推送到 GitLab，對應的 Jira 工單狀態會自動變為 Developing。

Step 3 & 4：從開發到完成

Step 3: 開發過程

  • Commit 訊息規範：每一次 git commit 的訊息中，必須包含 Jira 單號。
  • 保持同步：每日應透過 git pull --rebase origin release 將最新變更同步到自己的分支。

Step 4: 開發完成 (Developing ➔ Developed)

  • Git 操作：建立一個從 feature 分支合併回 release 分支的合併請求 (MR)。MR 標題必須包含 Jira 單號。
  • 自動化效果：MR 被合併後，觸發 DEV 環境部署。部署成功後，Jira 工單狀態自動變為 Developed。

Step 5 & 6：從測試到驗收

Step 5: QA 測試 (Developed ➔ QA-Testing)

  • 負責人：QA 主管。
  • Git 操作：在 release 分支上建立並推送 qa-* 的 Tag。
  • 自動化效果：觸發 QA 環境部署。部署成功後，相關 Jira 工單狀態自動變為 QA-Testing。

Step 6: PM 驗收 (QA-Testing ➔ PM-Testing)

  • 負責人：QA 主管 / PM。
  • Git 操作：在 release 分支上建立並推送 uat-* 的 Tag。
  • 自動化效果：觸發 UAT 環境部署。部署成功後，Jira 工單狀態自動變為 PM-Testing。

Step 7：上線發布

Step 7: 上線發布 (PM-Testing ➔ Done)

  • 負責人：PM / 技術主管。
  • Git 操作：建立從 release 到 main 的 MR，由 PM 進行最終審批。
  • 自動化效果：MR 合併後，觸發 Production 環境部署。部署成功後，相關 Jira 工單自動變為 Done 並關閉。

第四部分

特殊情況處理

Hotfix 緊急修復流程

生產環境 Hotfix

  1. 建立分支：立刻從 main 建立 hotfix/<ticket>-<desc> 分支。
  2. 修復與部署：修復後，將 hotfix 分支合併回 main，自動觸發部署。
  3. 同步程式碼：非常重要！ 將 hotfix 分支也合併回 release 分支。

UAT 環境 Hotfix

  1. 從 release 對應的 UAT commit 拉出 Hotfix 分支。
  2. 在 Hotfix 分支上觸發新的 UAT Tag 來部署驗證。
  3. 驗證無誤後，將 Hotfix 分支合併回 release 分支。

如何處理分支偏離 (Divergence)？

問題：當你的 feature 分支開發時間較長，release 分支可能已經更新了很多次，導致你的分支與主幹差異越來越大。

解決策略：頻繁地同步 release

  • 習慣：養成每天或每兩天就同步一次的習慣。
  • 推薦指令：git pull --rebase origin release。
  • rebase 的優點：保持乾淨線性的提交歷史、更容易解決衝突。
  • 責任歸屬：解決衝突的責任永遠在於發起合併的 feature 分支開發者。

第五部分

現場操作示範

✨ 開發者小幫手

讓 AI 協助您產生符合規範的指令與訊息。

Live Demo

場景一：一個標準功能的完整生命週期

  1. PM 將 Jira 工單移至 "Delivered"。
  2. 開發者建立 feature/PROJ-XXX-... 分支 (觀察 Jira 自動變更為 "Developing")。
  3. 開發者提交帶有 Jira 單號的 commit。
  4. 開發者建立 MR 並合併至 release (觀察 Jira 自動變更為 "Developed")。
  5. QA 主管打上 qa- Tag (觀察 Jira 自動變更為 "QA-Testing")。
  6. QA 主管打上 uat- Tag (觀察 Jira 自動變更為 "PM-Testing")。
  7. PM 批准 MR 從 release 到 main (觀察 Jira 自動變更為 "Done")。

第六部分

Q&A

Q&A

有任何問題嗎？

感謝聆聽！