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

Comments are closed. Login to edit/delete your existing comments

  • Thadeu Fernandes 0

    Great news so far! Specially being able to use multiple repositories in a single build.

    It’d be great to see improvements to release pipelines variables though, it’s a pain to manage them for multiple scopes.

  • Pierre Letter 0

    Can’t wait to have these (and past) updates live on Azure DevOps Server 2020.

  • Diego 0

    Is there any plan to support yaml templates with scripts?
    Today is really painful to create a step template that depends on a script and not be able to use the script path from the template repository.

    • Matt CooperMicrosoft employee 0

      With extends templates and multi-repo checkout, this should be a lot easier now.

  • Andre Wanlin 0

    From looking at the Feature Timeline there seems to be 6-8 months worth of Services features coming to Server in the 2020. I’m assuming that there won’t be anymore Updates for Server 2019 and the next release will be Server 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?

    • Gloridel MoralesMicrosoft employee 0

      Hi Andre,

      We plan to release Azure DevOps Server 2020 late this summer.

  • Mickael Vest 0

    Hi,
    I don’t see anywhere in the roadmap anything relating to the Release stages defined as YAML (not multi-stage builds, Releases). Is that planned ?
    Also it is unclear to me which should be considered the best practice and the real MS-supported way to do things : Build Pipelines et Releases separately, or deployments in the build pipelines ?

    • Matt CooperMicrosoft employee 0

      Hi Mickael. We have been bringing the features of classic RM into YAML; there is no plan to bring YAML to classic RM. I may have misunderstood your question, though – feel free to clarify and I’ll do the same.

      The main thing to keep in mind when deciding between separate build/deploy pipelines vs a single unified pipeline is whether most runs will end up going all the way through or not. If you frequently run builds but only occasionally deploy, then it probably makes sense to decouple into two pipelines and trigger the release on an artifact. On the other hand, if you’re all in on continuous deployment and every PR that lands goes to prod, a single unified pipeline is easier to manage.

      • Mickael Vest 0

        Hi Matt,

        Thanks a lot for taking the time to answer. For the first question I think either my question was not clear or I’m not understanding how your answer relates to it.
        My question is that I would like my releases to be also YAML-defined (and versioned) instead of adding them in the UI (Create a stage, link the variable groups, add task). I saw that all tasks have YAML enabled, but defining the release itself (stage+ tasks, approvals, triggers) has to be done through the UI.
        Which brings for me the problem of :
        – It is not versioned
        – A lot of copy-pasting and duplicated edits, lack of factorizing things

        In the end I have one pipeline per env (3 envs). My ideal would be ONE pipeline template (I saw there is a template feature but I haven’t really figured it out) on which I just apply a different variable group. And I would like it in a repo as code 🙂

        As for separating the pipelines or not, we’re more in a situation where (surprise) it depends : deployment is continuous on dev, and happens every 2 weeks (end of sprint) on production.

        Ultimately, my one question is will we be able to define the separate releases (triggers, approvals, stage, etc), the ones that are in the “Releases” tab, fully as YAML ; is that something anywhere on the roadmap ?
        If it is, I’m fine to wait, if not I think this will be the signal for us to use multi-stage build.
        Again, thank you a lot for answering Matt, I really appreciate !

        • Matt CooperMicrosoft employee 0

          Ah, I see where I misunderstood now. To define YAML-based releases, you don’t use the “Releases” menu item. That’s for classic/designer release definitions. For YAML, you use the Pipelines menu item just as you would for YAML builds. The syntax for releases is integrated with the syntax for CI. Deployment jobs full syntax is documented here: https://docs.microsoft.com/azure/devops/pipelines/yaml-schema#deployment-job and resource-based triggers are here: https://docs.microsoft.com/azure/devops/pipelines/yaml-schema#resources

          • Mickael Vest 0

            Thank you Matt. That was indeed where I was going, seeing if with YAML we can some day manage the separated release.
            From your answer I understand that YAML will only ever allow to do this from the same pipeline as the build, which does not shock me at all.

            All we need is feature parity, especially on everything that has to do with manual approvals and deploys 🙂

      • Richard Gavel 0

        The one issue with using “YAML Pipelines” as a replacement for release pipelines, how can u ad hoc define which build you want as the input into your release pipeline. The GUI made this fairly easy as it knew which release pipelines could accept a build of the type in question. The only thing I could see doing in YAML based release pipelines would be a free form text field variable.

        • Matt CooperMicrosoft employee 0

          If you’re going to manually queue releases, then you could use a runtime parameter (docs are up now, the feature is rolling out this week) to offer either a freeform text field or a constrained list of build pipelines to choose from.

  • Alexandre Nedelec 0

    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 ?

  • Ian Griffiths 0

    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.)

    • Gloridel MoralesMicrosoft employee 0

      Hi Ian,

      Thank you for the suggestion. You can suggest new features in the Developer Community.

  • LeMaciek 0

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

      Hi LeMaciek,

      We plan to release Azure DevOps Server 2020 late this summer.

  • Rajesh Sirimulla 0

    Hello,

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

    Thanks,
    Rajesh

    • Gloridel MoralesMicrosoft employee 0

      Hi Rajesh,

      We plan to release Azure DevOps Server 2020 late this summer.

Feedback usabilla icon