How to Improve Jenkins Notifications UX Design in Microsoft Teams

DZone's Guide to

How to Improve Jenkins Notifications UX Design in Microsoft Teams

Did you know you can get Jenkins notifications about your builds in your Teams channel? Learn how to set this up and fine-tune the UX.

· DevOps Zone
Free Resource

The Nexus Suite is uniquely architected for a DevOps native world and creates value early in the development pipeline, provides precise contextual controls at every phase, and accelerates DevOps innovation with automation you can trust. Read how in this ebook.

Jenkins is one of the most popular software builds automation servers in the industry. It is used by many teams across the world in the continuous integration process. You might be comfortable with periodic checks of the build statuses on Jenkins server when it doesn't have that many jobs. However, it is much more convenient to get notifications about the builds when everything gets more complex and the number of tasks is growing. It is even better if these notifications are grouped into teams, channels, etc. There are several solutions which offer workplace chat functionality. Microsoft Teams is the most popular among businesses who are already in Microsoft Office 365 ecosystem. In this article, we’ll tell you how the Existek team is making UX design and content of Jenkins notifications more optimized and convenient for the Microsoft Teams users.

Connecting Jenkins to a Microsoft Teams Channel

First, you will need to get notification URL in your channel. Click the menu button next to your channel name:

the screenshot which describes how to connect Jenkins to the Microsoft teams channel


Find Jenkins and click Configure. Enter the name that describes the channel and click Create. You will see a field called Webhook URL with the URL that starts with “https://outlook.office.com/webhook/”. Save it somewhere as you will need it later.

You will have to install Jenkins plugin to enable your build jobs to post notifications. In order to do this, go to your Jenkins URL and then go to /pluginManager/available and find a plugin called Office 365 Connector. Install it the same way as any other plugins.

The next step is to enable it in your build. You can do in specific build Configuration. Next to the Job Notifications section, you will see Office 365 Connector, click Add webhook button.

This is how it looks:

the process of the connecting Microsoft teams connector to the Jenkins

Enter the URL from the Webhook URL that you saved before, check which build states you want to be notified about, and press “Save.” That’s it, and if you run your build now, you’ll see notifications in your Teams channel.

The Problem With Build Start Notifications UX

This is how your build notification will look in the Microsoft Teams channel (at least if your plugin version is 3.0 or lower).

This is how your build notification will look in the Microsoft Teams channel

There are few major problems here and lots to be improved.

Many elements in this notification can be taken as the example. Let’s begin with the “Start time”. User already sees a start time at the top and it is in his timezone, nobody cares about CET not to mention seconds and date (which you can see if you hover your mouse over card’s time at the top).

Here is our suggestion how this can be improved:

Here is our suggestion how jenkins notifications can be improved:

This card is much smaller but still, it contains all the information that user needs:

  1. Like before, you have Jenkins (so you know what kind of notification that is) and timestamp in your local time zone, so you know when an event has occurred.
  2. Build name. Obviously, the user needs to know what build that was.
  3. Build number which is also a link to a build Jenkins URL. The user needs to know build number and it would be handy to have a link in case he or she wants to open it to see more details.
  4. Build status. Notification should show, what has happened to the build.
  5. Next string starts with build reason. It is useful to know who has pushed the changes or clicked Build now button in Jenkins.
  6. Amount of the files that have been changed. It is not always the most important thing to know but sometimes it might be useful. Therefore, we placed it at the very end of the notification.

That’s it. If you think something useful is missing or you see more space for improvements – welcome to the comments section below.

The Problem With the Build Finish Notifications

This is what you see when your Jenkins build is finished and is posting the notifications to Teams channel.

This is how it looks when your Jenkins build is finished and is posting the notifications to Teams channel.

Basically, it has the same issues as the build start notification. However, there are few extra things:

We suggest to improve it this way:

mockup of the improved jenkins notification

  1. You should be familiar with the first line because it is same as on the Start card.
  2. Build duration. We suggest to use it without any explanation text because its duration is clear from the format.
  3. List of changes with the names of the authors. It is convenient because QA engineers can quickly see what changes are in the build and who did them. Also, if the build failed – you can quickly find a way to fix it.
  4. Tests statistics in a single line.

The need for tests information here is arguable. For instance, if you have failed tests – the build actually should fail, so the developer will find out how many and what tests have been failed during the investigation. This can be the subject of another article. We will be happy to hear your opinions in the comments.

Solution

Office 365 Connector plugin is open source, so we decided to fix this issue and implemented compact notifications in our own repository, you can find the source code here. If you use it, the notifications look like this:

the screenshot of the compact jenkins notification

Office 365 Connector plugin for jenkins screenshot

As you can see, during our tests we have discovered that it is more convenient for our users to have changes list directly under the header so we moved it into subheader. We needed to move build duration somewhere because of that, so we decided to move it into the header. We already see even more space for improvements and we will try to implement that in the near future. What we have achieved is that these notifications occupy less vertical space. The notifications are no longer hidden behind the “See More” link and you can browse the notifications quicker.

  1. Uninstall official addon version and restart Jenkins.
  2. Build solution yourself or download ready HPI following this link.
  3. On your Jenkins server go to Manage plugins\Advanced and use Upload plugin section to upload the HPI file you have downloaded.

If you have any ideas and/or suggestions welcome to the comments below or feel free to contact us directly.

The DevOps Zone is brought to you in partnership with Sonatype Nexus.  See how the Nexus platform infuses precise open source component intelligence into the DevOps pipeline early, everywhere, and at scale. Read how in this ebook

DOWNLOAD
Topics:
office 365 ,jenkins ,test automation ,software testing ,tutorial ,devops

Published at DZone with permission of Victor Osetskyi, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.