Managing the configuration of Jenkins—the popular open source, continuous integration and continuous delivery application—is not trivial. Even a small change can make the platform less stable or result in problems. Vishal Sahasrabuddhe talks about his experiences using Jenkins and offers tips to take advantage of its many powerful features to automate deployment and increase productivity and product quality.
Configuration management requires that you automate application build, package, and deployment. There are many tools used to accomplish these tasks, but Jenkins is one of the most popular open source frameworks employed by teams today.
Jenkins is widely used by developers to automate not only application procedures, but also continuous integration and continuous delivery. It comes with many powerful built-in features, and there are also hundreds of plugins that help it integrate with other tools and perform a variety of important tasks.
It is also easy to use to deploy web packages such as JAR, WAR, and EAR files and modules, and Jenkins is known for its simple WAR-based deployment. Configuration is accomplished through XML files, and there is no requirement for an external database. This technology is scalable and can make use of a master and slave architecture that works across a variety of platforms. In fact, cross-platform support is one of Jenkins’s most powerful features.
Managing Jenkins requires automated procedures and well-defined processes, so a DevOps deployment pipeline to support it is a must-have.
Various sites and blogs talk about how to configure and set up Jenkins. You can even find lists of productivity plugins, which can make management much easier to handle. But there are few sources that describe how to administrate Jenkins—what not to do and what precautions need to be taken for daily operations.
I have faced multiple challenges while managing Jenkins, but that has led me to understand the tool more completely. Here are a few insider tips to manage Jenkins yourself.
Use the LTS Version
While you can always download the latest Jenkins release, it is usually a much better idea to work with the more stable long-term support (LTS) release. The latest release may have lots of new features and quick enhancements, but sometimes it also may have defects or issues that create stability issues.
The LTS version may lag behind in terms of features, but it is less prone to error, and therefore more reliable. Sooner or later these new features will be added to the LTS release and you can start using it without worrying about stability. If you still want to give the latest release of Jenkins a try, then I would suggest that you use it in your development sandbox first.
Don’t Let Plugins Update Automatically
Plugins can be configured to automatically update themselves, but this is not necessarily a desirable feature; it creates too much instability. If you allow your plugins to upgrade at will, you may get new versions every day. These new plugins can have bugs and may even break the desired functionality.
You can examine the plugin bug report to see it there is any critical bug or compatibility issue reported, but if there is a bug that impacts your day-to-day work, it can be difficult to identify the culprit because it may create some random problems in unknown directions. For example, I have seen the thinBackup plugin upgrade itself and cause Jenkins to unexpectedly schedule a restart, which is not at all easy to identify or predict beforehand.
I highly recommend that you have a sandbox for Jenkins where you can install or upgrade plugins and test them thoroughly before implementing them in your production system.
Back Up before Making Configuration Changes
The Jenkins configuration is managed through XML files, which provides considerable flexibility and allows you to make changes on the fly. The best use case here is to facilitate automation. If you want to automate a few tasks using some automation script, then the best way is to use the Jenkins REST API. You can even change the configuration of the job by downloading the config.xml file, modifying it locally, and later posting the modified config to the Jenkins platform.
Make sure you always back up your environment before making configuration changes. Once you have made changes to the XML files, you need to reload configuration from the disk in order to make the changes go into effect.
Remove Unused Plugins
Jenkins’s plugin-based architecture is very effective, but remember that each plugin consumes the some amount of memory; this means the more plugins you have installed, the more memory will be needed. That’s why the default Jenkins configuration comes with a minimal number of plugins.
You can install whatever you want based on your own requirements, but also keep in mind that it’s common to install a bunch but then end up not even using them. I suggest uninstalling the plugins that are not being used and freeing up resources on your server, which will likely improve the performance of your system.
Mastering Jenkins Management
Jenkins is a powerful platform to support continuous integration and continuous delivery. Managing the configuration of the Jenkins platform is not trivial; any change in the system can result in its becoming more stable or less stable. We should always take potential instability very seriously, as even a small change can result in problems.
But if you spend some time with Jenkins—and follow these tips—you can take advantage of its many powerful features while avoiding possible pitfalls. When used to the best of its ability, Jenkins can help you automate your deployment pipeline, increasing productivity and quality.