Azure DevOps 藍圖
| 新功能 | 開發人員社群 | DevOps 部落格檔 | |
產品藍圖
這項功能清單可查看我們的藍圖。 它會識別我們目前正在處理的一些重要功能，以及您預期會看到這些功能的粗略時間範圍。 它並不全面，但旨在提供一些關鍵投資的可見度。 在頂端，您將找到我們大型多季計劃的清單，以及其細分的功能。 進一步了解我們計劃的重要功能完整清單。
每項功能都會連結到一篇文章，您可以在其中深入瞭解特定專案。 這些功能和日期是目前的計劃，而且可能會變更。 時間範圍數據行會反映我們預期功能可供使用的時間。
方案
適用於 Azure DevOps 的 GitHub Advanced Security
Azure DevOps 的 GitHub 進階安全性 （GHAS） 現已正式推出。 任何專案集合管理員現在都可以從 [項目設定] 或 [組織設定] 中為其組織、專案和存放庫啟用進階安全性。 您可以在我們的 檔中深入瞭解如何設定適用於 Azure DevOps 的 GitHub 進階安全性。
我們預期要傳遞的新功能包括：
| 功能 | 區域 | 季 |
|---|---|---|
| 顯示包含新引進進階安全性結果之提取要求的內容批注 | 適用於 Azure DevOps 的 GitHub Advanced Security | 2024 年第 4 季 |
| 判斷偵測到的合作夥伴秘密有效性 | 適用於 Azure DevOps 的 GitHub Advanced Security | 2024 年第 4 季 |
| 使用 Dependabot 安全性更新自動修正偵測到的相依性掃描弱點 | 適用於 Azure DevOps 的 GitHub Advanced Security | 未來 |
將認證竊取的相關風險降至最低
Azure DevOps 支援許多不同的驗證機制，包括基本身份驗證、個人存取令牌 （PAT）、SSH 和 Microsoft Entra ID （先前稱為 Azure Active Directory） 存取令牌。 從安全性觀點來看，這些機制不會同樣建立，特別是當涉及到認證竊取的可能性時。 例如，PAT 之類的非預期認證外泄可讓惡意執行者進入 Azure DevOps 組織，讓他們能夠存取原始程式碼等重要資產、轉向供應鏈攻擊，或甚至轉向危害生產基礎結構。 為了將認證竊取的風險降到最低，我們會將工作集中在下列領域的未來四個季度：
可讓系統管理員透過控制平面原則改善驗證安全性。
藉由新增對更安全替代方案的支持，減少 PAT 和其他可竊取秘密的需求。
深化 Azure DevOps 與 Microsoft Entra 識別碼的整合，以更妥善地支援其各種安全性功能。
避免需要在 Azure Pipelines 服務連線中儲存生產秘密。
| 功能 | 區域 | 季 |
|---|---|---|
| PAT 生命週期 API | 一般 |
2022 年第 4 季 |
| 個人存取權杖的控制平面 （PAT） | 一般 |
2022 年第 4 季 |
| 受控識別和服務主體支援 （預覽） | 一般 |
2023 年第 1 季 |
| 適用於 Azure 部署的工作負載身分識別同盟 （預覽） | 管線 |
2023 年第 3 季 |
| Azure Active Directory OAuth 的細微範圍 | 一般 |
2023 年第 3 季 |
| 受控識別和服務主體支援 （GA） | 一般 |
2023 年第 3 季 |
| Azure 服務連線的工作負載身分識別同盟 （GA） | 管線 |
2024 年第 1 季 |
| Docker 服務連線的工作負載身分識別同盟 | 管線 | 2024 H2 |
| 條件式存取原則的完整 Web 支援 | 一般 | 2024 H2 |
| 停用驗證方法的原則 | 一般 | 未來 |
改善的 Boards + GitHub 整合
現有的 Azure Boards + GitHub 整合已就緒數年。 整合是一個絕佳的起點，但不會提供我們的客戶習慣的可追蹤性層級。 根據客戶的意見反應，我們彙集了一組投資來加強這項整合。 我們的目標是要加以改善，讓選擇使用 GitHub 存放庫的 Azure Boards 客戶可以維持對等層級的可追蹤性，讓 Azure DevOps 中的存放庫。
這些投資包括：
| 功能 | 區域 | 季 |
|---|---|---|
| 從工作專案新增 GitHub 認可或提取要求的連結 | Boards |
2024 年第 1 季 |
| 顯示 GitHub 提取要求的詳細數據 | Boards |
2024 年第 1 季 |
|
改善搜尋和連結 GitHub 時的延展性 存放庫至 Azure DevOps 專案 |
Boards |
2024 年第 2 季 |
| GitHub 提取要求上的 AB# 連結 （預覽） | Boards |
2024 年第 2 季 |
| 從工作專案在 GitHub 存放庫上建立分支 | Boards |
2024 年第 3 季 |
| 支援具有數據落地的 GitHub Enterprise Cloud | Boards | 2025 年第 1 季 |
| ! 提及 GitHub 提取要求的支援 | Boards | 2025 年第 1 季 |
| 搭配 GitHub 存放庫使用 YAML 組建管線時顯示組建狀態 | Boards | 2025 年第 1 季 |
| 支援在合併 GitHub Pull Request 時進行狀態轉換 | Boards | 2025 年第 1 季 |
| 連結至 GitHub 分支時自動連結提取要求 | Boards | 2025 年第 1 季 |
| 使用 YAML 發行管線搭配 GitHub 存放庫時，將階段狀態報告至工作專案 | Boards | 未來 |
YAML 和發行管線功能同位
在過去的幾年裡，我們所有的管線投資都在 YAML 管線領域。 此外，我們的所有安全性改進都是 YAML 管線。 例如，使用 YAML 管線時，受保護 資源的 控制權（例如存放庫、服務連線等）掌握在資源擁有者手中，而不是管線作者。 YAML 管線中使用的作業存取令牌範圍限定於 YAML 檔案中指定的特定存放庫。 這隻是YAML管線可用的兩個安全性功能範例。 基於這些原因，我們建議透過傳統使用 YAML 管線。 對組建（CI）而言，透過傳統 YAML 的採用相當重要。 不過，許多客戶已繼續透過YAML使用傳統發行管理管線進行發行（CD）。 主要原因是兩個解決方案之間各種CD功能缺乏同位。 在過去的一年裡，我們解決了這一領域的幾個差距，特別是在 檢查中。 檢查是 YAML 管線中的主要機制，可閘道從一個階段升級至另一個階段的組建。 我們將在未來一年內繼續解決其他領域的差距。 我們的重點是用戶體驗、可追蹤性和環境。
| 功能 | 區域 | 季 |
|---|---|---|
| 檢查的稽核 | 管線 |
2022 年第 4 季 |
| 檢查中的自定義變數 | 管線 |
2023 年第 1 季 |
| 檢查延展性 | 管線 |
2023 年第 2 季 |
| 略過核准和檢查 | 管線 |
2023 年第 4 季 |
| 排序核准和其他檢查 | 管線 |
2024 年第 1 季 |
| 延遲核准 | 管線 |
2024 年第 1 季 |
| 重新執行單一階段 | 管線 |
2024 年第 1 季 |
| 階段的手動佇列 | 管線 |
2024 H2 |
| 階段層級並行 | 管線 |
2024 年第 3 季 |
| 階段層級可追蹤性 | 管線 | 2024 H2 |
| 檢查中的服務連線 | 管線 | 未來 |
| 檢查擴充性 | 管線 | 未來 |
所有功能
Azure DevOps Services
Azure DevOps Server
如何提供意見反應
我們很樂意聽到您對於這些功能的看法。 透過 開發人員社群回報任何問題或建議功能。
您也可以在 Stack Overflow 上的社群取得建議和您的問題。