3.11.4. Migrer à partir d’une archive
La procédure pour migrer vers Git est comme suit. L’idée est de basculer vers Git sans changer la version de Bugzilla que vous utilisez pour mimnimiser les risques de conflits ou de problèmes. La mise à jour est effectuée ensuite dans une autre étape.
3.11.4.1. Télécharger le code avec Git
Tout d’abord, vous devez trouver la version de Bugzilla que vous utilisez. Elle devrait se trouver
dans le coin supérieur droit de la page d’accueil. Si ce n’est pas le cas, ouvrez le
fichier Bugzilla/Constants.pm dans votre répertoire Bugzilla et
recherchez BUGZILLA_VERSION.
Ensuite, vous devrez télécharger une copie supplémentaire de votre version actuelle de
Bugzilla à partir du dépôt Git, et la placer dans un répertoire séparé à côté
de votre installation Bugzilla existante (nous supposerons qu’elle se trouve dans un répertoire
appelé bugzilla).
Pour faire cela, vous aurez besoin d’une copie du programme git. Toutes les
distributions Linux en ont une. Recherchez dans votre gestionnaire de paquets git. Sous Windows ou
Mac OS X, vous pouvez
télécharger le binaire officiel.
Une fois Git installé, exécutez ces commandes pour récupérer une copie de Bugzilla :
git clone https://git.mozilla.org/bugzilla/bugzilla bugzilla-new
cd bugzilla-new
git checkout release-$VERSION
Remplacez $VERSION avec le nombre à trois chiffres de la version de votre installation actuelle de Bugzilla,
par ex. 4.2.2. (Si le dernier chiffre est un 0, omettez-le – utilisez donc
4.4 pour la première version de la série 4.4).
Vous verrez un message indiquant “detached HEAD”. Ne vous inquiétez pas, votre tête est toujours solidement attachée à vos épaules.
3.11.4.2. Sauvegarder les personnalisations locales
Rendez-vous dans votre répertoire actuel de Bugzilla et exécutez la commande suivante :
diff -ru -x data -x lib -x docs -x .git -x CVS -x .cvsignore -x .bzr -x .bzrignore -x .bzrrev ../bugzilla-new . > ../patch.diff
Si vous avez réalisé des personnalisations dans votre installation Bugzilla et que vous l’avez fait
en modifiant directement le code de Bugzilla (au lieu d’utiliser le système d’extension),
alors le fichier patch.diff contiendra beaucoup de contenu. Conserver une copie de ce fichier
et des modifications référencées par les lignes
Only in. Si le fichier est vide ou s’il ne contient que du contenu insignifiant,
vous n’avez pas fait de personnalisations de ce genre.
3.11.4.3. Arrêter Bugzilla
Maintenant, vosu devez arrêter Bugzilla pour être sûr qu’aucun changement ne survienne
pendant la bascule. Rendez-vous dans l’interface d’administration et saisissez un message
approprié dans le paramètre shutdownhtml, qui se trouve dans la section
Général des paramètres d’administration. Comme son nom l’indique, le code HTML
y est autorisé.
C’est le bon moment pour faire des Sauvegardes. Nous ne devrions pas toucher à la base de données, mais on ne saurait être trop prudent.
3.11.4.4. Copier les données et les modules
Copiez le contenu des répertoires suivants à partir de votre installation
de Bugzilla actuelle vers le répertoire correspondant dans bugzilla-new/:
lib/
data/
template/en/custom (ce répertoire peut ne pas exister)
Vous devrez aussi copier toutes les extensions que vous avez écrites ou installées, qui se trouvent
dans le répertoire extensions/. Recopie tout sous-répertoire qui n’existe pas
dans votre nouvelle installation.
Enfin, copiez le fichier suivant à partir de votre installation actuelle de Bugzilla
dans l’emplacement correspondant dans bugzilla-new/:
localconfig
Ce fichier contient le mot de passe et les détails de l’accès à la base de données. Vos deux versions de Bugzilla étant identiques, cela devrait fonctionner sans problème.
3.11.4.5. Réappliquer les personnalisations locales
Si votre fichier patch.diff est vide, vous pouvez passer
à létape suivante. dans le cas contraire, vous devez appliquer le correctif dans votre nouvelle installation.
Si vous êtes sous Windows et que vous n’avez pas le programme patch,
vous pouvez le télécharger sur
GNUWin. Une fois téléchargé,
vous devez copier l’exécutable patch.exe dans le répertoire Windows.
Copiez patch.diff dans le répertoire bugzilla-new puis exécutez la commande suivante :
patch -p0 --dry-run < patch.diff
Le correctif devrait s’appliquer correctement car vous avez exactement la même version de Bugzilla dans les deux répertoire. Si c’est le cas, retirer l’argument --dry-run de la ligne de commande et relancez la commande pour appliquer les modifications. Si ce n’est pas le cas, c’est que vous avez des versions de Bugzilla différentes dans les deux répertoires.
3.11.4.6. Basculer vers la nouvelle version
Maintenant, intervertissez les répertoires et exécutez checksetup.pl pour confirmer que tout
va bien. À partir du répertoire contenant les répertoires bugzilla
et bugzilla-new, exécutez les commandes suivantes :
mv bugzilla bugzilla-old
mv bugzilla-new bugzilla
cd bugzilla
./checksetup.pl
L’exécution de checksetup.pl ne devrait pas modifier votre base de données.
Si c’est le cas, c’est que vous avez deux versions
de Bugzilla différentes.
3.11.4.7. Réactiver Bugzilla
Rendez-vous dans l’interface d’administration et supprimez le contenu du paramètre shutdownhtml.
3.11.4.8. Tester Bugzilla
Utilisez Bugzilla pendant plusieurs jours pour vérifier que la bascule n’a pas eu d’effet de bord. Ensuite, si nécessaire, suivez les instructions dans Mettre à jour avec Git pour mettre à jour vers la dernière version de Bugzilla.
3.11.4.9. Revenir en arrière
Si quelque chose s’est mal passé pendant le processus (par ex. votre
correctif ne s’est pas appliqué ou checksetup.pl renvoie des erreurs), vous pouvez toujours
réintervertir les répertoires (si vous êtes arrivé jusque là) et réactiver Bugzilla
(si vous l’aviez désactivé) et recherchez de l’aide. Même si vous avez réactivé Bugzilla,
et que vous rencontrez des problèmes peu de temps après, vous utilisez toujours la même
version, donc il ne devrait pas y avoir pour revenir en arrière deux à trois jours après.
Cette documentation contient très probablement des bogues ; si vous en découvrez, veuillez les signaler ici.