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.
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
|
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é (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.
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 »).
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é.
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.
mysqldump --opt -u bugs -p bugs > bugs.sql
pg_dump --no-privileges --no-owner -h localhost -U bugs > bugs.sql
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.
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.
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.
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.
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.
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.
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.
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. |
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
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). |
Si vous avez des extensions installées, vous devrez aussi les copier
dans le nouveau répertoire bugzilla. Les extensions sont situées dans
|
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.
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.)
Soyez conscient que la mise à jour à partir d'un fichier correctif ne change pas les entrées
dans votre répertoire |
Maintenant que vous avez le nouveau code de Bugzilla, il reste quelques étapes à accomplir pour terminer votre mise à jour.
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).
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.
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
Le point (« . ») au début de la commande ./checksetup.pl est important et ne peut pas être omis. |
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. |
Effacez tout texte ou code HTML saisi dans le paramètre « shutdownhtml » pour ré-activer Bugzilla.
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.
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/
.