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.