3.11.1. Mettre à jour avec Git

Mettre à jour Bugzilla est très simple, et vous pouvez faire la mise à jour à partir de n'importe quelle version vers une version ultérieure en une seule fois - il n'est pas nécessaire de passer par des étapes intermédiaires. Il existe un script appelé checksetup.pl fourni dans Bugzilla qui effectuera automatiquement la migration de la base de données.

3.11.1.1. Avant de mettre à jour

Avant de démarrer la mise à jour, il y a quelques étapes importantes à réaliser :

  1. Lisez les Notes de version de la version vers laquelle vous allez mettre à jour, particulièrement la section Comment migrer à partir d'une version précédente.
  2. Consultez la page de Contrôle d'intégrité (Contrôle d'intégrité) de votre installation avant de mettre à jour. Essayez de corriger tous les avertissements produits sur cette page avant d'aller plus loin ou vous pourriez avoir des problèmes pendant la mise à jour.
  3. Faites une sauvegarde de votre base de données Bugzilla. CECI EST TRÈS IMPORTANT. Si quelque chose se passe mal pendant la mise à jour, votre installation peut être corrompue et irrécupérable. Avoir une sauvegarde est une sécurité.

Si vous avez modifié votre installation Bugzilla

Si vous avez modifié le code ou les templates de votre installation Bugzilla, alors la mise à jour nécessite un peu plus d'effort et de réflexion. Une discussion sur les diverses méthodes de mise à jour en fonction du degré et des méthodes de personnalisation locaux se trouve dans Choisir une méthode de personnalisation.

Plus l'écart de version est important, plus il sera difficile de mettre à jour si vous avez fait des personnalisations locales. Une mise à jour d'une version 4.2. vers une version 4.2.1 devrait se faire sans peine, même si vous avez fortement personnalisé votre installation. Mais passer d'une version 2.18 à une version 4.2 un gros travail de ré-écriture de vos changements locaux pour utiliser les nouveaux fichiers, logique, templates, etc. Si vous n'avez pas fait de changement locaux du tout cependant, alors la mise à jour devrait représenter approximativement la même quantité de travail, quelle que soit la version que vous utilisez actuellement.

Si vous avez fait des personnalisations, vous devriez faire la mise à jour sur une copie de votre environnement de production et vous assurez que toutes vos personnalisations fonctionnent encore. Si ce n'est pas le cas, effectuez leur portage et les tests de sorte que tout soit prêt quand vous procéderez à la réelle mise à jour de votre environnement de production.

Vous pouvez vérifier s'il y a des personnalisations locales de code en utilisant la commande :

git diff

S'il n'y a pas de résultat, lancez alors la commande :

git log | head

et vérifiez si le dernier « commit » a été fait par l'équipe de Bugzilla ou par vous. S'il apparaît que celui-ci a été fait par nous, alors vous n'avez pas de personnalisations locales du code.

3.11.1.2. Démarrer la mise à jour

  1. Fermez votre installation Bugzilla en ajoutant un texte explicatif dans le paramètre shutdownhtml.
  2. Effectuez toutes les sauvegardes nécessaires. CECI EST TRÈS IMPORTANT. Si quelque chose tourne mal pendant la mise à jour, les sauvegardes vous permettront de revenir à une situation stable.

3.11.1.3. Télécharger la nouvelle version de Bugzilla

Dans les commandes ci-dessous, $BUGZILLA_HOME représente le répertoire dans lequel Bugzilla est installé. En supposant que vous avez suivi les instructions d'installation et que votre version de Bugzilla est un « checkout » d'une branche stable, vous pouvez obtenir la dernière version en exécutant les commandes suivantes :

cd $BUGZILLA_HOME

git pull

Si vous voulez mettre à jour vers une version plus récente de Bugzilla, vous devrez de plus exécuter la commande suivante :

git checkout release-X.X-stable

où X.X est le numéro de version à deux chiffres de la version stable que vous voulez installer (par ex. : 4.4).

Note

N'essayez pas de revenir à une version antérieure de Bugzilla par ce moyen : cela ne fonctionnera pas.

Si vous avez des personnalisations locales, git essaiera de les fusionner. Si cela échoue, vous devrez mettre en place le plan que vous avez envisagé quand vous avez détecté ces personnalisations dans les étapes précédentes.

3.11.1.4. Mettre à jour la base de données

Exécutez checksetup.pl. Ceci effectuera tout ce qui est nécessaire pour convertir votre base de données et les paramètres pour la nouvelle version.

cd $BUGZILLA_HOME

./checksetup.pl

Avertissement

Pour certaines mises à jour, exécuter checksetup.pl sur de grosses installations (75 000 bogues ou plus) peut prendre beaucoup de temps, et même plusieurs heures, si par exemple les index doivent être reconstruits. Si la durée de l'indisponibilité de votre installation est un problème pour vous, vous pouvez déterminer le temps nécessaire en effectuant la mise à jour sur un serveur de test avec les données de production.

checksetup.pl peut aussi indiquer que des modules Perl supplémentaires sont nécessaires, ou des versions plus récentes. Vous devrez les installer soit globalement, soit localement en utilisant le script install-module.pl.

3.11.1.5. Terminer la mise à jour

  1. Réactivez Bugzilla en effaçant le texte saisi dans le paramètre shutdownhtml.
  2. Lancez un nouveau Contrôle d'intégrité sur votre installation mise à jour. Il est recommandé de corriger tout problème rencontré immédiatement. Ne pas le faire peut entraîner des dysfonctionnements de Bugzilla.

Cette documentation contient très probablement des bogues ; si vous en découvrez, veuillez les signaler ici.