3.11.5. Mettre à jour en utilisant une archive¶

Si vous ne pouvez (ou ne voulez) pas utiliser Git, une autre option est toujours disponible pour obtenir la dernière archive à partir de la Page de téléchargements pour créer une nouvelle installation de Bugzilla à partir de celle-ci.

Sans système de contrôle de version pour vous aider, le processus peut être un peu plus compliqué.

3.11.5.1. Avant de mettre à jour¶

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

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.
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.
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.

Comme vous utilisez une archive et pas un DVCS, il n'est pas facile de savoir s'il y a des personnalisations de code dans votre installation. Vous pouvez demander au sein de votre organisation si c'est le cas ou télécharger une copie de la même version de Bugzilla que vous utilisez et comparer les deux répertoires. Si vous avez des personnalisations du code, vous devrez en faire un correctif, peut-être en effectuant un diff des deux répertoires, et en réappliquant plus tard ce correctif. Si vous personnalisez votre Bugzilla localement, envisager le « rebasing » de votre installation avec git.

3.11.5.2. Télécharger la nouvelle version de Bugzilla¶

Téléchargez une copie de la dernière version de Bugzilla sur la page de téléchargements dans un répertoire séparé (que nous appellerons bugzilla-new) à côté de votre installation existante (que nous supposerons installé dans un répertoire appelé bugzilla).

3.11.5.3. Recopier les données et les modules¶

Copiez le contenu des répertoires suivants de votre installation Bugzilla actuelle vers les répertoires correspondants dans bugzilla-new/:

lib/
data/
template/en/custom (peut ne pas exister)

Vous devrez aussi copier les extensions que vous avez écrites ou installées, qui se trouvent dans le répertoire extensions/. Bugzilla fournit quelques extensions, donc si vous voulez savoir si certaines extensions installées sont les vôtres, vous pouvez faire une comparaison avec une copie vierge de votre version actuelle. Vous pouvez ignorer les extensions contenant un fichier disabled dnas leur répertoire - celles-ci ne sont pas activées.

Enfin, copiez le fichier suivant à partir de votre installation actuelle vers le répertoire correspondant dans bugzilla-new/ :

localconfig

Ce fichier contient les informations de connexion à votre base de données.

3.11.5.4. Basculer vers la nouvelle version¶

Maintenant, intervertissez les répertoires. À partir du répertoire contenant les répertoires bugzilla et bugzilla-new, exécutee les commandes suivantes :

mv bugzilla bugzilla-old

mv bugzilla-new bugzilla

cd bugzilla

3.11.5.5. 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.5.6. Terminer la mise à jour¶

Réactivez Bugzilla en effaçant le texte saisi dans le paramètre shutdownhtml.
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.