Scheduled pipelines : planifiez et automatisez vos workflows de déploiement

Plus de 4 millions d’organisations ont choisi GitHub pour héberger leurs projets. Ce choix semble logique lorsqu’on considère l’ensemble des avantages et services que propose cette usine logicielle.

Parmi ces services, on retrouve classiquement l’intégration (CI) et le déploiement continus (CD).

Les workflows CI/CD peuvent être mis en place facilement dans les usines logicielles les plus connues : GitHub, GitLab et Azure DevOps.

Dans cet article, nous allons voir comment on peut planifier les déploiements sur chacune de ces plateformes.

Contexte

Pour illustrer l’usage des scheduled pipelines, nous allons considérer le scénario suivant : une entreprise souhaite déployer en production la dernière version de son API tous les vendredis à partir de 19h.

Le code source de la dernière version d’API se trouve sur la branche GIT « release».

Prérequis pour planifier un pipeline

Pour planifier un pipeline, il est nécessaire d’aborder les expressions cron.

Définition : une expression cron est une chaine de caractères avec un ensemble de champs qui décrivent une planification.

Format : {minute} {heure} {jour dans le mois} {mois} {jour de la semaine}

Dans notre contexte, nous allons décrire la fréquence d’exécution de notre pipeline sous forme d’expression cron :

0 : minute

19 : heure

*: jour dans le mois

*: mois

5 : jour de la semaine (vendredi)

Nous recommandons vivement d’utiliser crontab.guru pour visualiser et valider l’expression définie dans le cron.

Azure DevOps – Pipelines

Après vous être authentifié sur le portail Azure DevOps de votre organisation, il faudra sélectionner le projet souhaité.

Depuis la page du projet, on peut alors créer un pipeline depuis l’onglet « Pipelines ».

Pour démarrer, on choisit « Azure Repos Git ».

On choisit ensuite le projet qui va héberger le pipeline :

On peut alors choisir de créer un nouveau pipeline ou sélectionner un pipeline déjà créé sur le dépôt Git.

⚠️ Attention : le fichier YAML décrivant le pipeline doit être créé ou modifié depuis la branche ciblée par la tâche planifiée. Dans notre contexte, le fichier doit être créé sur la branche « release ».

Finalement, on peut cliquer sur « Save and run » pour sauvegarder le pipeline.

Remarque : le paramètre always : true permet de garantir que le pipeline sera exécuté même si aucun changement de code n’a été détecté sur la branche release.

Vérification du pipeline planifié

Depuis le portail Azure DevOps, il est possible de vérifier les prochaines occurrences planifiées d’un pipeline.

Il faut d’abord ouvrir le pipeline depuis l’onglet Pipelines.

On peut retrouver la liste depuis l’onglet « Scheduled runs » dans le menu situé en haut à droite.

Limitations des scheduled pipelines sur Azure DevOps

Les limitations des scheduled pipelines sur Azure DevOps sont les suivantes :

• Environ 1000 exécutions par semaine
• 10 exécutions par pipeline toutes les 15 minutes
• Le fuseau horaire utilisé dans Azure DevOps est UTC

Pipeline – Classic Mode

Dans Azure DevOps, lors de la création d’un pipeline, il est possible d’utiliser le mode classique (consulter la documentation Microsoft). Nous n’abordons pas ce mode dans cet article, mais nous soulignons le fait que le mode classique permet de choisir le fuseau horaire, contrairement au mode YAML.

Planifier les déploiements sur GitHub Actions

Depuis GitHub , on peut sélectionner le dépôt Git sur lequel on souhaite planifier un déploiement.

Depuis le menu « Actions », on a accès à l’ensemble des pipelines (« workflow ») liés au dépôt.

On peut créer un nouveau pipeline en cliquant sur le bouton « new Workflow ».

Si un pipeline existe déjà, il s’affiche alors dans la liste des Workflows.

Contrairement à Azure DevOps, sur GitHub, le pipeline planifié doit être créé sur la branche « main » et non pas sur la branche ciblée.

Vérification du pipeline planifié

GitHub ne dispose pas d’un menu affichant les prochaines occurrences planifiées d’un pipeline. Il est uniquement possible de vérifier les résultats des exécutions passées et filtrer par type d’évènement « schedule ».

Limitations des scheduled pipelines sur GitHub

Les limitations des scheduled pipelines sur GitHub sont les suivantes (source : documentation GitHub) :

• L’intervalle minimum séparant deux exécutions planifiées est de 5 minutes.
• Lors des périodes de forte activité côté GitHub Actions, les tâches planifiées peuvent être retardées, voire abandonnées.
• Si le dépôt est public, le workflow sera désactivé si aucune activité n’a été détectée dans les 60 derniers jours.
• Le fuseau horaire utilisé dans GitHub est UTC.

Planifier les déploiements sur GitLab

Depuis GitLab , on peut sélectionner le dépôt Git sur lequel on souhaite planifier un déploiement.

Sur GitLab, le pipeline et son planificateur sont dissociés.

On peut éditer le script de déploiement depuis le menu Build, en sélectionnant Pipeline editor.

Le planificateur peut être édité uniquement depuis Pipeline schedules. Contrairement à Azure DevOps et GitHub, le planificateur de GitLab ne peut pas être décrit directement dans le fichier yaml.

On peut créer une tâche planifiée en cliquant sur New Schedule.

GitLab est la seule usine logicielle qui prend en compte le fuseau horaire dans la scheduled pipeline.

Vérification du scheduled pipeline

On peut retrouver les traces d’exécutions ainsi que les prochaines occurrences du pipeline depuis la page Pipeline Schedules.

Limitations des scheduled pipelines sur GitLab

Les limitations des scheduled pipelines sur GitLab sont les suivantes (source documentation Gitlab) :

• L’intervalle minimum séparant deux exécutions planifiées est 5 minutes.

Niveau gratuit :

• 10 projets maximum peuvent contenir un scheduled pipeline
• Un scheduled pipeline peut s’exécuter jusqu’à 24 fois/jour

Abonnement payant

• 50 projets maximum peuvent contenir un scheduled pipeline
• Un scheduled pipeline peut s’exécuter jusqu’à 288 fois/jour

Remarque : on constate dans les faits que les limitations renseignées par GitLab ne sont pas tout à fait complètes. La limitation à 24 fois/jour est en réalité une limitation à 1 fois/heure chaque jour (voir capture d’écran précédente).

L’essentiel à retenir sur les scheduled pipelines

Nous avons vu dans cet article comment planifier l’exécution de pipeline depuis Azure DevOps, GitHub et GitLab.

Chacune des usines logicielles propose une solution simple pour mettre en place les scheduled pipelines avec quelques limitations.

Voici quelques cas d’usage qui peuvent tirer avantage des scheduled pipelines :

• Déployer une nouvelle version d’API sur Azure tous les vendredis
• Lancer un nighty build et des séries de tests unitaires sur des projets entre minuit et 5 heures du matin
• Mettre en place un environnement Sandbox sur Azure et le supprimer à la fin de la journée avec Terraform

Vous souhaitez être accompagnés dans vos projets de transformation numérique ? Contactez-nous !