This post is about continuous integration practice and Jenkins (Hudson) — one of the most popular open-source continuous integration server. The six must-have plug-ins I’ll discuss here will make your job of configuring Jenkins and running builds much more productive.
Continuous integration was first written about in Kent Beck’s book “Extreme Programming Explained,” published back in 1999. The idea behind it was that every time somebody commits any change to a version control system, the whole system is integrated and retested. With continuous integration, your system is proven to work (assuming you developed good test coverage), and, most importantly, you know right away if something got broken so you can fix it immediately.
The teams that practice continuous integration are able to deliver software much faster and with fewer bugs than teams that wait until the project is finished to do integration and testing. The main advantage is that bugs are found much earlier, mostly within minutes after they were introduced, and at that time, it is much easier and cheaper to fix them.
For example, it’s quicker to find the cause of a bug if there are only two changes to examine since the last integration rather than 50. In addition, it’s easier to eliminate bugs (by first identifying the root cause) while the change is still fresh in the developer’s mind and they can remember exactly what they did, why they did it, and how they chose to implement it. Another reason CI is effective is that when multiple changes are integrated together, their combined impact can result in unpredictable bugs, and CI practice allows one to find those bugs before software is ready for QA.
One of the necessary tools for implementing continuous integration practice is a continuous integration server. Jenkins is one of the most popularly deployed continuous integration servers. It’s an open-source product that is well supported by the community and commercially by CloudBees. It competes with well-regarded commercial products like Bamboo and TeamCity.
Jenkins is extendable via plug-in modules, and currently there are about 320 plug-ins to choose from. My favorites plug-ins are listed below, along with details on how they helped me to deliver build automation and create a robust, maintainable Jenkins server environment:
1. Disk Usage Plugin – Disk space is cheap these days, but it’s still good to know which projects consume how much disk space and act accordingly.
2. JobConfigHistory Plugin – Saves copies of all job and system configurations. This plug-in provides some backup and auditing of the changes made to the job.
Does not replace VCS for your configuration, but provides a quick start.
3. Email-ext plugin. This plug-in extends Hudson’s built-in email notification functionality by giving you more control. It provides customization of three areas:
• Triggers – Select the conditions that should cause an email notification to be sent.
• Content – Specify the content of each triggered email’s subject and body.
• Recipients – Specify who should receive an email when it is triggered.
The Email-Ext plug-in is quite customizable and can be put to good use to keep everybody informed about build status.
4. Jira Jenkins plugin. This plug-in integrates Atlassian JIRA to Jenkins. This allows the developer to just reference the Jira issue in the comment message (like Issue19), and Jenkins will automatically update the issue with developer comments and reference to code changes that were checked in for the issue. It’s very simple, yet powerful.
5. Integration with Sonar – Code quality reporting tool. This is a killer application for management to see a report about code quality. Quickly benefit from Sonar, an open-source code quality management platform based on many well-known analysis tools like Checkstyle, PMD, Findbugs and Cobertura.
6. For advanced usage, like building a deployment pipeline in Jenkins, I find the Build Pipeline plug-in offers a useful visualization.
By extending the concepts of CI, you can create a chain of jobs, each one subjecting your build to quality assurance steps. These QA steps may be a combination of manual and automated steps. Once a build has passed all these, it can be automatically deployed into production.
In order to better support this process, the Build Pipeline plug-in was developed. This gives the ability to form a chain of jobs based on their upstream\downstream dependencies. Downstream jobs may, as per the default behaviors, be triggered automatically, or by a suitable authorized user manually triggering it.
These six plug-ins can be beneficial to any project, language agnostic.
Please write which is your favorite plug-in and why.