February 6th, 2020

Azure DevOps Roadmap update for 2020 Q1

Gloridel Morales

Senior Technical Program Manager

Azure DevOps Roadmap update for 2020 Q1

Last week we updated the Features Timeline to provide visibility to several of our key investments for this quarter. I am happy to share a few highlights on some of the features for Q1. Note that each feature links to our public roadmap project where you can find more details about each item and see its status.

Azure Boards:

More actionable error experience for Required fields

We’ve heard your feedback about making the Required fields error experience more friendly. We will make the errors more visible, easily understood, and actionable to help you quickly fill in required information, both on your board card as well as within your work item form.

Azure Repos:

Upgraded pull request web experience

We will convert the pull request details pages to a more modern, fast, and mobile-friendly UI. This will include the overview tab, files tab, commits tab, etc. In addition, we will add several features that will help you review pull requests faster and improve the overall pull request experience. Some of the features that we will add include:
- Add required reviewers per pull request in addition to those added by policy.
- A summary of policies that includes easier actions for failed policies.
- Ability to compare multiple updates not just subsequent ones when reviewing files.
- Suggest a change that the pull requestor can accept and commit without leaving the pull request.
- Being able to wait on optional policies when setting auto-complete.

Azure Pipelines:

Runtime parameters and pipeline variables

We will improve the YAML templating language and pipeline variables. YAML pipelines gain a way to specify runtime parameters. These are slots for the pipeline author to offer options to the end user running the pipeline while maintaining control over what the pipeline can do. Strings, numbers, enumerations, and even entire YAML objects can be entered at runtime rather than hardcoded into the YAML file. These same data types can be used with YAML templates, giving greater confidence about the resulting pipeline definition. Separate but related, variables can be marked “read only”, sealing them so that tasks cannot change their values between steps.
Multi-repository support for YAML pipelines

Last quarter, we introduced the ability to check out multiple repositories in a single pipeline job. This quarter, we’ll improve this multi-repository support to allow a separation between the repository containing the YAML file and the repository containing the code. This will let you get all the benefits of config as code, while letting the pipeline definition live in a different repository with different access controls.
Automated checks between stages

We’ve had great feedback on approvals in YAML pipelines since we released in November. This quarter we will enhance the functionality to support completing other automated validations before start of a stage. Like approvals, checks will be a protection on the infrastructure resources (environments, service connections and agent pools), ensuring all jobs that impact them meet a fixed set of criteria. We will invest in capabilities to allow invoking HTTP APIs for any service to perform the validation and periodic re-invocations for checks that take longer to complete.

Reporting:

Copy Dashboard

You will be able to make a copy of a dashboard within a team to another team, or to another team project. This will help you save time when replicating your dashboards across teams.

Administration:

Streaming for Azure DevOps Auditing

Azure DevOps Auditing is now in public preview! You can learn more about it here.

In this quarter we’ll be working on a streaming feature which will let you send your logs to first- and third-party Security Incident and Event Management (SIEM) tools. The use of these tools along with auditing will give you transparency into your workforce and allow for anomaly detection, trend visualization, and more.

We appreciate your feedback, which helps us prioritize. If you have new ideas or changes you’d like to see, provide a suggestion on the Developer Community, vote for an existing one, or contact us on Twitter.

Author

Gloridel Morales

Senior Technical Program Manager

Gloridel is a Senior Technical Program Manager on the Azure DevOps team.

33 comments

Discussion is closed. Login to edit/delete existing comments.

Alexandre, Diogo Paulino March 25, 2020

Do you know if the option Cross-repo services will be available in Azure Devops Server?

BR,

Diogo
- Gloridel Morales Author March 25, 2020
  
  Hi Diogo, don’t know yet.
Glyn Durban March 19, 2020

Any idea when the 2020 Q1 release will be made available?
- Gloridel Morales Author March 25, 2020
  
  Hi Glyn, you can see what we have released so far in the release notes release notes.
O'Neill, James (Capita Application Services) March 9, 2020
Was one of the changes changing the value of build.sourcesdirectory if there is a single checkout operation which specifies a path ?

I have this

<code>

I have found if I check out both like this

<code>

it would put the content in different directories $(build.sourcesdirectory)\codeBase and $(build.sourcesdirectory)\Utils
but if I only specified one or the other the content would go into $(build.sourcesdirectory)

To prevent adding or removing a repo causing the destination to change I wrote the check out as

<code>

This worked until Friday. Today. I find the code above works as it did. But if I only have

<code>

The value of build.sourcesdirectory changes...
Read more
Was one of the changes changing the value of build.sourcesdirectory if there is a single checkout operation which specifies a path ?

I have this
```
  
- repository: CodeBase      
    type: git
    endpoint: AnotherOrg 
    name: 'Org/Project' 
  - repository: Utils         
    type: git
    name: 'ThisOrg/Utils'
```
I have found if I check out both like this
```
  
- checkout: codeBase
- checkout: Utils
```
it would put the content in different directories $(build.sourcesdirectory)\codeBase and $(build.sourcesdirectory)\Utils
but if I only specified one or the other the content would go into $(build.sourcesdirectory)

To prevent adding or removing a repo causing the destination to change I wrote the check out as
```
  
- checkout: codeBase
  path: 's\codeBase'
- checkout: Utils
  path: 's\Utils'
```
This worked until Friday. Today. I find the code above works as it did. But if I only have
```
  
- checkout: codeBase
  path: 's\codeBase'
```
The value of build.sourcesdirectory changes from d:\a\1\s before the checkout to d:\a\1\s\CodeBase so everything which references ‘$(build.sourcesdirectory)’ is now broken. And pipelines which ran last week no longer run
Read less
- O'Neill, James (Capita Application Services) March 9, 2020
  
  Supplementary. It also changes
  BUILD_REPOSITORY_LOCALPATH and SYSTEM_DEFAULTWORKINGDIRECTORY
DUVAL, Romain March 9, 2020

Hello

I’m working for a company with specific constraints.
We want to manage our IP adresse in inbound of Azure key vaults firewall

The question is :
Is it possible to use AzureDevops with PrivateLink in order to access KeyVault?
This is a security question because we don’t want to allow all trafic on the key vault firewall.

Do you have a solution for this if it’s not possible ?

Regards
DUVAL Romain
- Gloridel Morales Author March 25, 2020
  
  Hi Duval, we don’t support PrivateLink at this time. Please reach out to Justin Chung (Justin.Chung@microsoft.com) so he can provide a solution.
MdV March 2, 2020

Hi there we are desperately waiting for any news regarding azure devops server 2020!
Our users keep asking me for the new testplan design und progress reports.
Many other service improvements which are long time available for azure devops look interesting as well.
Remember on-premise customers pay licence fees as well
- Gloridel Morales Author March 2, 2020
  
  Hi, we plan to release Azure DevOps Server 2020 late this summer.
  - Klaus Steinmetz March 24, 2020
    
    Yes I also have to say that this is quite sad. The last real feature delivery for 2019 was in August last year and now the next major is roughly 1 year later. Will this be the new pace for the on premise server?
  - MdV March 3, 2020
    
    Thanks for your feedback. Although i had hopes to get the new version earlier this year.
Rajesh Sirimulla February 28, 2020

Hello,

When are we planning to release Azure DevOps Server 2020? Is there any timeline?

Thanks,
Rajesh
- Gloridel Morales Author March 2, 2020
  
  Hi Rajesh,
  
  We plan to release Azure DevOps Server 2020 late this summer.
LeMaciek February 28, 2020

Any announcements coming regarding Server 2020? Is there a timeline for when we might see an RC1 of Server 2020 and an eventual RTW? Why are you so silent? No more updates?
- Gloridel Morales Author March 2, 2020
  
  Hi LeMaciek,
  
  We plan to release Azure DevOps Server 2020 late this summer.
Erik Mägi February 24, 2020

Are there any plans to support YAML PR triggers in Azure Repos Git?

Relevant feature request: https://developercommunity.visualstudio.com/idea/385329/pr-triggers-in-yaml-should-be-supported-on-azure-d.html?childToView=911048#comment-911048.
Ian Griffiths February 13, 2020

While you're looking at variables, I have a request: please could you lift the restrictions on where we can plug in parameters at template load time? For example, we make extensive use of the ability to pull templates from external repos. (We define a bunch of standard templates we use across all our projects in one repo, and then pull these in from other projects.) To do this, you need to specify the GitHub service connection name in the template reference, and today, you can't parameterise that. The service connection name used when referring to an external template has to...
Read more
While you’re looking at variables, I have a request: please could you lift the restrictions on where we can plug in parameters at template load time? For example, we make extensive use of the ability to pull templates from external repos. (We define a bunch of standard templates we use across all our projects in one repo, and then pull these in from other projects.) To do this, you need to specify the GitHub service connection name in the template reference, and today, you can’t parameterise that. The service connection name used when referring to an external template has to be hard-coded into the YAML.

(And more generally, it seems a bit arbitrary as to where you can and can’t plug in parameters. particularly if you make heavy use of templating like we do.)

Read less
- Gloridel Morales Author February 13, 2020
  
  Hi Ian,
  
  Thank you for the suggestion. You can suggest new features in the Developer Community.
Alexandre Nedelec February 12, 2020

Interesting news 😃. Really glad to see more things coming to YAML pipelines.
A bit sad however to see that “Azure Resource Group based environments” have been postponed. Without that, environments are almost useless when you don’t do Kubernetes. I did not see any survey on the topic, on what was based the customer research ?