Azure DevOps Roadmap update for 2020 Q1

Gloridel Morales

February 6th, 202033 0

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.

Gloridel Morales Senior Program Manager, Azure DevOps

Read next

33 comments

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

  • MdV 0

    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 MoralesMicrosoft employee 0

      Hi, we plan to release Azure DevOps Server 2020 late this summer.

      • MdV 0

        Thanks for your feedback. Although i had hopes to get the new version earlier this year.

      • Klaus Steinmetz 0

        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?

  • DUVAL, Romain 0

    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 MoralesMicrosoft employee 0

      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.

  • O'Neill, James (Capita Application Services) 0

    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

    • O'Neill, James (Capita Application Services) 0

      Supplementary. It also changes
      BUILD_REPOSITORY_LOCALPATH and SYSTEM_DEFAULTWORKINGDIRECTORY

  • Glyn Durban 0

    Any idea when the 2020 Q1 release will be made available?

    • Gloridel MoralesMicrosoft employee 0

      Hi Glyn, you can see what we have released so far in the release notes release notes.

  • Alexandre, Diogo Paulino 0

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

    BR,

    Diogo

    • Gloridel MoralesMicrosoft employee 0

      Hi Diogo, don’t know yet.

Feedback usabilla icon