Aktualisierung von Hudson und Plugins

Question

Ich habe mich gefragt, welche Schritte die besten sind, um Hudson und die Plugins zu aktualisieren.

Ich laufe 1.347 im Moment. Ich habe einmal versucht zu aktualisieren, was zu einem Durcheinander führte, weil einige Plugins inkompatibel waren.

Auch ich möchte einige Plugins löschen ist es angemessen, nur die hpi-Datei zu löschen? Es wäre schön zu wissen, wie andere Leute diesen Schritt machen und in welcher Reihenfolge.
Soll ich erst Hudson upgraden und dann plugin plugin?
Und wenn ein Plugin bricht etwas downgrade es wieder? Es scheint eine Menge Arbeit zu sein. Oder gibt es einen einfachen Weg?
Ist es auch genug, um alle XML-Konfigurationsdateien zu speichern, falls etwas kaputt geht, das ich wiederherstellen kann?

Vielen Dank im Voraus.

Answer 1

Meine Lösung übertrieben, aber ich war (von Plugin-Inkompatibilitäten einmal von einem Hudson-Fehler und einmal) zweimal gebrannt und habe meine Lektion gelernt.

Ich habe Hudson auf einer VM mit den gleichen Plugins wie meine Produktionsinstanz und ein paar einfache Builds installiert. Wenn ich das Gefühl habe, dass es an der Zeit ist, ein Upgrade durchzuführen, oder wenn ich die neueste Version auschecken möchte, rüste ich Hudson auf der VM auf und vergewissere mich, dass es hochfährt und Builds ausführen kann. Ich aktualisiere nur das Produktionssystem, das alle unsere Entwickler verwenden, nachdem ich mein Testsystem aktualisiert habe. Generell teste ich mein Testsystem nicht umfassend. Es ist genug, um sicherzustellen, dass die Kombination von aktualisiertem Hudson und Plugins ordnungsgemäß startet.

Wenn entweder die VM oder das Hauptsystem aktualisieren, ich alle Plugins aktualisieren, dann ein Upgrade Hudson selbst und neu starten. (Da ich ein Testsystem habe, bin ich nicht besonders besorgt über die Dinge Schritt für Schritt zu tun.)

Ich kam mit meinem Prozess, bevor Hudson Herabstufung Unterstützung eingeführt. Ich benutze diesen Prozess immer noch, weil es mir wichtig ist, darauf zu vertrauen, dass ein Upgrade das System, das andere Entwickler verwenden, nicht durchbrechen wird. Dieses Setup erlaubt mir auch eine experimentelle Konfiguration, die vom Haupt-Hudson-System getrennt ist, was ich nützlich finde.

Answer 2

Ich update normalerweise zuerst Hudson, dann die Plugins.

Die aktuellen Versionen von Hudson für diesen Prozess eine gewisse Unterstützung haben:

• die Hudson 1.376 Herabstufung Unterstützung für den Kern und Plugins hinzugefügt.
  Das bedeutet, dass Sie nach dem Upgrade eines Plugins eine Schaltfläche haben, mit der Sie bei Bedarf auf die vorherige installierte Version zurückstufen können.
• die Hudson 1.369 vermeiden Fehler mit ungültiger oder null primärer Ansicht, wie in Upgrade von älterer Hudson

und die bevorstehenden Hudson 1.387 vermeiden HUDSON_HOME mit atomaren *.xml Dateien Littering, die den Backup-Prozess von kritischen Konfigurationsdateien machen sollten viel einfacher.
(derzeit mit einem Hudson 1.386, sehe ich unter 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 

)