As one of the most popular software delivery CI/CD tools, Jenkins is an open source automation server with an unparalleled plugin ecosystem that supports almost every part of your delivery pipelines. Whether your goal is continuous integration (CI), continuous delivery (CD) or something else entirely, Jenkins can help automate it.
Enabled and maintained by operations engineers, Jenkins servers coordinate all activities, such as building projects, checking and pulling new versions and submitting updates to different code repositories. These functionalities come in handy when frequent integration and deployment comes into play. If each development team member commits a single piece of work every day, which reduces the risks of running into traditional integration complexities, they are able to develop solid software at a much quicker pace.
Jenkins best practices
The following general best practices are important if you want to run a robust integration server. However, you will need to determine your environment’s requirements, as some of these recommendations will be more relevant for large and complex production resources.
All too often, users who use Jenkins for first time treat security as secondary. The business risk of not securing your Jenkins servers is high. Ensure that user authentication is established and enforce access control policies to your Jenkins servers. Due to the centrality of its role, a breach of your Jenkins servers can end up exposing access credentials to your most valuable resources.
Treat your master(s)
In large, complex integration environments which include multiple users who configure jobs, ensure that no one is running builds on the master, which actually provides unrestricted access to the JENKINS_HOME directory. Instead you can use Job Restrictions Plugin to limit which jobs can be executed on the master. You can also use multiple masters to restrict access to specific teams. With this approach, for example, restarts to install or upgrade won’t disrupt other users.
Backup Jenkins home
Although obvious, backing up JENKINS_HOME is a very important point. You want to make sure that all configurations and activity logs will be there when needed. For that purpose, you can also use the thinBack plugin which backs up the global and job specific configurations and can be scheduled for automated backup only of the critical configurations.
Choose and maintain your plugins
Due to the popularity of the open source project, it is no secret that there are many plugins and duplicated functionalities across plugins. This can negatively affect your master performance and your jobs’ run time. Think twice before you install any plugins and never install a plugin on the master. Make sure that you uninstall and clear old data of unused plugins.
Your jobs shouldn’t all start at the same time. Instead, use time triggers in the cron expressions. You can set up the schedule period to 10 12 * * * which means that you schedule the build every day of every month, of every year, at the 10th minute of the 12th hour of the day. To allow periodically scheduled tasks to produce balanced loads on the system, the symbol H should be used wherever possible and it will distribute the job starting times evenly.
Break jobs down to pieces
A Jenkins job running multiple tasks is not effective. Modular and distributed design are good programming practices and that is applies to Jenkins deployment as well. Breaking a single build process into small processes allows reusability of generic jobs across multiple releases.
Jenkins need free disk-space
Jenkins needs disk space to perform builds and keep data logs and archives. You can use the Disk Usage Plugin to monitor your project usage trends and the remaining allocated disk space, or install Nagios checks for disk space monitoring.
Test Drive Stratoscale for Free!
Finally, build, run and scale cloud-native applications on-prem
Sign up for Stratoscale’s fully-featured sandbox environment - No Download Needed!