Azure DevOps 藍圖
| 新功能 | 開發人員社群 | DevOps 部落格檔 | |
產品藍圖
這項功能清單可查看我們的藍圖。 它會識別我們目前正在處理的一些重要功能，以及您預期會看到這些功能的粗略時間範圍。 它並不全面，但旨在提供一些關鍵投資的可見度。 在頂端，您將找到我們大型多季計劃的清單，以及其細分的功能。 進一步了解我們計劃的重要功能完整清單。
每項功能都會連結到一篇文章，您可以在其中深入瞭解特定專案。 這些功能和日期是目前的計劃，而且可能會變更。 時間範圍數據行會反映我們預期 Azure DevOps Services 上提供此功能的時間;伺服器數據行會反映我們預期功能會在 Azure DevOps Server 中出貨時。
計畫
適用於 Azure DevOps 的 GitHub Advanced Security
Azure DevOps 的 GitHub 進階安全性 （GHAS） 現已正式推出。 任何專案集合系統管理員現在可以為其組織、專案和存放庫啟用進階安全性，從 Project 設定 或組織 設定。 您可以在我們的 檔中深入瞭解如何設定適用於 Azure DevOps 的 GitHub 進階安全性。
我們預計在即將到來的學期提供的新功能包括：
與 GHAS for-GitHub 類似，任何產生符合 SARIF 格式結果的第三方 開放原始碼 或商業安全性分析管線工作，都可以在進階安全性程式代碼掃描警示中樞顯示這些結果。 這可讓您從所有分析工具檢視存放庫程式代碼安全性警示的 Azure DevOps 內建單一窗格。
支援自訂 CodeQL 查詢。
偵測和封鎖更多種類的秘密。
將認證竊取的相關風險降至最低
Azure DevOps 支援許多不同的驗證機制，包括基本身份驗證、個人存取令牌（PAT）、SSH 和 Microsoft Entra ID（先前稱為 Azure Active Directory）存取令牌。 從安全性觀點來看，這些機制不會同樣建立，特別是當涉及到認證竊取的可能性時。 例如，PAT 之類的非預期認證外泄可讓惡意執行者進入 Azure DevOps 組織，讓他們能夠存取原始程式碼等重要資產、轉向供應鏈攻擊，或甚至轉向危害生產基礎結構。 為了將認證竊取的風險降到最低，我們會將工作集中在下列領域的未來四個季度：
可讓系統管理員透過控制平面原則改善驗證安全性。
藉由新增對更安全替代方案的支持，減少 PAT 和其他可竊取秘密的需求。
深化 Azure DevOps 與 Microsoft Entra ID 的整合，以更妥善地支援其各種安全性功能。
避免需要在 Azure Pipelines 服務連線中儲存生產秘密。
| 功能 | 區域 | 服務 | 伺服器 |
|---|---|---|---|
| PAT 生命週期 API | 一般 |  2022 年第 4 季 |
N/A |
| 個人存取權杖的控制平面 （PAT） | 一般 | 2022 年第 4 季 |
2022.1 |
| 受控識別和服務主體支援 （預覽） | 一般 | 2023 年第 1 季 |
N/A |
| 適用於 Azure 部署的工作負載身分識別同盟 （預覽） | Pipelines | 2023 年第 3 季 |
N/A |
| Azure Active Directory OAuth 的細微範圍 | 一般 | 2023 年第 3 季 |
N/A |
| 受控識別和服務主體支援 （GA） | 一般 | 2023 年第 3 季 |
N/A |
| Azure 服務連線的工作負載身分識別同盟 （GA） | Pipelines | 2024 年第 1 季 | N/A |
| Docker 服務連線的工作負載身分識別同盟 | Pipelines | 2024 H1 | N/A |
| 條件式存取原則的完整 Web 支援 | 一般 | 2024 年第 1 季 | N/A |
| 停用驗證方法的原則 | 一般 | 未來 | N/A |
更新的Boards體驗
Azure Boards 用戶體驗已從頭開始更新。 雖然功能保持不變，但您可以預期更現代化的設計、回應式重排、改善的效能，以及改善的輔助功能。 本季，我們將推出 New Boards Hub 作為所有組織的默認體驗。
請注意，我們在 Boards 中出貨的大部分新功能僅適用於新增面板中樞。 這些投資包括：
| 功能 | 區域 | 服務 | 伺服器 |
|---|---|---|---|
| 移至位置 | Boards | 2022 年第 2 季 |
未來 |
| 將 [指派給虛擬人偶] 新增至卡片上的子專案 | Boards | 2022 年第 2 季 |
未來 |
| 移至柱形圖並移至泳道 | Boards | 2022 年第 1 季 |
未來 |
| 篩選至工作項目歷程記錄 | Boards | 2022 年第 3 季 |
未來 |
| 複製工作專案附件 URL | Boards | 2022 年第 4 季 |
未來 |
| 套用篩選條件時維護待辦項目階層 | Boards | 2022 年第 4 季 |
未來 |
| 能夠從 Web UI 變更連結類型 | Boards | 2022 年第 4 季 |
未來 |
| 工作流程看板上的泳道色彩 | Boards | 2023 年第 1 季 |
未來 |
| 工作流程看板上的泳道規則 | Boards | 2023 年第 2 季 |
未來 |
| 工作項目註出的 Markdown 編輯器 （預覽） | Boards | 2023 年第 2 季 |
未來 |
| 自動化小組工作項目規則 | Boards | 2024 年第 1 季 |
未來 |
| 根據預設，所有組織都會開啟新的 Boards 中樞 | Boards | 2024 年第 2 季 | 未來 |
改善的 Boards + GitHub 整合
現有的 Azure Boards + GitHub 整合已就緒數年。 整合是一個絕佳的起點，但不會提供我們的客戶習慣的可追蹤性層級。 根據客戶的意見反應，我們彙集了一組投資來加強這項整合。 我們的目標是要加以改善，讓選擇使用 GitHub 存放庫的 Azure Boards 客戶可以維持對等層級的可追蹤性，讓 Azure DevOps 中的存放庫。
這些投資包括：
| 功能 | 區域 | 服務 | 伺服器 |
|---|---|---|---|
| 改善的AB#{ID} 驗證 | Boards | 2023 年第 4 季 |
未來 |
| 從工作專案新增 GitHub 認可或提取要求的連結 （預覽） | Boards | 2024 年第 1 季 |
未來 |
| 顯示 GitHub 提取要求的詳細資料（預覽） | Boards | 2024 年第 1 季 |
未來 |
| 從工作專案在 GitHub 存放庫上建立分支 | Boards | 2024 年第 2 季 | 未來 |
| 改善搜尋和連結 GitHub 時的延展性 存放庫至 Azure DevOps 專案 |
Boards | 2024 年第 2 季 | 未來 |
管線代理程序節點生命週期
Azure Pipelines 工作可以在 Node 或 PowerShell 中撰寫，並在 Azure Pipelines 代理程式中使用對應的執行器。 節點有一 般發行頻率，節點 16 是 LTS 和節點 18，自 2022 年 10 月起為目前版本。 節點工作執行器的原始設計並沒有讓工作作者直接升級 Node 版本，因此並沒有跟上最新的 Node 版本。 我們已收到客戶對此的意見反應，現在已進行多項變更，讓 Azure Pipelines 代理程式能夠讓已安裝的節點版本與節點發行頻率和支援生命週期保持同步，同時將工作和管線作者的影響降至最低。
作為第一個步驟，我們最近發行了代理程式的新 Node 16 工作執行器 。 在接下來的幾個月里，我們計劃為工作作者提供改善的指引，以跟上節點更新。 由於 Marketplace 中的所有工作都不會持續更新，以在最新版的 Node 上執行，因此我們也會提供管線作者繼續使用非升級工作的能力。 一旦提供所有這些功能，我們將從 Microsoft 裝載的代理程式和自我裝載的代理程式映射中移除 Node 的生命週期結束版本。
| 功能 | 區域 | 服務 | 伺服器 |
|---|---|---|---|
| 管線代理程式中的節點 16 工作執行器 | Pipelines | 2022 年第 3 季 |
2022.1 |
| 工作可以表達與多個節點執行器的相容性 | Pipelines | 2022 年第 3 季 |
2022.1 |
| 所有現用工作都會在節點 16 上執行 | Pipelines | 2023 年第 4 季 |
未來 |
| 如果目標版本無法使用，可以在下一個可用的節點版本上執行工作 | Pipelines | 2023 年第 4 季 |
2022.1 |
| 從 Microsoft 裝載集區移除節點 6 和 10 | Pipelines | 未來 | 未來 |
| 能夠在自我裝載的代理程式上下載並安裝舊的執行器 | Pipelines | 2023 年第 4 季 |
2022.1 |
| 停止傳送節點 6 和節點 10 執行器與代理程式 | Pipelines | 未來 | 未來 |
| 除了具有所有版本的代理程式以外，也只寄送節點 16+ 代理程式 | Pipelines | 2024 年第 1 季 | 未來 |
YAML 和發行管線功能同位
客戶偏好 YAML 管線而不是傳統組建 （CI）。 不過，對於發行（CD），許多客戶已繼續使用透過YAML的傳統發行管理管線。 主要原因是兩個解決方案之間各種CD功能缺乏同位。 在接下來的一年裡，我們將投資縮小這些差距。
作為第一個步驟，我們將著重於 檢查。 檢查是 YAML 管線中的主要機制，可閘道從一個階段升級至另一個階段的組建。
| 功能 | 區域 | 服務 | 伺服器 |
|---|---|---|---|
| 檢查的稽核 | Pipelines | 2022 年第 4 季 |
未來 |
| 檢查中的自定義變數 | Pipelines | 2023 年第 1 季 |
未來 |
| 檢查延展性 | Pipelines | 2023 年第 2 季 |
未來 |
| 略過核准和檢查 | Pipelines | 2023 年第 4 季 |
未來 |
| 排序核准和其他檢查 | Pipelines | 2024 年第 1 季 | 未來 |
| 延遲核准 | Pipelines | 2024 年第 1 季 | 未來 |
| 檢查中的服務連線 | Pipelines | 未來 | 未來 |
| 檢查擴充性 | Pipelines | 未來 | 未來 |
接下來，我們將著重於 部署功能，讓 YAML 管線中的部署策略與傳統發行管線中的部署策略類似。
| 功能 | 區域 | 服務 | 伺服器 |
|---|---|---|---|
| 階段的手動佇列 | Pipelines | 2024 年第 1 季 | 未來 |
| 重新執行單一階段 | Pipelines | 2024 年第 1 季 | 未來 |
| 階段層級並行 | Pipelines | 2024 年第 1 季 | 未來 |
| 階段層級可追蹤性 | Pipelines | 2024 年第 1 季 | 未來 |
簡化的儀錶板體驗
Azure DevOps 正在增強儀錶板體驗，著重於簡化建立和維護的使用者流程。 我們正在微調方法來改善工作流程。 我們的目標是簡化上線程式，確保使用者可以快速設定其儀錶板，並開始工作，而不需要麻煩。 為了提升生產力，並透過儀錶板深入解析增強決策，我們計劃提供下列功能。
| 功能 | 區域 | 服務 | 伺服器 |
|---|---|---|---|
| 工作項目圖表篩選 | 報表 | 2023 年第 4 季 |
未來 |
| 新的儀錶板目錄體驗 | 報表 | 2023 年第 4 季 |
未來 |
| 儀錶板全局參數 | 報表 | 2024 H1 | 未來 |
| 儀錶板範本 | 報表 | 2024 H1 | 未來 |
所有功能
如何提供意見反應
我們很樂意聽到您對於這些功能的看法。 透過 開發人員社群回報任何問題或建議功能。
您也可以在 Stack Overflow 上的社群取得建議和您的問題。