For years, I’ve been a happy user of Jenkins to automate all our Continuous Integration & Continuous Delivery CI/CD steps. Just recently, I’ve been evaluating some other, more modern platforms. While trying out GitHub Actions and Azure DevOps, I’ve been generally satisfied, but found that both don’t fit perfectly for what I want. GitHub Actions is still in it’s early stages and lacks many features, and with Azure DevOps I’ve felt the setup to be a bit too complicated and tightly integrated with Azure services. Jenkins just could do everything quite well while giving you lots of freedom.

These findings resulted in me not changing the existing setup too much - two servers, one running Windows and one on Linux worked fine so far. However, I’ve been a bit unsatisfied with the server’s performance characteristics. The instances were on some virtual servers that were approaching their 4 year mark, so I decided to switch to two up to date, dedicated machines.

This led me to rethink the backup process. Previously, a cronjob just backed up all the Jenkins data daily to a network share that was provided by the server hosting company, and that felt a bit too outdated and makes accessing backups actually more complicated than necessary. So I decided to just Backup the data to Azure Blob Storage. However, there was no ready made solution that I could find, so I had to roll my own.

Luckily, Jenkins uses just file storage in it’s JENKINS_HOME directory for all configurations, from users to jobs to plugins, so backing up the configuration is actually pretty easy - just copy the parts you want to be backed up. For this, I decided to directly leverage Jenkins itself to run the backup jobs, with a simply script that backs up the data to a Zip file and uploads it to the cloud.

Essentially, it boils down to two parts, all of them are available directly on GitHub. First, the Jenkinsfile which configures the job itself:

#continuous integration #jenkins #azure #ci #ci