Reading Time: 4 minutes
Less is more. We’ve all heard this. But it’s especially true when it comes to notifications where it’s easy to end up with too much noise. Getting notifications for everything means getting notifications for nothing.
Today we’re rolling out the first stage of our improved notifications handling on Codeship. Its goal is to provide much better control over when your team gets notified and how. Keeping true to our Codeship core value of customer focus, we gathered tons of feedback from existing users and implemented it into this project. We’re confident our notifications are much easier to configure than other systems we’ve looked at. In a few clicks you can cut out noise, by only sending notifications to the people that need them, and only the ones that are relevant.
Should you be an existing Codeship user, all your current notification settings have been automatically migrated, so unless you want to take advantage of the new features, there are no actions required on your end. That being said, let’s have a closer look at what has changed and maybe you’ll want to change something after all.
Changes made to the current Notifications Settings?
First of all, let’s talk about what has moved. The first change is that commit status notifications to Github, Gitlab, and Bitbucket, has moved under General Settings. We felt it was more at home with the other similar setting (which account to use) so they’re not available together on the General setting view:
As you can see, we also moved the links to the project status images to the General Settings page.
How we improved Notifications on Codeship
Okay, on to the new stuff. We’ve revamped the whole stack, from the way we store the settings, to the logic, all the way up to a nice and simple UI. There’s a lot of stuff that is not visible, but the first thing you’ll probably notice is that the UI takes a whole new approach to notifications. It’s no longer just a list of notification services you can turn on, but a much more flexible and logical way of looking at notifications.
Branch-first approach to reduce noise
When we think of notifications, we normally think of them in context of the branch that triggered a build. A broken build on Master is very different from one on a feature branch, and obviously we’d like to make sure we don’t spam everyone so we end up ignoring the notifications instead of acting on them. Based on this, we’ve decided to make the branch the top-level dimension for notifications, and for each branch, or set of branches, you can now configure one or more notification services to trigger. You can specify either a single branch by name or use the
* wildcard to match multiple branches with similar names.
Using multiple notification services on Codeship
Sometimes you need to notify two different audiences. Perhaps you want to notify the whole team when a new deployment is out, but also want to drop a note in the Customer Success channel. Now you can do that with Slack, Hipchat, a webhook or any of the other services we integrate with, by simply adding more services under the same branch.
Select Notification Scenarios on Codeship
What good is it to be able to direct notifications, if you just end up directing the firehose somewhere else? This is why we’ve added the ability to select what type of events will trigger a notification. For now we’ve focused on either started, succeeded, failed, or recovered but plan to add more flexibility once we’ve seen how the new notifications settings are used.
Email Notifications on Codeship?
The email notifications themselves haven’t changed, but you now have more control over when they are triggered. Instead of just “on all events” and “on failure and recovery” you can now select between all four events (“started”, “succeeded”, “failed”, and “recovered”) to only get the emails you care about.
Don’t want emails at all for a project? Just remove the email rule and we’ll stop sending them. Some of you will appreciate this for sure.
CI Notifications – What’s next?
The changes we rolled out today not only provides more flexibility and control, but also sets the stage for adding more options in the future. We decided to limit the current release to the branch and event mapping, but have more improvements planned to be rolled out later. In the meantime we would love to hear from you if you think there are ways we can make notifications even better.
Feel free to sign up for Codeship and check out our highly customizable notification settings!