Mise à jour de Hudson et des plugins

Question

Je me demandais quelles étapes étaient les meilleures pour mettre à jour hudson et les plugins.

Je cours actuellement 1.347. Une fois, j'ai essayé de mettre à jour ce qui a abouti à un désordre parce que certains plugins étaient incompatibles.

Aussi, je veux supprimer certains plugins est-il approprié de simplement supprimer le fichier hpi? Ce serait bien de savoir comment les autres font cette étape et dans quel ordre.
Dois-je d'abord mettre à jour hudson, puis le plugin par plugin?
Et si un plugin casse quelque chose downgrade encore? Cela semble être beaucoup de travail. Ou y a-t-il un moyen facile?
Est-il également suffisant d'enregistrer tous les fichiers de configuration xml au cas où quelque chose casse que je peux récupérer?

Merci d'avance.

Answer 1

Ma solution est surpuissant, mais je brûlé deux fois (une fois par un bogue Hudson et une fois par incompatibilités plugin) et appris ma leçon.

J'ai installé Hudson sur une VM avec les mêmes plugins que mon instance de production et quelques builds simples. Quand je pense qu'il est temps de mettre à niveau, ou que je veux vérifier la dernière version, je mets à jour Hudson sur la VM et je vérifie qu'il démarre et qu'il peut faire des builds. Je ne fais que mettre à niveau le système de production que tous nos développeurs utilisent après avoir mis à jour mon système de test. Je ne fais généralement pas de tests exhaustifs sur mon système de test; il suffit de s'assurer que la combinaison de Hudson et des plugins mis à jour démarre correctement. Lors de la mise à niveau de la machine virtuelle ou du système principal, je met à niveau tous les plugins, puis met à niveau Hudson lui-même et redémarre. (Depuis que j'ai un système de test, je ne suis pas particulièrement inquiet de faire les choses pas à pas.)

Je suis venu avec mon processus avant que Hudson a introduit le support de downgrade. J'utilise toujours ce processus car il est important pour moi d'avoir confiance qu'une mise à niveau ne va pas casser le système que les autres développeurs utilisent. Cette configuration me permet également d'avoir une configuration expérimentale séparée du système Hudson principal, que je trouve utile.

Answer 2

J'ai l'habitude de mettre à jour Hudson d'abord, puis les plugins.

Les versions récentes d'Hudson ont un certain soutien à ce processus:

• le Hudson 1.376 a ajouté le support de déclassement pour le noyau et les plugins.
  Cela signifie qu'après avoir mis à jour un plugin, vous disposez d'un bouton qui vous permet de revenir à la version précédente installée si nécessaire.
• la Hudson 1.369 Éviter l'erreur avec vue primaire invalide ou nulle, comme dans la mise à niveau de plus Hudson

Et la Hudson 1.387 prochaine évitera jonchant HUDSON_HOME avec *.xml atomiques fichiers, ce qui devrait rendre le processus de sauvegarde des fichiers de configuration critiques c'est beaucoup plus facile.
(Actuellement, avec un Hudson 1,386, je vois sous 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 

)