Azure DevOps Roadmap update for 2020 Q4
As part of our quarterly update, we’d like to share with you some of the highlights from the previous quarter and discuss what we have planned for this upcoming one. Each of the highlighted features includes a link to our public roadmap project where you’ll find more details on the item and where you can check its status.
Azure Boards
Customers have long desired the ability to view work items in a roadmap/timeline display. The Delivery Plans extension was a good start, but it is missing some key pieces of functionality. In Q4 of 2020, we are updating Delivery Plans, so it is part of the core product and building out some of those necessary features. These include:
- Allow work items to visually span sprint boundaries
- Support work items that are not assigned to an iteration path (start date and target date)
- Access to view existing plans for stakeholders
- Track dependencies across work items
- Roll up information to show the progress of child and grandchild work items
Azure Pipelines
YAML pipeline runs today can be paused only when performing checks on critical resources like environments, service connections, etc. There is no way to pause a run independent of these resources. We will soon be rolling out the capability to pause a pipeline run at a chosen point and seek manual inputs or validations from your peers. The pipeline run can be resumed or rejected by peers with additional comments.
Azure Artifacts
The Azure Artifacts team is moving to a new architecture for propagating updates from upstream sources, in response to customer feedback. Previously, upstream sources were polled only once every three hours. This injected latency and script complexity into build activities for customers.
With this upcoming feature, we are switching to a publication-subscription model, removing the need to poll upstream sources for changes. By the end of Q4, customers of Azure DevOps Services can expect the latency to drop significantly: a matter of seconds in the best case, up to a minute in the worst case.
This will be a behind-the-scenes improvement. When this feature is released it will be automatically applied to your organization for your private upstreams. We plan to make this improvement available for your public upstreams as well, it’s on the roadmap!
General
Billing setup and management events (set up billing, change billing subscription, remove billing, update quantity) will be available in the organization audit log.
Sign-in, personal access token (PAT) management (create, revoke, expire), PAT usage, SSH management (create public key, delete key), and SSH usage events will be added to the audit log. Though originally planned to be delivered in CY20 Q3, it is taking more effort than we anticipated and is now moving to CY Q4.
Azure DevOps REST API support to automate personal access token (PAT) management. This includes the ability to create new personal access tokens, rotate (regenerate), renew and revoke existing ones. Originally planned for CY Q3, this effort has been pushed to Q4.
Normally, changes to group memberships and permissions can take up to one hour to reflect in Azure DevOps. This tool will re-evaluate your group memberships and permissions on-demand; any recent changes will take effect immediately.
Today, any member of an Azure DevOps organization is able to view information such as the list of users, list of projects, billing details, usage data, and more by navigating to the organization settings. Many customers have wanted to restrict this information from some users like Stakeholders, AAD guest users, or members of a particular team. This quarter, administrators will be able to identify and restrict the organization settings from users and groups in their organization.
We always appreciate your feedback because it helps us prioritize what we should work on. If you have a new idea, change you’d like to see, or a suggestion on what you’d like to see next, here are some options:
- Review the existing suggestions on the Developer Community, and upvote for one that represents your thoughts
- Create a new suggestion if there are no existing ones that suit
- Reach out to us on Twitter
Light
Dark
10 comments
Hi there,
Is backup of git repos anywhere on the roadmap? We wanted to move some of our code into azure devops but the lack of backup was a deal killer.
We maintain at least 6 copies of your repo data, including PRs and push history, as part of our general data availability commitment. We don’t have plans to offer any other form of backups. (But of course, it’s just Git, so anyone with read access can
git clone --mirror!)You forgot to mention Pulumi as an option
Hi there. Is there a timeline on the road map when you plan to turn off the SOAP APIs and deprecate the WIT form?
as you know the SOAP API’s have already been deprecated. But there are lot of partners and customers still using them. We currently don’t have plans to remove them from the being used. That said, we are not updating them as new features and functionality come to the product.
For your information some of the links to work items in this article are not correct are they are based on a query and most of us don’t have the access to see such links.
For instance the link to Manual validation in YAML pipelines is https://dev.azure.com/mseng/AzureDevOpsRoadmap/_queries/edit/1663893 which results in a 401 (when logged in with a Microsoft account or an account from an unauthorized organization). If you use the following link however you will have no problem accessing the work item : https://dev.azure.com/mseng/AzureDevOpsRoadmap/_workitems/edit/1663893.
Could you please update the links in the article ?
The links appear to be to the mseng DevOps organisation which requires authentication to access, even the AzureDevOpsRoadmap project. I can’t access them from my non-Microsoft organisation account.
this comment has been deleted.
Hello Azure DevOps Server Team. Is the discussed roadmap here going to be assigned a date soon (perhaps November or December)? Does the 2020 RTW Release include all of the 2019.1.1 Patch 5 fixes and subsequent 2019.1.1 patches after September 8, 2020? Does the reported Microsoft.TeamFoundation.Git.dll bug/installation issue affect upgrades if you are upgrading from ADOS 2019 (with Azure DevOps Server 2019 folder) to the new default Azure DevOps Server 2020 folder (this scenario was not indicated in the Release Notes)? Our organization is eager to upgrade to ADOS 2020, but only after we see an iteration or two of patches/updates. Thank you for this Roadmap information and please continue to keep us up to date with as much information as possible.
I am glad to see the Manual validation in YAML pipelines feature being prioritized.
I have a concern, from the screenshot it looks like this will work similarly to the Required Approvers feature. This seems to be more focused on Continuous Deployment and doesn’t really meet the needs of a Continuous “Delivery” where you want to be able to deploy at any time but choose to deploy less frequently to production (maybe because you have government or highly regulated customers). In this case it looks like it would probably show the stage as running forever until someone rejected it, in which case it will probably show up as failed and email everyone involved each build. In our scenarios, I would like it to just always be skipped on CI triggers (email none); Then when you get a deployment approval which may be each sprint or each month (whatever that be) you go in the UI and manually click deploy (much like the release pipelines did), and then it would email approvers and require an approval.
This is impacting our ability to adopt the YAML pipelines which we very greatly wish to. Is there a preview feature that can be turned on for this?
Just for completeness our pipeline would look like this:
stages: # build and unit tests - stage: Build # qa environment deploy and end to end/api testing - stage: Test dependsOn: Build condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master')) # A production customer who highly regulates our deployments, doesn't want a multi-daily build approval email, need to manually trigger deploys infrequently - stage: ProdCustomer1 trigger: manual dependsOn: Test # Another production customer who highly regulates our deployments, doesn't want a multi-daily build approval email, need to manually trigger deploys infrequently - stage: ProdCustomer2 trigger: manual dependsOn: Test # Another production customer who highly regulates our deployments, doesn't want a multi-daily build approval email, need to manually trigger deploys infrequently - stage: ProdCustomer2 trigger: manual dependsOn: TestSome additional information, eventually I would like to be able to have a number of pull request environments where a pull request would trigger a test deployment to either a pool of dev environments or a dynamically created Kubernetes environment where a dev or tester could do some basic manual checks before approving the PR (but not deploy the “Test”/QA environment or production at that time). The CI build would then follow the pattern in the sample above deploying the Test/QA and, if manually deployed, the production systems.