Azure DevOps Roadmap
| What's New | Developer Community | DevOps Blog | Documentation |
Product roadmap
This feature list is a peek into our roadmap. It identifies some of the significant features we are currently working on and a rough timeframe for when you can expect to see them. It is not comprehensive but is intended to provide some visibility into key investments. At the top you will find a list of our large multi-quarter initiatives and the features that they break down into. Further down you will find the full list of significant features we have planned.
Each feature is linked to an article where you can learn more about a particular item. These features and dates are the current plans and are subject to change. The Timeframe columns reflect when we expect the feature to be available on Azure DevOps Services; the Server columns reflect when we expect the feature to ship in Azure DevOps Server.
Initiatives
GitHub Advanced Security for Azure DevOps
GitHub Advanced Security (GHAS) for Azure DevOps is now generally available. Any project collection administrator can now enable Advanced Security for their organization, projects and repos from the Project Settings or Organization Settings. You can learn more about how to configure GitHub Advanced Security for Azure DevOps in our documentation.
New capabilities we expect to deliver include:
| Feature | Area | Service | Server |
|---|---|---|---|
| Display code scanning alerts for third-party tools that produce SARIF | GitHub Advanced Security for Azure DevOps | 2024 Q2 | N/A |
| Display contextual comments to pull requests containing newly introduced Advanced Security findings | GitHub Advanced Security for Azure DevOps | 2024 Q2 | N/A |
| Determine detected partner secrets validity | GitHub Advanced Security for Azure DevOps | 2024 Q2 | N/A |
| Automatically fix detected dependency scanning vulnerabilities with Dependabot security updates | GitHub Advanced Security for Azure DevOps | 2024 Q2 | N/A |
Minimizing the risks associated with credential theft
Azure DevOps supports many different authentication mechanisms, including basic authentication, personal access tokens (PATs), SSH, and Microsoft Entra ID (formerly Azure Active Directory) access tokens. These mechanisms are not created equally from a security perspective, especially when it comes to the potential for credential theft. For example, unintended leakage of credentials like PATs can let malicious actors into Azure DevOps organizations where they can gain access to critical assets like source code, pivot toward supply chain attacks, or even pivot toward compromising production infrastructure. To minimize the risks of credential theft, we will focus our efforts in the upcoming quarters in the following areas:
Enable administrators to improve authentication security through control plane policies.
Reducing the need for PATs and other stealable secrets by adding support for more secure alternatives.
Deepening Azure DevOps' integration with Microsoft Entra ID to better support its various security features.
Avoiding the need to store production secrets in Azure Pipelines service connections.
| Feature | Area | Service | Server |
|---|---|---|---|
| PAT lifecycle APIs | General |  2022 Q4 |
N/A |
| Control plane for personal access tokens (PAT) | General | 2022 Q4 |
2022.1 |
| Managed Identity and Service Principal support (preview) | General | 2023 Q1 |
N/A |
| Workload identity federation for Azure Deployments (preview) | Pipelines | 2023 Q3 |
N/A |
| Granular scopes for Azure Active Directory OAuth | General | 2023 Q3 |
N/A |
| Managed Identity and Service Principal support (GA) | General | 2023 Q3 |
N/A |
| Workload identity federation for Azure service connection (GA) | Pipelines | 2024 Q1 |
N/A |
| Workload identity federation for Docker service connection | Pipelines | 2024 H1 | N/A |
| Full web support for Conditional Access Policies | General | 2024 Q2 | N/A |
| Policies to disable authentication methods | General | Future | N/A |
Improved Boards + GitHub Integration
The existing Azure Boards + GitHub integration has been in place for several years now. The integration is a great starting point, but it does not offer the level of traceability that our customers have grown accustomed to. Based on customer feedback, we have put together set of investments to enhance this integration. Our goal is to improve upon it so that Azure Boards customers who choose to use GitHub repositories can maintain an equivalent level of traceability to having repositories in Azure DevOps.
These investments include:
| Feature | Area | Service | Server |
|---|---|---|---|
| Improved AB#{ID} validation | Boards | 2023 Q4 |
Future |
| Add link to GitHub commit or pull request from work item | Boards | 2024 Q1 |
Future |
| Show more details about a GitHub pull request (preview) | Boards | 2024 Q1 |
Future |
| Improve scalability when searching and linking GitHub repos to an Azure DevOps project |
Boards | 2024 Q2 |
Future |
| AB# links on GitHub pull request (preview) | Boards | 2024 Q2 |
Future |
| Create branch on GitHub repository from work item | Boards | 2024 Q3 | Future |
YAML and release pipelines feature parity
For the past several years, all our pipelines investments have been in the area of YAML pipelines. Furthermore, all our security improvements have been for YAML pipelines. For example, with YAML pipelines, the control over protected resources (e.g., repositories, service connections, etc) is in the hands of the resource owners as opposed to pipeline authors. The job access tokens that are used in YAML pipelines are scoped to specific repositories that are specified in the YAML file. These are just two examples of security features that are available for YAML pipelines. For these reasons, we recommend using YAML pipelines over classic. Adoption of YAML over classic has been significant for builds (CI). However, many customers have continued to use classic release management pipelines over YAML for releases (CD). The primary reason for this is the lack of parity in various CD features between the two solutions. Over the past year, we addressed several gaps in this area, notably in Checks. Checks are the primary mechanism in YAML pipelines to gate promotion of a build from one stage to another. We will continue to address gaps in other areas over the next year. Our focus will be on user experiences, traceability, and environments.
| Feature | Area | Service | Server |
|---|---|---|---|
| Auditing for checks | Pipelines | 2022 Q4 |
Future |
| Custom variables in checks | Pipelines | 2023 Q1 |
Future |
| Checks scalability | Pipelines | 2023 Q2 |
Future |
| Bypass approvals and checks | Pipelines | 2023 Q4 |
Future |
| Sequencing approvals and other checks | Pipelines | 2024 Q1 |
Future |
| Deferred approvals | Pipelines | 2024 Q1 |
Future |
| Rerun single stage | Pipelines | 2024 Q1 |
Future |
| Stage-level concurrency | Pipelines | 2024 Q3 | Future |
| Manual queuing of stages | Pipelines | 2024 H2 | Future |
| Stage-level traceability | Pipelines | 2024 H2 | Future |
| Service connections in checks | Pipelines | Future | Future |
| Checks extensibility | Pipelines | Future | Future |
All features
How to provide feedback
We would love to hear what you think about these features. Report any problems or suggest a feature through Developer Community.
You can also get advice and your questions answered by the community on Stack Overflow.