2.7. Mettre à jour vers de nouvelles versions

Mettre à jour vers une nouvelle version de Bugzilla est très facile. Il y a un script checksetup.pl inclus dans Bugzilla qui fera automatiquement toute la migration de la base de données pour vous.

Les sections suivantes expliquent comment mettre à jour d'une version Bugzilla à une autre. Que vous mettiez à jour d'une version corrective à une autre (comme par exemple de 4.2 à 4.2.1) ou d'une version majeure à une autre (comme par exemple de 4.0 à 4.2), les instructions sont toujours les mêmes.

[Note]

Les exemples des sections suivantes sont écrits pour un utilisateur faisant une mise à jour à partir d'une version 4.2.1, mais les procédures sont les mêmes quelle que soit la version. Également, dans les exemples, l'installation Bugzilla de l'utilisateur se trouve dans /var/www/html/bugzilla. Si ce n'est pas le même emplacement que pour votre installation, substituez simplement les chemins d'installation quand c'est approprié.

2.7.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é (Section 3.16, « Vérifier et maintenir l'intégrité de la base de données ») 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. Arrêter votre installation Bugzilla en ajoutant du texte ou du code HTML dans le paramètre « shutdownhtml » (voir Section 3.1, « Configuration de Bugzilla »).

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

    [Avertissement]

    La mise à jour ne fonctionne que dans un sens. Vous ne pouvez pas « descendre » d'une version de Bugzilla. Si vous voulez revenir à l'ancienne version de Bugzilla pour quelque raison que ce soit, vous devrez restaurer votre base de données à partir de cette sauvegarde.

    Voici quelques exemples de commandes que vous pourriez utiliser pour sauvegarder votre base de données, en fonction du système de gestion de base de données que vous utilisez. Vous pourriez avoir à modifier ces commandes en fonction de vos paramètres d'installation.

    MySQL :

    mysqldump --opt -u bugs -p bugs > bugs.sql

    PostgreSQL :

    pg_dump --no-privileges --no-owner -h localhost -U bugs > bugs.sql

2.7.2. Obtenir la nouvelle version de Bugzilla

Il existe trois moyens d'obtenir la nouvelle version de Bugzilla. Nous allons les lister brièvement ici, puis nous les expliquerons plus en détail ensuite.

Bzr (Section 2.7.2.2, « Mettre à jour en utilisant Bzr »)

Si bzr est installé sur votre machine et que vous avez un accès à Internet, ceci est le moyen le plus facile pour mettre à jour, en particulier si vous avez fait des modifications dans le code ou les templates de Bugzilla.

Télécharger l'archive (Section 2.7.2.3, « Mettre à jour en utilisant l'archive »)

Ceci est un moyen très simple de mettre à jour, et bien si vous n'avez fait que peu (ou pas) de modifications dans le code ou dans les templates de Bugzilla.

Correctifs (Section 2.7.2.4, « Mettre à jour en utilisant les correctifs »)

Si vous avez des modifications dans votre installation Bugzilla et que vous n'avez pas d'accès à Internet ou que vous ne voulez pas utiliser cvs, alors ceci est le meilleur moyen de mise à jour.

Vous ne pouvez faire que des mises à jour mineures (comme par exemple de 4.2 à 4.2.1 ou de 4.2.1 à 4.2.2) avec les correctifs.

2.7.2.1. 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 Section 6.3.2, « 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.

2.7.2.2. Mettre à jour en utilisant Bzr

Ceci nécessite que bzr soit installé (c'est le cas pour la plupart des machines Unix), et aussi que vous puissiez accéder à bzr.mozilla.org, ce qui peut ne pas être une option si vous n'avez pas d'accès à Internet.

Ci-dessous, la séquence des commandes nécessaires pour mettre à jour une installation Bugzilla par Bzr, et les résultats typiques obtenus. En supposant que Bugzilla a déjà éé installé en utilisant Bzr.

[Avertissement]

Si votre installation utilise encore CVS, vous devez d'abord la convertir vers Bzr. Une documentation très détaillée est disponible sur wiki.mozilla.org.

bash$ cd /var/www/html/bugzilla
bash$ bzr switch 4.2 (n'utilisez cette commande que si vous n'utilisez pas déjà la version 4.2)
bash$ bzr up -r tag:bugzilla-4.2.1
+N  extensions/MoreBugUrl/
+N  extensions/MoreBugUrl/Config.pm
+N  extensions/MoreBugUrl/Extension.pm
…
 M  Bugzilla/Attachment.pm
 M  Bugzilla/Attachment/PatchReader.pm
 M  Bugzilla/Bug.pm
…
All changes applied successfully.
        
[Attention]

Si une ligne de résultat de bzr update mentionne un conflit, cela représente alors un fichier avec des changements locaux que Bzr n'est pas capable de fusionner correctement. Vous devez résoudre manuellement ces conflits avant que Bugzilla (ou tout au moins la portion utilisant ce fichier) ne soit utilisable.

2.7.2.3. Mettre à jour en utilisant l'archive

Si vous ne pouvez (ou ne voulez) pas utiliser Bzr, 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.

Cette séquence de commandes montre comment obtenir l'archive en ligne de commande ; il est aussi possible de la télécharger à partir du site directement dans le navigateur. Si vous procédez ainsi, enregistrez le fichier dans le répertoire /var/www/html (ou son équivalent, si vous utilisez autre chose) et passez les trois premières lignes de l'exemple.

bash$ cd /var/www/html
bash$ wget http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-4.2.1.tar.gz
(Affichage des résultats omis)
bash$ tar xzvf bugzilla-4.2.1.tar.gz
bugzilla-4.2.1/
bugzilla-4.2.1/colchange.cgi
(Affichage des résultats tronqué)
bash$ cd bugzilla-4.2.1
bash$ cp ../bugzilla/localconfig* .
bash$ cp -r ../bugzilla/data .
bash$ cd ..
bash$ mv bugzilla bugzilla.old
bash$ mv bugzilla-4.2.1 bugzilla
        
[Avertissement]

Les commandes cp se terminent toutes deux avec un point (« . »), ce qui est un détail important (cela signifie que le répertoire de destination est le répertoire de travail courant).

[Attention]

Si vous avez des extensions installées, vous devrez aussi les copier dans le nouveau répertoire bugzilla. Les extensions sont situées dans bugzilla/extensions/. Ne copiez que celles que vous avez installées, pas celles gérées par l'équipe de Bugzilla.

Cette méthode de mise à jour vous donnera une installation propre de Bugzilla. Ce qui est très bien si vous n'avez pas de personnalisations locales que vous voulez maintenir. Si vous avez des personnalisations, vous devrez alors les réappliquer manuellement dans les fichiers appropriés.

2.7.2.4. Mettre à jour en utilisant les correctifs

Un correctif est un ensemble de corrections de bogues qui ont été faites depuis la version mineure précédente.

Si vous faites une mise à jour par correctif (c'est-à-dire, où seule le dernier numéro de révsion change, comme par exemple de 4.2 à 4.2.1), alors vous pouvez obtenir et appliquer le fichier correctif à partir de la Page de téléchargements.

Comme précédemment, cet exemple commence par l'obtention du fichier en ligne de commande. Si vous l'avez déjà téléchargé, vous pouvez passer les deux premières commandes.

bash$ cd /var/www/html/bugzilla
bash$ wget http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-4.2-to-4.2.1.diff.gz
(Affichage des résultats omis)
bash$ gunzip bugzilla-4.2-to-4.2.1.diff.gz
bash$ patch -p1 < bugzilla-4.2-to-4.2.1.diff
patching file Bugzilla/Constants.pm
patching file enter_bug.cgi
(etc.)
        
[Avertissement]

Soyez conscient que la mise à jour à partir d'un fichier correctif ne change pas les entrées dans votre répertoire .bzr. Ceci pourrait rendre plus difficile une mise à jour en utilisant Bzr (Section 2.7.2.2, « Mettre à jour en utilisant Bzr ») dans le futur.

2.7.3. Terminer la mise à jour

Maintenant que vous avez le nouveau code de Bugzilla, il reste quelques étapes à accomplir pour terminer votre mise à jour.

  1. Si votre nouvelle installation Bugzilla est dans un répertoire différent ou sur une machine différente de celle de votre ancienne installation Bugzilla, assurez-vous d'avoir copié le répertoire data et le fichier localconfig de votre ancienne installation Bugzilla. (Si vous avez suivi les instructions d'installation via l'archive ci-dessus, c'est déjà fait).

  2. S'il s'agit d'une mise à jour majeure, vérifiez que la configuration (Section 2.2, « Configuration ») pour votre nouvelle installation de Bugzilla est à jour. Quelquefois, les prérequis de configuration changent entre une version majeure et une autre.

  3. Si vous ne l'avez pas fait dans l'étape de configuration ci-dessus, vous devez maintenant exécuter checksetup.pl, qui fera tout ce qui est nécessaire pour convertir votre base de données existante et les paramètres pour la nouvelle version :

    bash$ cd /var/www/html/bugzilla
    bash$ ./checksetup.pl
              
    [Avertissement]

    Le point (« . ») au début de la commande ./checksetup.pl est important et ne peut pas être omis.

    [Attention]

    S'il s'agit d'une mise à jour majeure (disons de 3.6 à 4.2 ou similaire), l'exécution de checksetup.pl sur une grosse installation (75 000 bogues ou plus) peut prendre un long moment, parfois plusieurs heures.

  4. Effacez tout texte ou code HTML saisi dans le paramètre « shutdownhtml » pour ré-activer Bugzilla.

  5. Consultez la page (Section 3.16, « Vérifier et maintenir l'intégrité de la base de données ») Contrôle d'intégrité dans votre installation de Bugzilla mise à jour.

    Il est recommandé, dans la mesure du possible, de corriger immédiatement tout problème que vous voyez. Ne pas le faire peut signifier que Bugzilla ne fonctionnera pas correctement. Veuillez noter que si la page de contrôle d'intégrité contient plus d'erreurs après une mise à jour, cela ne veut pas nécessairement dire qu'il y a plus d'erreurs dans votre base de données qu'auparavant, car des tests additionnels sont ajoutés au contrôle d'intégrité avec le temps et il est possible que ces erreurs nétaient pas vérifiées dans la version précédente.

2.7.4. Notifications automatiques pour les nouvelles versions

Bugzilla 3.0 a introduit la possibilité de notifier automatiquement les administrateurs lorsque de nouvelles versions sont disponibles, en fonction du paramètre upgrade_notification, voir Section 3.1, « Configuration de Bugzilla ». Les administrateurs verront ces notifications en accédant à la page index.cgi, c-à-d. généralement lors de la connexion. Bugzilla vérifie une fois par jour la présence de nouvelles versions, à moins que le paramètre soit défini à « désactivé ». Si vous êtes placé derrière un proxy, vous pourriez avoir à définir le paramètre proxy_url de façon appropriée. Si le proxy nécessite une authentification, utilisez la synatxe http://utilisateur:mot_de_passe@url_proxy/.