Workflows Static env rules Dynamic env Améliorations

GitLab Flow
Pipelines avancés
F. Michel
Workflows Static env rules Dynamic env Améliorations

Plan

1 Les principaux workflows associés à Git

2 Environnements statiques

3 Rules

4 Environnements dynamiques

5 Amélioration du pipeline

2
Workflows Static env rules Dynamic env Améliorations

Plan

1 Les principaux workflows associés à Git

2 Environnements statiques

3 Rules

4 Environnements dynamiques

5 Amélioration du pipeline

3
Workflows Static env rules Dynamic env Améliorations

Nécessité d’adopter un workflow

Pour l’instant nos pipelines ne prennent pas en compte les

possibilités offertes par Git, à savoir le mécanisme de branches.

L’idée est d’organiser le flux du développement en respectant un

processus standardisé pour la création des features, releases, fixes,
etc. et d’organiser le CI/CD en conséquence.

Principes généraux d’un workflow basé sur Git

Permettre un travail collectif efficace
Suivre les modifications apportées au code source simplement
Introduire des points de relecture avant validation (merge requests)
Distinguer pré-production vs. production
Automatiser le déploiement et la création de releases, en fonction des
branches

4
Workflows Static env rules Dynamic env Améliorations

GitFlow

Basé sur 2 branches principales : master et develop

les branches de fonctionnalités sont créées à partir develop
puis fusionnées dans develop, une fois testées et validées
develop est fusionnée dans master lorsqu’on souhaite créer une release
les versions, commits tagués, sont créées sur master

5
Workflows Static env rules Dynamic env Améliorations

GitHub Flow

Basé sur une seule branche principale (e.g. master)

les branches de fonctionnalités sont créées à partir de master
puis fusionnées dans master, une fois testées et validées
les versions, commits tagués, sont créées sur master

6
Workflows Static env rules Dynamic env Améliorations

GitLab Flow
Une variante de GitFlow qui ne fixe pas le nom et le nombre de
branches pour la pré/production : pas de branche develop GitLab Flow

Il en existe deux variantes :

Avec des branches d’environnements : environment branches
Deux branches principales : main et production
les branches de fonctionnalités sont créées à partir de main
puis testées/déployées dans autant de branches d’environnements
(pré-production) que nécessaires : tests, acceptation, . . .
puis fusionnées dans la branche main, puis dans la branche production

Avec des branches releases

Idem mais avec une branche principale et des branches de version
(long terme)
⇒ convient lorsqu’on produit du logiciel téléchargeable

7
Workflows Static env rules Dynamic env Améliorations

GitLab Flow / Principes de mises en œuvre

Bonnes pratiques GitLab Flow best practices

1 Toujours utiliser des branches annexes pour développer

2 Effectuer tous les tests pour chaque commit : un push déclenche un
pipeline
3 Effectuer une code review pour chaque merge request
4 Le déploiement est automatisé en fonction des branches, e.g.
production
5 Les tags sont créés par les développeurs, pas par le CI
6 Les releases sont basées sur les tags : une release par tag
7 Éviter le rebase lors de push, pour un suivi clair de l’historique
8 Les développeurs partent de main et ciblent main pour chaque nouvelle
feature
9 Fixer les bugs dans main, puis dans les branches de releases
(cherry-pick)
10 Les messages de commit doivent dire explicitement pourquoi il a été
réalisé, pas seulement comment How to Write a Git Commit Message
8
Workflows Static env rules Dynamic env Améliorations

Plan

1 Les principaux workflows associés à Git

2 Environnements statiques

3 Rules

4 Environnements dynamiques

5 Amélioration du pipeline

9
Workflows Static env rules Dynamic env Améliorations

Environments

GitLab permet de définir des environnements Environments

Ils permettent de spécifier le contexte dans lequel un job
(déploiement/tests) s’exécute et de suivre facilement le résultat des
opérations

Par exemple pour le déploiement, on peut créer plusieurs

environnements :
staging : pré-production
production : version active
créés de façon dynamique et unique pour chaque pipeline, par ex. pour
tester une feature

10
Workflows Static env rules Dynamic env Améliorations

Création d’un environnement statique

Prérequis depuis l’UI de GitLab

11
Workflows Static env rules Dynamic env Améliorations

Conventions pour le nommage des

environnements

12
Workflows Static env rules Dynamic env Améliorations

Utilisation des environnements

13
Workflows Static env rules Dynamic env Améliorations

Visualisation des activités par

environnement

14
Workflows Static env rules Dynamic env Améliorations

Résultats du déploiement

Open permet d’aller directement sur l’URL

Exemple sur [Link] michel/cicd/staging/

15
Workflows Static env rules Dynamic env Améliorations

Plan

1 Les principaux workflows associés à Git

2 Environnements statiques

3 Rules

4 Environnements dynamiques

5 Amélioration du pipeline

16
Workflows Static env rules Dynamic env Améliorations

Mot-clé rules

Il permet de spécifier quand les jobs doivent être exécutés rules

Certains jobs ne doivent pas être exécutés tout le temps

deploy-production doit être exécuté uniquement pour un tag sur la
branche production
deploy-staging uniquement pour main

17
Workflows Static env rules Dynamic env Améliorations

Exemples d’utilisation 1

18
Workflows Static env rules Dynamic env Améliorations

Exemples d’utilisation 2

19
Workflows Static env rules Dynamic env Améliorations

Exemples d’utilisation 3

20
Workflows Static env rules Dynamic env Améliorations

Utilisation classiques de variables

prédéfinies

21
Workflows Static env rules Dynamic env Améliorations

Utilisation classiques de variables

prédéfinies

22
Workflows Static env rules Dynamic env Améliorations

Réutilisation de règles

Il est possible de réutiliser des règles afin de factoriser le code et

d’améliorer sa lisibilité

23
Workflows Static env rules Dynamic env Améliorations

Application sur notre pipeline

On modifie le pipeline pour s’aligner sur un GitLab Flow

(environment)

24
Workflows Static env rules Dynamic env Améliorations

Les jobs sont maintenant filtrés en fonction

du contexte
Les commits sur la branche feature ne déclenchent plus les
déploiements :

25
Workflows Static env rules Dynamic env Améliorations

Création d’une merge request sur main

26
Workflows Static env rules Dynamic env Améliorations

Déclenchement du déploiement sur staging

27
Workflows Static env rules Dynamic env Améliorations

Exécution du pipeline sur la branche main

28
Workflows Static env rules Dynamic env Améliorations

Fin du merge de la merge request ⇒

pré-prod OK

29
Workflows Static env rules Dynamic env Améliorations

Mise en production
Il faut maintenant faire une merge request de main vers production

30
Workflows Static env rules Dynamic env Améliorations

Mais on a une petite erreur dans le job. . .

Le bloc rules ne pouvait pas être déclenché par la création d’un tag
Une fois corrigée dans une branche feature, on recommence les MR,
puis la création d’un tag sur production déclenche bien le pipeline

31
Workflows Static env rules Dynamic env Améliorations

Déclencher un job manuellement

Il est possible de définir qu’un job est uniquement déclenché

manuellement, depuis l’UI de GitLab avec le mot-clé when dans le
bloc rules

Par exemple pour déclencher le déploiement en production au

moment le plus propice, et pas automatiquement en fin de pipeline
(les jobs précédents peuvent être longs)

32
Workflows Static env rules Dynamic env Améliorations

Déclencher un job manuellement

Le déploiement n’est plus automatique :

33
Workflows Static env rules Dynamic env Améliorations

Plan

1 Les principaux workflows associés à Git

2 Environnements statiques

3 Rules

4 Environnements dynamiques

5 Amélioration du pipeline

34
Workflows Static env rules Dynamic env Améliorations

Environnements dynamiques
Il est possible de créer des environnements éphémères
dynamiquement, e.g. pour tester le résultat d’une feature avant un
merge.

On a un squelette proposé dans la section environment de GitLab,

avec le bouton Enable Review Apps :

35
Workflows Static env rules Dynamic env Améliorations

Dans notre pipeline

On ajoute un job deploy-review qui sera déclenché par une
merge request :

36
Workflows Static env rules Dynamic env Améliorations

Création de la merge request

Elle déclenche bien le job, mais il reste quelque chose à faire. . .

37
Workflows Static env rules Dynamic env Améliorations

Ajout d’une règle au job build

Pour que notre job deploy-review fonctionne, il a besoin de
l’artefact produit par le job build : il faut qu’il soit lancé !
⇒ On utilise pour cela la règle when: always

38
Workflows Static env rules Dynamic env Améliorations

Nouveau résultat pour la merge request

Les deux jobs ont bien été lancés

39
Workflows Static env rules Dynamic env Améliorations

Stopper et nettoyer un environnement

dynamique
Une fois la MR validée ou fermée, l’environnement peut être stoppé,
puis effacé. Stop an environment

40
Workflows Static env rules Dynamic env Améliorations

Ajout du job stop_review dans le pipeline

Il consiste dans un simple nettoyage du répertoire correspondant

41
Workflows Static env rules Dynamic env Améliorations

Apparition du job stop_review dans la MR

42
Workflows Static env rules Dynamic env Améliorations

Déclenchement du job stop_review

Il sera déclenché manuellement : par (1) merge/close de la MR ou (2)
un clic sur le job.

Exemple avec un close de la MR

43
Workflows Static env rules Dynamic env Améliorations

Plan

1 Les principaux workflows associés à Git

2 Environnements statiques

3 Rules

4 Environnements dynamiques

5 Amélioration du pipeline

44
Workflows Static env rules Dynamic env Améliorations

Beaucoup de choses sont à améliorer

45
Workflows Static env rules Dynamic env Améliorations

Beaucoup de choses sont à améliorer

Défauts potentiels
1 Il y a trop de lignes semblables
2 Le numéro de version ne devrait pas être toujours identique
3 PRODUCTION_URL / STAGING_URL. . . ne devraient pas être là

Améliorations possibles
1 Solutions pour la factorisation
Utiliser le mot-clé include pour factoriser include

Utiliser un moteur de production comme Gradle

Chercher ou créer une image docker adaptée aux besoins de déploiement
2 Utiliser le contexte pour nommer la version : feature / pré-prod / tags
3 Utiliser des variables définies dans l’UI de GitLab

46
Workflows Static env rules Dynamic env Améliorations

Ce que nous n’avons pas vu

L’utilisation du mot-clé workflow pour définir le comportement du

pipeline en fonction du contexte workflow

47
Workflows Static env rules Dynamic env Améliorations

Conclusion

Nécessité de suivre un workflow

⇒ Le développement doit suivre un workflow
⇒ Le GitLab flow existe en deux versions : environnement et releases
⇒ Les environnements de GitLab permettent de simplifier le suivi du
workflow

Les rules permettent d’exécuter les jobs en fonction du workflow

L’exécution des jobs est en fonction du contexte : feature / pré-prod /
tags
On utilise pour ce la les variables prédéfinies, e.g. CI_COMMI_TAG

48