Construire un changelog automatique avec Gitlab-CI

Dans la vie d’un projet, il est forcément arrivé un moment où il était compliqué de suivre les tickets en cours et livrés, sur plusieurs environnements différents. C’est encore plus compliqué lorsqu’il s’agit d’applications mobiles sans codepush pour lesquelles il est nécessaire de déterminer quel build contient quel(s) ticket(s). C’est cette problématique que nous avons résolue.

Gestion de versions sur un projet mobile

Pour ajouter du contexte à la problématique, voici le gitflow utilisé sur notre projet mobile :

Nous créons chaque branche depuis la version de production, livrons chaque ticket en UAT, pour une version bien précise, tout en maintenant plusieurs versions d’application, une version “production” et la version N+1 qui contient les prochaines features. 

Un bon moyen pour déterminer la différence entre deux builds est d’utiliser git. Le “problème” c’est que nous faisons le merge de nos branches sur  “v1.X”. Il faut donc rajouter des tags à chaque merge de nos features vers les branches cibles.

Faire un tag à chaque merge semblait lourd, il a donc fallu utiliser la phase de build des applications mobiles via la CI afin de tagger les builds “réels” qui étaient générés. Cela permet d’éviter un certain nombre de tags inutiles. 

Au sujet des CI sur les applications, je vous invite à lire l’article d’Andréas Hanss sur l’intégration continue avec une application React Native, et ce qui change par rapport à une application native pour Android ou iOS.

Les tags ordonnés dans le temps pour incrémenter les versions

Maintenant que nous savons quand faire notre “git tag”, comment pouvons nous créer notre tag de façon à avoir un incrément entre la version N-1 et N. Ce qui est donc intéressant, est la mise en place de tags ordonnés dans le temps. L’avantage c’est que la commande “git tag” trie ses tags par ordre alphabétique croissant. Donc avoir le timestamp dans le tag nous permet d’avoir des tags ordonnés dans le temps.

Il est possible avec git de générer le timestamp d’un commit à partir de celui-ci via la commande suivante :

“Git show -s –format=%CT [COMMIT HASH]”

Et là c’est bingo ! Nous avons notre moyen de faire le tag, de manière ordonnée dans le temps. Il ne reste plus qu’à industrialiser cela à chaque phase de build.
L’avantage de le faire à chaque phase de build, c’est que si nous réutilisons une pipeline, le hash de commit ne bouge pas et donc le tag n’a pas à être refait.

Allons voir du côté du gitlab-ci.yml la mise en place :

Plusieurs choses à noter, nous utilisons des macstadiums pour générer nos builds sur lesquels nous avons installé des runner gitlab shells. Il faut savoir que le runner shell, par défaut, n’a pas d’accès en écriture au repository (du moins c’est ce que nous avons constaté lors du développement) sur lequel il est en train d’exécuter sa pipeline : il faut donc ajouter un nouveau remote sur lequel nous pouvons push des informations depuis la CI.

C’est grâce aux variables globales injectées dans la pipeline qu’il est possible d’ajouter un remote, volontairement appelé “origin_write” afin de ne pas écraser le remote “origin”. Vu que nous sommes sur des machines physiques et non des dockers, il se peut qu’un ancien build exécuté en amont ait déjà créé le remote. Afin de ne pas faire crash la pipeline, il est nécessaire de générer un code de sortie d’exécution de commande en status 0, d’où l’utilisation des doubles pipes à chaque action sur le remote.

Comment identifier la branche en cours d’utilisation

Autre variable globale utilisée, il s’agit de “CI_COMMIT_REF_NAME”. Cette variable permet de connaitre la branche en cours d’utilisation, dans notre cas, il s’agit donc de “v1.X-UAT” ou “v1.X”.

A quoi cela peut servir ? A créer un tag spécifique à la branche en cours, sinon il y aurait conflit dans les tags.

Au final, à chaque phase de build, nous avons un tag “AUTOTAG_[BRANCH]_[TIMESTAMP]” qui est généré, qui nous permet de faire le diff.

Il ne reste plus qu’à développer un petit script, fait en Node.js dans notre cas, qui vient lister les tags et générer le diff entre deux tags :

Nous utilisons une convention de messages de commit dans laquelle chaque commit doit avoir en préfixe le numéro du ticket, ce qui permet d’établir les numéros des tickets qui sont entre les deux tags cibles. Au final, cela donne le changelog des tickets contenus entre deux builds livrés sur AppCenter. Il ne reste plus qu’à mettre cette liste dans la release note et dans le channel slack partagé avec le client.

Voici un avant/après de cette mise en place :

Le client voit très facilement quel build utiliser pour vérifier et valider ses tickets et gagne un temps précieux et de l’autonomie quant à la récupération des builds.