Regardless if everything has gone smoothly or if there has occurred an error you want to be timely notified about it. Therefore it is imperative to use a notification system.

Also, you should not miss the previous part of the article series about web integration – Continuous Integration – Cure for Human Error in Deployment. It is a must-read!

Generally, you notifications can be sent to:

• E-mail,
• RSS feed,
• HipChat, Slack,
• Jabber – Google Talk, AOL Instant Messenger,
• Google Cloud Messaging (GCM) service – Android devices
• Skype,
• MSN Messenger,
• Custom service in XML or JSON.

Below are sample notification messages in a Hipchat room (advising about successful and unsuccessful deployments of demo projects):

The basic notification option is to send notifications by e-mail; every CI tool supports it. Email notifications allow getting very detailed information. On the other hand, if you get hundreds of e-mails and messages get easily snowed under, you may need another solution. So what is it? Critically important messages can be accompanied by a text message notification, which you should always notice.

Most of the tools allow for a number of communication channels. You can choose from the above, among which you’ll likely find your favourite chat tool. We use Hipchat for common notifications, which we accompanied by e-mails in combination with text messages for projects of critical importance.

Intelligent Notifications

Every project involves a build practically after every commit. Hundreds of messages take some effort to get organised. That’s why we are happy to be able to use “intelligent notifications”. Do you wonder how it works?

We do not use artificial intelligence, but relatively simple logic. A notification is sent if the result of the current build is different than of the previous one.

E.g. It can happen that your last build ended in a failure, even though the previous build was successful. We should find out the cause and remedy it, if we are able to. Of course, it may have happened that the build failed because some cloud service hasn’t been available. In that case we cannot directly influence the situation, but at least the rest of the team and the client will be notified.

Jenkins CI notification setup is minimalist and in most cases sufficient. Administrators can’t go wrong. The setup contains the outlined “intelligent notification”.

If you are after a wider setup options you can go for e.g. Atlassian Bamboo, which allows distinction of who is to get a common notification, and who is to be notified about an important event i.e. by “intelligent notification”.

Tool Selection

Personally, I can give you a thorough comparison of Jenkins CI, which I have been using for several years, along with Atlassian Bamboo as a modern tool, and a bold adept at further system integration.

Jenkins CI is free; including plugins, there is no hidden pricing.

Though, you’ll have to sacrifice some time and effort installing it and setting up configuration tools. Yet, Jenkins has a historical advantage, as it builds on its predecessor named Hudson. Thanks to this long history, it has extensive documentation, and a plenty of plugins for a variety of additional functions.

Job management is clear, everything is on one page; you simply can’t get lost. On the other hand, the user interface could be considered a bit of disadvantage, as it doesn’t look very “cool” at first glance, but rather “old school”. Well, I guess we shouldn’t expect a bunch of frills in the time of flat design.

You can see below what a Jenkins CI job dashboard looks like. On the left is administrator menu, history of builds, including the one in progress; in the middle are quick links, and an overview of recent successful / unsuccessful builds, including times.

For comparison, I also added Atlassian Bamboo. It’s nice, clickable and aimed at less technical users. In addition, if you use Bitbucket as SCM platform and Atlassian JIRA for requirements tracking, you can easily set up the integration and create a compact automated tool ecosystem, which work well together.

However, I see a significant flaw in the complicated deployment process breakdown, which is plan – stages – jobs – tasks. The system reduces the redundancy of settings, for example, when you define a global variable in the plan and will use it in all jobs; one task can be used in more jobs.

I miss an overall overview on one page, as it is Jenkins CI. “Plan” management in Bamboo has tabs with different sub-settings. Jobs are broken down to tasks; so you always work only certain fragments. That’s why I consider Bamboo confusing, and potentially contributing to inattentive mistakes. Like other tools from Atlassian Bamboo is licensed and the price may be, especially for small business, also a limiting factor. You can try the basic version for $ 10, but the real operation starts at $ 800 per year.

To give you a comparison, you can see here what Atlassian Bamboo history of builds looks like (preview including detailed documentation for each screen part).

As it is not quite possible for a common user to compare all the available alternatives.

You can find a systematic comparison of 40 continuous integration tools here Comparison of continuous integration software. You will find there various criteria, from supported build tools to notifications and integration options.

But perhaps none of us has time for that. Yet, we should aim to choose the right tool that will suit you, and which you will be able to operate properly. Jenkins CI proved to be that for me. I can’t imagine continuous integration without it anymore.

Continuous Integration Can’t be Done without the Right Tool

As we have seen, continuous integration involves a number of activities. There is plenty of space for mistakes, if they are to be done by a human user. We can’t also disregard the time it consumes and the knowledge required.

On the top that, if we use human resources we also need to keep in mind possible substitutability.

Continuous integration experts are expensive and not easy to find. It is therefore appropriate, if not necessary, to also engage in the process an automation tool. How we choose it may be influenced by various criteria. Personally, I suggest not taking into account only the cost of the tool itself, but also what it can do, and how well it works – notifications, the possibility of integration with other services, and user interface. Consider what is most important for you, and test the tools accordingly. If you do encounter problems, try to find someone to help you with that. The chances are there are many companies around the world dealing with a similar situation.

Finally, certainly don’t worry about starting with continuous integration and the process setup. It may be a bit of an investment at the beginning, but it will save you both time, nerves (and even reputation). Once you have properly set up the automated process within continuous integration, you can just “replicate it only” in the next projects.