Note: If you do not see the preview feature on your account, kindly leave a comment to this blog with your team services account name.
There are multiple stakeholders for a release. Whether the team is small or large, keeping the right stakeholders informed about how releases are progressing and what actions are required.
Notifications, whether they arrive via email, Microsoft Teams, Slack, or some other system, push relevant information to recipients. Recipients don’t need to periodically check for new information; the information arrives when the recipient needs to be told something or when their action is required.
So far Release Definition authors were in charge for configuring the notification settings per environment. They could define if approvers should be intimated about pending approvals for deployments to the environment and whether information about deployment completions gets notified. We have heard feedback about this causing confusion with the stakeholders in terms of what notifications to expect.
We have been working on an integration with the default notification settings experience in team services, that is already in use for work items, pull requests, code reviews, builds etc. The principles behind the integration are –
- Great out of the box experience: We want users to get notified about the most relevant activity in their releases, without them needing to do anything. To achieve this, a set of default notification subscriptions are enabled for all users.
- Personal settings per user: When a subscription is enabled, the end user receives the notifications whenever the specified event happens. We want each user to be able to decide whether he wants to continue receiving the notification or not, and not rely on administrators to make that call.
- Customization experience: We believe out of the box notification subscriptions should be enough for most users, some users or admins may want to receive notifications about other activity. They can still do this via custom subscriptions.
Note: The feature discussed here is available now for Team Services. They are currently not available for Team Foundation Server.
Using the updated release notification settings
Here is a quick recap of how to use the new release notification settings.
This feature is currently in preview. To enable it for the account, an account administrator needs to go to Preview features under your profile menu, select From this account from the drop-down, then toggle on Release notifications feature.
Out of the box notifications
Prior to this feature, release definition authors would need to manually choose the notification settings. The recipients had no control on the notifications. With out-of-the-box notifications users automatically receive notifications for the following release events.
Users can easily choose to opt out of any of them. To manage the notification settings, select the Notifications option under the profile menu.
Learn more about out of the box notifications.
Custom notifications
Users and team administrators can create custom subscriptions for the following release events.
They can filter the events for which notifications should be delivered while creating a custom subscription.
User can configure the notifications to be delivered to other email addresses as well.
Learn more about managing personal notification settings and team subscriptions.
Sample Notification Emails
Following are a couple of snapshots of the emails received for release events.
Points to note
With this feature going live, there are a few points you should take note of.
- When the updated release notifications experience is enabled, then the existing settings made by release definition authors are no longer honored. Notifications are delivered based on the subscriptions, for all releases irrespective of whether the release definition author had chosen to send email or not.
If the release notification experience is turned off for an account, then the notifications are delivered as per the settings in the release definitions to users who have not disabled the corresponding subscriptions.
- A Deployment is deemed requested by the user based on the last manual action performed that resulted in starting of the deployment, between making the commit, queueing the build, creating the release or starting the deployment. In case a commit results in the deployment starting automatically (due to CI and CD triggers), then the deployment is considered requested by the user who made the commit.
- When approvals are assigned to a group or a group is mentioned as the environment owner, then all members of the group are intimated about the relevant release events.
Your feedback is important to us. Use the “send a smile” feature, comment on this post, or send to RM_Customer_Queries <at> microsoft <dot> com.
0 comments