Azure DevOps Roadmap update for 2019 Q3
Azure DevOps Roadmap update for 2019 Q3
As always, the Azure DevOps engineering team is working hard to deliver enhancements and new features across all our services. Recently we have been adding new capabilities at an unprecedented pace, including support for multi-stage YAML pipelines, Pipeline environments and Kubernetes integration, support for authenticating with GitHub identities, Python and Universal packages and public feeds in Azure Artifacts, new and updated integrations with Jira Software, Slack and Microsoft Teams, and much more.
We have also been making a renewed effort to include some smaller items each sprint which we categorize as “paper cuts”. These are minor to medium sized issues that can really help improve the users experience and are based on the amazing feedback provided through our Developer Community site.
Last week we updated the Features Timeline, take a look at the complete list of features for Q3. As we move into the second half of the calendar year, you can expect to see significant investments across all the services, but I wanted to call out some of my favorites from that list. Note that each feature links to our public roadmap project where you can find more details about each item and see its status.
Instead of automatically moving a run from one stage to the next, you might want an approver to review it first. While approvals are a concept that already exists in Release pipelines, it is not yet available when defining pipelines with YAML documents. Config-as-code poses interesting challenges for where you specify approvals. We plan to make approvals a policy on the resource (agent pool, variable group, service connection, or secure file), and any stage that uses that resource will be paused for an approval.
Currently, you can trigger a pipeline from changes made in a single repository. With this feature, you will be able to trigger pipelines based on changes made in one of multiple repositories. For example, this is useful if you manage your code in one repository and the YAML file in a different repository.
A deployment job is a special type of job that is used to deploy your app to an environment. We will enhance the strategies supported in deployment jobs to enable rolling, canary and blue-green deployments.
Customizing system picklists is a request with a high number of votes in the Developer Community. This quarter we will add this feature and let you to customize values on system fields such as Activity, Priority, Risk, etc.
We’ll update the work item notifications so that they are more customizable and flexible. You will have the full subscription option, unsubscribed option and a customizable option. This gives you the choice to follow just certain events on the work item, such as state changes or assigned to field changes.
We are adding granularity to the automatic reviewer policy so that you can set required reviewers at the group level. Today you can set a total required reviewer policy, but this is a global total. For example, this will let you set two people from a specific group as approvers.
You will be able to update, and close work items through Git commits by using a syntax similar to “fixes #3245”.
We are adding push policies that will allow admins to block pushes to a repository based on certain criteria. You will be able to set policies to block pushes where the commit author does not match the defined pattern. In addition, you will be able to block pushes where the push contains a file name that violates the defined pattern.
We’re making a major update to the “Connect to feed” dialog that supports more modern tools and reduces the need to manually generate and store Personal Access Tokens on disk in order to use Azure Artifacts feeds. We will also release new package authentication tasks for Azure Pipelines that will allow you to securely configure both Azure Artifacts feeds and any other feeds you provide via service connections.
Now that we’ve introduced consumption-based pricing for Azure Artifacts, we’ll be adding a set of views to help you understand your usage across feeds and upstream sources. From those views, we’re also adding a set of manual and automatic clean-up tools to help you control your costs.
Azure Test Plans:
We are adding a test progress report to Test Plans. The report will be powered by analytics to reflect the summary, progress and drill down for the selected Test Plan.
An organization in Azure DevOps is a mechanism for organizing and connecting groups of related projects. To help with governance, we are creating a new policy to control who in your enterprise can create new Azure DevOps organizations attached to your Azure Active Directory.
We will let you pull a full list of paid users under one Azure subscription. This export will provide a list of all the users under the same Azure subscription, the organizations and projects they can access, when they last accessed Azure DevOps, and when they were first added. You can use the information provided by the export to see which project your users have access to. This can be useful if you need to split costs based on projects.
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.