We leverage Release Management for Visual Studio quite often internally and at client sites to enable them to implement release processes for their organizations. One of the strengths of Release Management is its ability to model moderately complex workflows and approval processes within the enterprise. One of the challenges is to get the right level of communication from this tool. If a group has too little communication then people are not informed when they need to take part in a workflow. If there is too much and people begin to start to ignore it completely. Both of these outcomes result in decreased alignment and harm adoption of Release Management within organizations. This post is aimed at highlighting a common problem and a few solutions for it.
For this post, I’ll be using the following simple environment promotion process (click here for explanations of validation, approval, and acceptance):
Problem: QA Manager is Getting Too Many Notifications
Each Release that is created has a targeted environment. The target environment will indicate how far (from left to right in the above diagram) that release will be promoted if all approvals are made. Typically Development will “automate” validation and approval in the development environment to ensure that the noise to them for doing many builds is minimal. In an environment where any build can potentially make its way to production, this is bound to happen. The development team is in effect shifting the noise to the QA group/owner.
Development team changes most builds to only target Dev, and then if a release needs to go to QA and beyond: Dev can retarget an existing release to QA, or create another release that targets QA.
To retarget an existing build, within Release Management, navigate to Releases (tab), Releases (hyperlink below), Open the relevant release, and click on properties:
After that, simply change the Target Stage of the release, and Release management will prompt you to accept the new target stage.
Development team accepts the notification load by adding a member or members as Approvers of the Dev build when it’s satisfactory to promote beyond.
As this one issue highlights, where users are involved in the release process, a team needs to be particularly deliberate about how communication is handled. Before tools like Release Management, it was largely the responsibility of Development and QA to discuss when the next build would happen. These conversations should still be taking place regardless, but now Release Management will help in that process if it’s helping organize the communication. That will only happen as long as both parties in the example transaction above feel like they are getting a fair amount of communication.