Day 03 數位交付的起點：以 Issue Ticket 管理對齊業務需求

2026 iThome 鐵人賽

DAY 3

IT Operation

18th鐵人賽

16 瀏覽

在軟體開發裡面，Issue Ticket 其實就是我們常說的「工作單」或「任務卡」。

不管是工程師要幫系統加一個新功能，還是要修復一個 Bug，每一項工作都必須先有一張專屬的 Ticket。 這張單子就是整個開發流程的起點，也是所有紀錄的歷程。

如果每個人開工單都隨便亂寫，系統自動化就會大亂。所以我們必須在 Jira 或 Notion 這種工具裡，幫 Ticket 設好幾個必要的條件（欄位）：

任務 ID（像是編號 PROJ-123）：
- 就像是這張ticket的唯一的身份證字號。以後你開 Git 分支、送出 Pull Request（PR）時，名字都要帶上這個編號，大家才知道這堆程式碼是在解哪一個任務。
變更類型（Type，像是功能、修復、文件）：
- 標記這張單子到底是來「加新功能的（feat）」還是來「修 Bug 的（fix）」。後續自動化系統看到這個標籤，就會自動去更新版本號和產生修改紀錄（Change Log）或 Release Note。
狀態（Status，像是進行中、審查中）：
- 告訴大家這張單子現在卡在哪個階段。如果還沒完成，自動化系統就不准它部署上線。這部分可以把ticket以看板的形式列出，比較好可以看出每張ticket目前在哪個階段。
完成準則（DoD，Definition of Done）：
- 白紙黑字寫清楚「做到什麼地步才算完工」。這可以拿來當作自動化測試的依據，確保程式碼真的有達到要求。

為了將上述的標準化欄位與自動化思維落地，我們以客製化的 Notion 為例，說明如何將其轉化為 CI/CD 流程的起點：

資料庫屬性（Properties）的強型別化：在 Notion 建立 Task Database 時，必須利用 Select 或 Relation 屬性精準對應上述提到的欄位（如變更類型、優先順序）。透過嚴格的欄位格式，避免自由文本（Free text）帶來的格式混亂，確保後續 CI 工具透過 API 抓取資料時的準確性。
原生 GitHub 雙向同步：啟用 Notion 的原生 GitHub 整合功能。當開發者在 GitHub 建立 Pull Request 並在描述中輸入 Fixes PROJ-123（對應 Notion 的任務唯一 ID）時，Notion 端的任務狀態即可自動從「開發中」推進至「審查中（In Review）」。
API 驅動的自動化回填：結合 GitHub Actions 與 Notion API，當 CI 流程中的單元測試或安全掃描完成時，透過自動化腳本將測試結果（如覆蓋率、成功或失敗狀態）直接寫入 Notion 該任務的留言區。這讓非工程背景的 PM 也能在 Notion 上即時掌握品質數據。

我們提倡「單一任務原則」（Atomic Issue Principle），也就是讓一個 Issue 只對應一個修改目標。這能有效降低 Code Review 的難度，同時讓自動化流程在排查錯誤（Troubleshooting）時變得更加精確。

背景資訊結構化：在 Issue 中提供清楚且詳細的上下文。這對 GitHub Copilot 或 Cursor 等 AI 輔助開發工具非常關鍵，優質的工單描述能大幅提升 AI 產生程式碼的準確度與業務符合度。
DoD 的自動化驗證：將「完成準則」（Definition of Done）轉化為實際的測試腳本。當 CI 流程通過所有預設的驗收測試後，系統就能自動將 Issue 狀態更新為「待合併」或「已完成」。

在進階的 CI/CD 實踐中，我們會透過 Webhooks 讓 Issue 系統與版本控制系統緊密串聯，打造出流暢的自動化閉環：

自動狀態遷移：當開發者建立 Pull Request 時，系統會自動把相關聯的 Issue 標記為「進行中」。
測試結果回填：CI 執行完畢後，系統會自動把測試總結（Test Summary）與品質門禁報告（Quality Gate Report）以留言形式回填到 Issue 中，讓管理者與 QA 不用切換平台，就能隨時掌握專案進度。
部署後追蹤：當程式碼順利進入生產環境後，系統會自動關閉對應的 Issue，並標註這次上線的版本號。