Intégration continue

L’ancienne méthode

Lors de la création du projet Gregorius, nous avons vite été confronté, avec le porteur du projet, à un problème d’orgaisation pour la mise à jour des contenus. En effet nous échangions les différentes versions des pages statiques du site web par mail, parfois avec ou sans pièce jointe. Ces mails se perdant dans le flux que je recevais quotidiennement, il m’arrivait de ne plus savoir quelle version était la plus à jour et donc de procéder à de mauvaises modifications.

En plus de ces potentielles erreurs, le travail était rendu plus long et plus complexe par la chaîne de traitement qu’il impliquait. Pour chaque modification souhaitée (changement d’une date, d’un nom, de ponctuation, etc.), je devais modifier le fichier html en local, puis l’envoyer sur le dépôt git d’Estrades, pour ensuite me connecter manuellement au serveur et appliquer diverses commandes de mise à jour. L’édition était alors modifiée, mais au prix d’erreurs potentielles, d’un travail de correction fait en double (par l’éditeur scientifique puis par moi) et de manipulations diverses sur le serveur pouvant conduire à de nombreuses erreurs.

À ce moment là, je me suis dit que nous pourrions essayer de trouver une méthode permettant à l’éditeur scientifique d’avoir la main sur ses propres modifications et, ainsi, de fluidifier la chaîne éditoriale.

La nouvelle méthode

mise en place de l’intégration continue

Nous nous sommes donc tournés vers notre collègue Régis Witz afin qu’il puisse nous aider à mettre en place une intégration continue pour Estrades. Désormais, c’est à travers l’interface Gitlab d’Huma-Num que les chercheuses.eurs peuvent procéder aux modifications des pages statiques de leur édition (attention, nous parlons bien ici des pages de présentation statiques, et non pas des pages qui résultent de transformation XSL). L’intégration continue (repérable par la présence d’un fichier .gitlab-ci.yml) permet alors de mettre automatiquement à jour sur le serveur les modifications apportées aux documents rédigés en markdown.

tentative de sobriété numérique

Cependant, nous nous sommes vite rendu compte qu’en vue des nombreuses modifications qui étaient apportées quotidiennement, nous appelions sans cesse le script d’intégration continue. Ce qui impliquait, à chaque commit, le téléchargement complet d’une image docker (alpine en l’occurence) de 3 méga, sans compter les autres téléchargements divers, et ce, parfois jusqu’à une cinquantaine de fois par jours ! On pouvait mieux faire en terme de sobriété numérique.

C’est pourquoi nous avons modifié le fichier gitlab.yml afin qu’il ne s’exécute que si une modification est réalisée dans un fichier à la racine appelé mises_a_jour.md. Ainsi, il est possible de réaliser toutes les modifications souhaitées des différents fichiers .md sans que cela ne lance l’intégration continue immédiatement. À la fin de la session de modifications, il n’y a plus qu’à modifier le fichier mises_a_jour.md pour que les changements soient effectifs.

Bien sûr, nous aurions également pu mettre en place un cron gitlab pour programmer cette mise à jour tous les jours à intervalle régulier ou même de manière plus sporadique. Mais cela aurait empêcher à l’éditeur scientifique de contrôler au fil de l’eau ses modifications sur le site de développement.

Il ne s’agit que d’une solution, et nous sommes ouverts à toute remarque et conseil pour améliorer notre pipeline !

branche `dev` et `main`