Azure DevOps Roadmap update for 2020 Q1

Avatar

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.

Avatar
Gloridel Morales

Program Manager, Azure DevOps

Follow    

11 comments

Leave a comment

  • Avatar
    Thadeu Fernandes

    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.

  • Avatar
    Andre Wanlin

    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?

  • Mickael Vest
    Mickael Vest

    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 Cooper
      Matt Cooper

      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
        Mickael Vest

        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 !

  • Avatar
    Alexandre Nedelec

    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 ?

  • Avatar
    Ian Griffiths

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