We want to upgrade a Jenkins instance from 2.332.2 (from May 2022) to 2.387.2 (2023). Because this is such a large jump of LTS versions - we were planning to do a rolling upgrade by upgrading to every other LTS version until we reach 2.387.2.
Is there a strategy recommended for this type of upgrade? Not sure if this is the right approach. Thanks in advance.
@halkeye Do you have a recommendation?
Sorry, I didn’t mean to cause any trouble - you’ve been really helpful in the past so I thought you might have an idea.
The release guides don’t provide guidance on upgrades between LTS versions that are months apart, which was the reason for me asking here.
The ideal process is to have a QA server that is currently running the same version as your production instance. Then, you would try the upgrade (to the final version you want, though not sure why you are using an older LTS than the most recent for your final version target) and make sure your stuff works, then do the same on the production server. I know things are generally not ideal, so the rolling upgrade is probably the safest. I would recommend upgrading plugins in-between each Jenkins version you upgrade to, otherwise you would run into issues with plugins not being able to load and so forth.
I don’t understand your choice of destination version. 2.387.2 is not the final release in the 2.387.x LTS line and it is known to have security vulnerabilities. Why not upgrade to 2.414.1 or at least to 2.401.3?
I agree with @slide_o_mix that the direct, single step approach is worth an attempt on a disposable copy of your installation. You’ll need to upgrade Jenkins and upgrade plugins during that single step upgrade, but if successful, the end result has been reached very quickly.
If the single hop fails on the disposable copy of the server, then you can do the multi-step upgrade.
If the server is a Linux machine and was installed with one of the Linux package managers, then I would definitely attempt the single step upgrade on a test server first.
Just some random thoughts in random order
(no complete strategy - sorry; we try to keep up to date for exactly this reason)
- As mentioned by others: get yourself a test system; you don’t want to screw up your production system
- Do the full jump and test - if it works: fine
- If it doesn’t work, you could do a interval halving approach to narrow down on the problematic version
- First update your plugins to the latest version on the used Jenkins LTS version
- Put the files (jenkins config and job config) under version control.
Sometimes Jenkins updates changes content in non-trivial ways. This Keeping stuff in version control makes backing out easier and also to find what changed and what might caused your trouble
(Speaking from experience here ! Saved our combined asses more than once)
- What about the Java version used ?
In my current understanding you want 11.x
- Obviously: Check the Jenkins releaese notes. Some stuff might ring an alarm bell…