Updating Hudson and plugins

I was wondering which steps are the best to upgrade hudson and the plugins.

I'm running 1.347 at the moment. I once tried to update which resulted into a mess because some plugins were incomp开发者_StackOverflow社区atible.

Also i want to delete some plugins is it appropriate to just delete the hpi file? It would be nice to know how other people do this step and in which order.

Should i first upgrade hudson and then plugin by plugin?

And if a plugin breaks something downgrade it again? It seems to be a lot of work. Or is there any easy way?

Also is it enough to save all the xml configuration files in case something breaks that i can recover?

Thanks in advance.

---

My solution is overkill, but I was burned twice (once by a Hudson bug and once by plugin incompatibilities) and learned my lesson.

I have Hudson installed on a VM with the same plugins as my production instance and a couple of simple builds. When I feel it's time to upgrade, or want to check out the latest release, I upgrade Hudson on the VM and verify that it starts up and can do builds. I only upgrade the production system that all of our developers use after I've upgraded my test system. I generally don't do exhaustive tests on my test system; it's enough to make sure the combination of upgraded Hudson and plugins starts up properly.

When upgrading either the VM or the main system, I upgrade all the plugins, then upgrade Hudson itself and restart. (Since I have a test system, I'm not particularly worried about doing things step by step.)

I came up with my process before Hudson introduced downgrade support. I still use this process because it's important to me to have confidence that an upgrade is not going to break the system that other developers use. This setup also allows me to have an experimental setup that's separate from the main Hudson system, which I find useful.

---

I usually update Hudson first, then the plugins.

The recent versions of Hudson have some support for this process:

• the Hudson 1.376 added downgrade support for the core and plugins.
  That means after upgrading a plugin, you have a button which allows you to downgrade to the previous installed version if needed.
• the Hudson 1.369 Avoid error with invalid or null primary view, such as in upgrade from older Hudson

And the upcoming Hudson 1.387 will avoid littering HUDSON_HOME with atomic *.xml files, which should make the backup process of critical config files that much easier.
(Currently, with an Hudson 1.386, I see under HUDSON_HOME:

com.mtvi.plateng.hudson.ldap.LdapMailAddressResolver.xml                   
config.xml                                                                 hudson.scm.SubversionSCM.xml
de.fspengler.hudson.pview.PViewProjectProperty.xml                         hudson.tasks.Ant.xml
hudson.maven.MavenModuleSet.xml                                            hudson.tasks.Mailer.xml
hudson.model.UpdateCenter.xml                                              hudson.tasks.Maven.xml
hudson.plugins.clearcase.ClearCaseInstallation.xml                         hudson.tasks.Shell.xml
hudson.plugins.clearcase.ClearCaseSCM.xml                                  hudson.triggers.SCMTrigger.xml
hudson.plugins.git.GitTool.xml                                             nodeMonitors.xml
hudson.plugins.sonar.SonarPublisher.xml                                    proxy.xml
hudson.scm.CVSSCM.xml

)