How do you test changes to Jenkins plugins before deploying them?

If you ever been bitten by a plugin upgrade that broke some functionality you must have given some thought about this problem: What should be the Jenkins plugins upgrade policy? How do you test changes before deploying them?

Has anyone gone as far as having a test instance running dummy jobs to test the new versions or do you just pray that upgrading the versions won't break anything?

Answer

Do you mean Jeankins' team policy or your (organisation's) policy? I would take a snapshot of the Jenkins node before upgrading and just test it out. In my experience Jenkins has never been a mission critical component. If it's "down" for 15 minutes because some plugin upgrade broke it, it's usually not blocking production in any way, so manual intervention is acceptable. Of course, if that's not the case for you (and Jenkins must be 100% HA), it's not the right approach. @DanCornilescu my organisation policy as this is for our internal Jenkins server @AssafLavie That's highly dependent on the way Jenkins is running: Standalone server, VM, docker container, kubernetes pods (our case). It may not be easy to take a snapshot of the current state to restore it as is.

In our case we can clone the EBS volume holding the Jenkins data but it's a manual and time-consuming process to restore both the container and data volume to a specific state. Hi @MichaelPereira if either of the two answers below have solved your question please consider accepting it by clicking the check-mark. This indicates to the wider community that you've found a solution and gives some reputation to both the answerer and yourself. There is no obligation to do this. If you don't feel that your question has been answered please do feel free to engage with the authors in the comments.