• Application d’un hotfix à passer en stable 2.3
  • Prérequis
  • Déterminer la version à corriger
  • Déterminer le commit de la branche source
  • Créer une branche pour le hotfix
  • Corriger le bug
  • Créer une branche pour empaqueter le correctif
  • Intégrer le correctif
  • Mettre à jour debian/changelog
    • Déterminer le nouveau numéro de version
    • Vérifier les informations de log
    • Modifier debian/changelog
    • Commit
  • Compiler le paquet à la main sur les serveurs de build
  • Publier le paquet sur le dépôt debian
  • Faire tester le correctif présent sur test-eoleng.ac-dijon.fr
  • Éviter les régressions
    • Intégrer à « $SRC »
    • Publier le tag du nouveau paquet
  • Nettoyage

Application d’un hotfix à passer en stable 2.3¶

Prérequis¶

• Le paquet est à distribuer dans eole-2.3-updates
• « DEBEMAIL="Equipe EOLE <eole@ac-dijon.fr>" »: nom et mail utilisés pour la commande dch
• « $DEV_NAME » : le prénom et nom du développeur qui fait la correction
• « DISTRIB=eole-2.3-updates » : nom de la distribution EOLE
• « $ISSUE » : numéro de la demande redmine
• « $PAQUET » : le nom du paquet (et du dépôt git)
• « SRC=2.3 » : la branche source
• « PKG=dist/ubuntu/lucid/master » : la branche de packaging
• « $COMMIT_ID » : l’identifiant du commit de la branche 2.3 depuis lequel on fait le correctif (calculé ci-dessous)
• « $PROD_VERSION » : numéro de version du paquet diffusé (calculé ci-dessous)
• « $NEW_VERSION » : nouveau numéro de version comprenant le correctif (calculé ci-dessous)

Déterminer la version à corriger¶

root@server:~# dpkg -l $PAQUET
ii $PAQUET ${PROD_VERSION} <arch> <description>

La version est ${PROD_VERSION}.

Déterminer le commit de la branche source¶

Ne s’applique pas à des corrections de packaging

Le source qui a servi à la compilation du paquet debian est accessible par le tag « debian/${PROD_VERSION} ».

Ce tag pointe sur un commit de la branche de packaging « $PKG ».

À partir de ce tag, il faut déterminer, en remontant l’historique, le premier commit de la branch source, c’est à dire le premier commit présent dans les deux branches.

Cela peut être fait à la main en parcourant le log de « debian/${PROD_VERSION} » :

moi@work:~/src/$PAQUET (master)$ git log debian/${PROD_VERSION}

Il est possible de le faire de façon programmatique en déterminant quelle est la base de fusion entre le tag et la branche source avec la commande « git merge-base » :

moi@work:~/src/$PAQUET (master)$ COMMIT_ID=$(git merge-base debian/${PROD_VERSION} $SRC)

L’identifiant du commit est noté « $COMMIT_ID ».

Créer une branche pour le hotfix¶

Il faut créer une nouvelle branche basée sur « $COMMIT_ID » afin de n’appliquer que la correction, nous lui donnons un nom en rapport avec une demande, par exemple avec la demande № « $ISSUE » :

moi@work:~/src/$PAQUET (master)$ git checkout -b hotfix/$ISSUE $COMMIT_ID
moi@work:~/src/$PAQUET (hotfix/$ISSUE)$

Corriger le bug¶

Et ne rien faire d’autre que corriger le bug afin de limiter au maximum les problèmes.

Normalement il ne devrait y avoir qu’un seul commit.

À voir au cas par cas, si une partie de la correction est à intégrer ailleurs alors cela peut-être fait en plusieurs commits.

Créer une branche pour empaqueter le correctif¶

Il faut créer une nouvelle branche basée sur le paquet à corriger (représenté par le tag « debian/${PROD_VERSION} ») :

moi@work:~/src/$PAQUET (master)$ git checkout -b pkg/hotfix/$ISSUE debian/${PROD_VERSION}
moi@work:~/src/$PAQUET (pkg/hotfix/$ISSUE)$

Intégrer le correctif¶

moi@work:~/src/$PAQUET (pkg/hotfix/$ISSUE)$ git merge --no-ff hotfix/$ISSUE

Mettre à jour debian/changelog¶

Cela peut-être fait en ajoutant une entrée à la main ou via l’utilitaire « dch » fourni par le paquet debian « devscripts ».

Nous allons détailler étape par étape afin de vérifier avant de publier une bêtise ;-)

Déterminer le nouveau numéro de version¶

• Si le précédent numéro n’était pas celui d’un correctif, ajouter le suffix « +1 », par exemple, si « PROD_VERSION=2.3-eole76 », cela donne: « 2.3-eole76+1 »
• Sinon, incrémenter le chiffre après le « + », par exemple, si « PROD_VERSION=2.3-eole76+2 », cela donne: « 2.3-eole76+3 »

La nouvelle version est notée « $NEW_VERSION ».

Vérifier les informations de log¶

Il ne devrait y avoir qu’un commit de différence entre « $COMMIT_ID » et la branche de hotfix « hotfix/$ISSUE », (sauf cas exceptionnel), nous utilisons un format court utilisable comme ligne de
« debian/changelog » :

moi@work:~/src/$PAQUET (pkg/hotfix/$ISSUE)$ git log --format='[%h] %s' ${COMMIT_ID}..hotfix/$ISSUE

Modifier debian/changelog¶

De façon automatique avec l’utilitaire « dch », il s’agit d’utiliser correctement les informations recueillies jusqu’à présent :

moi@work:~/src/$PAQUET (pkg/hotfix/$ISSUE)$ DEBEMAIL=$DEBEMAIL dch --no-auto-nmu --multimaint --multimaint-merge \
    --distribution=$DISTRIB \
    -v "${NEW_VERSION}" -- \
    "$(git log --format='[%h] %s' ${COMMIT_ID}..hotfix/$ISSUE)" 

Commit¶

moi@work:~/src/$PAQUET (pkg/hotfix/$ISSUE)$ git add debian/changelog
moi@work:~/src/$PAQUET (pkg/hotfix/$ISSUE)$ git commit \
    -m "Nouveau paquet compilé par $DEV_NAME: $PAQUET ($NEW_VERSION) $DISTRIB depuis pkg/hotfix/$ISSUE" 

Compiler le paquet à la main sur les serveurs de build¶

Demander à Joël Cuissinat ou Daniel Dehennin ;-)

Cela permet de faire une validation en plus.

moi@work:~/src/$PAQUET ($SRC)$ git archive --prefix=${PAQUET}-2.3/ \
    -o ${PAQUET}-2.3.tar.gz \
    pkg/hotfix/$ISSUE
moi@work:~/src/$PAQUET ($SRC)$ ssh eole@lucid32 mkdir -p tmp/$PAQUET/
moi@work:~/src/$PAQUET ($SRC)$ scp ${PAQUET}-2.3.tar.gz eole@lucid32:tmp/$PAQUET/
moi@work:~/src/$PAQUET ($SRC)$ ssh eole@lucid32
eole@lucid32:~$ cd ~/tmp/$PAQUET/ && tar -xzvf ${PAQUET}-2.3.tar.gz
eole@lucid32:~/tmp/$PAQUET$ cd ${PAQUET}-2.3
eole@lucid32:~/tmp/$PAQUET/${PAQUET}-2.3$ dpkg-buildpackage -rfakeroot

Publier le paquet sur le dépôt debian¶

Demander à Joël Cuissinat ou Daniel Dehennin ;-)

Ils le feront directement depuis le serveur de build

eole@lucid32:~/tmp/${PAQUET}-2.3$ dput eole ../${PAQUET}_2.3*.changes

Faire tester le correctif présent sur test-eoleng.ac-dijon.fr¶

Même si le paquet compilé est publié, il n’est pas lâché dans la nature directement, il y a un sas de sécurité avec test-eoleng.ac-dijon.fr.

Une fois que l’utilisateur confirme que la chose est bien corrigée, le paquet sera envoyé sur les dépôts de production.

Éviter les régressions¶

Il ne faut pas oublier d’intégrer les modifications à la branche $SRC afin que le prochain paquet aie lui aussi le correctif

Intégrer à « $SRC »¶

moi@work:~/src/$PAQUET (pkg/hotfix/$ISSUE)$ git checkout $SRC
moi@work:~/src/$PAQUET ($SRC)$ git merge --no-ff hotfix/$ISSUE

Publier le tag du nouveau paquet¶

Afin de garder une trace et de permettre une possible correction sur le paquet corrigé, il faut publier une référence qui sera utilisable dans la phase 2 de cette documentation « Déterminer le commit
de la branche source ».

Pour cela nous créons un tag signé par GPG :

moi@work:~/src/$PAQUET ($SRC)$ git tag -s \
    -m "Debian release $NEW_VERSION" \
    debian/$NEW_VERSION \
    pkg/hotfix/$ISSUE

Et on le publie sur le dépôt git central :

moi@work:~/src/$PAQUET ($SRC)$ git push origin debian/$NEW_VERSION

Nettoyage¶

On peut maintenant :

• Supprimer la branche « hotfix/$ISSUE » car elle est intégrée à « $SRC » ;
• Supprimer la branche « pkg/hotfix/$ISSUE » car le prochain paquet intégrera le correctif via la branche « $SRC ».