After waiting for it for a long time it’s here! If any of your customers has self-service sandbox environments you’ve been doing this by hand. We’ve been on self-service for over a year and a half with a customer, since the private preview, and we’ve REALLY missed this feature in Azure DevOps.
All the documentation is available in the marketplace page for the tools.
You can read my complete guide on Dynamics 365 and Azure DevOps here.
If you want to learn more about self-service environments you can read these posts:
- Self-service deployments: the future is here!
- A warning about Self-service environments: update carefully
- Self-service & SSRS: print reports as PDF in your Dev VM
Configure release for a self-service environment
If you already set this for a regular environment you can still change the task to the new version.
The new task version 1 works for both type of environments: Microsoft managed (regular environments) and self-service environments. The task version 0 is the old one and will only work with regular environments. You can safely switch your deploy tasks to version 1.
What’s different in task version 1? I guess that some work behind it that we don’t see to make it support self-service, but in the UI we only see a new field called “Name for the update“.
This field is needed only for the self-service environments deployments, it will be ignored for regular ones, and corresponds to the field with the same name that appears on LCS when we apply an update to a sandbox environment:
The default field’s value is the variable $(Release.ReleaseName) that is the name of the release, but you can change it, for example I’ll be using a pattern like PREFIX BRANCH $(Build.BuildNumber) to have the same name we have for the builds and identifying what we’re deploying to prod quickier.
And done, you now can sit and relax and see your sandboxes updated using the benefits of CI/CD.
