無法將工作項分配給 Azure DevOps 中的發布

Question

我來自使用 Rally 和 Pivotal Tracker。 在這兩種情況下，我都可以將工作項分配給 Releases 作為規划工具，並擁有已部署工作項的歷史記錄。

盡管 Microsoft 提供了所有關於 Azure DevOps 的高度具體的指導，但對於如何針對未來版本組織工作卻沒有提及。 我什至看不到將工作項與發布相關聯的地方。 是否有我在所有文檔中遺漏的內容，或者是否有一些比僅使用標簽來主動針對發布進行計划更強大的變通策略？ 還是 Microsoft 期望我使用一些單獨的產品管理工具來根據版本管理工作項？

Answer 1

有多種技術可以實現這一點，而不是“一種方式”：

1. 使用父迭代路徑對您針對某個版本計划的迭代進行分組。 當您在開始下一個版本之前完全完成一個版本時，這最有效。 否則，它通常會因多次活動迭代而變得一團糟。

    Backlog Iteration + Release 1.0 + Sprint 1 + Sprint 2 + Sprint 3 + Release 2.0 + etc

——

2. 使用標簽發布。 在該版本中包含的所有工作項的頂部添加一個標記 [Release 1.0]，這是最靈活的選項之一。

3. 使用 Azure Pipelines 跟蹤哪些工作項與哪些 Git 提交相關聯，從而包含在哪些構建工件中。 跨環境跟蹤構建工件，通過查看中間構建來查看哪些工作項已部署到環境中。

4. 將自定義工作項字段添加到要跟蹤的工作項類型。 您可以更改正在使用的工作項流程，並且可以向工作項添加一個字段，您可以在其中指定版本名稱/編號。 有可用的自定義控件可以將版本號范圍限定為特定列表，或者可以從任何 REST API 獲取允許的值。

如您所見，Azure DevOps 在使用模式上更加靈活，但這也意味着有時您需要“找出最適合您的團隊的方法”。

您可能感興趣的另一個擴展是Bravo Notes 擴展。 或者可以根據您的工作項數據、提交和/或管道工件生成發行說明的其他擴展之一。