1 Hébergement : Utilisation de la CI/CD GitLab

1.1 Objectifs

Cette documentation vous permettra de :

• modifier et de mettre à jours le code source de votre service hébergé par la Mlf
• Appliquer des modification sur le serveur de dévellopement
• Valider les modifications puis les appliquer des modification sur le serveur de stagging (pré-production)
• Valider les modifications puis les appliquer des modification sur le serveur de production
  

1.2 Eléments nécessaires

• Avoir un login et mot de passe pour accéder à l’application GitLab.com
• Les droit de modification du repository de votre service
• Savoir utiliser Git

1.3 CI/CD d'une application

L'objectif est qu'une application déployée dans l'environnement de production (prod) a forcément été déployée dans l'environnement de recette (staging) et dans l'environnement de revue de code (dev) au préalable. Le déploiement continu en recette et en production ne peut se faire qu'après une validation par des personnes autorisées.

Ainsi, les différents environnements étant techniquement identiques et contrôlés, la probabilité qu'une application en production disfonctionne diminue (les erreurs sont interceptées avant le déploiement en production).

Workflow

Le workflow adopté se base sur Gitlab flow, en particulier Gitlab flow avec une branche "production".

La branche "master" fait référence, et son contenu est déployé en continu dans l'environnement de recette (staging). Une branche "prod" intègre le contenu de la branche "master", et est déployée en continu dans l'environnement de production.

L'intégration d'ajouts et modifications du code et/ou de la configuration de déploiement se fait toujours sur une branche "feature" qu'on téléverse sur le dépôt distant. Le contenu de cette branche "feature" est automatiquement déployé dans l'environnement de revue de code (dev), et sera ensuite intégré dans la branche "master".

Les branches "master" et "prod" peuvent être protégées de sorte qu'un développeur ne puissent téléverser ses développements directement sur ces branches et court-circuiter le workflow.

Utilisation

La version à jour et faisant référence d'une application se trouve dans la branche "master" du dépôt. La version contenue dans la branche "prod" déployée en production n'est pas nécessairement à jour : en effet, le contenu de la branche "master" peut être en cours de validation dans l'environnement de recette (staging) et par conséquent être en attente d'intégration dans la branche "prod".

Développement et modification du code et/ou de la configuration de déploiement d'une application

Résumé du flot

• En local :

  • Rappatriemment du dépôt distant ou mise à jour du dépôt local (branche "master")
  • Création d'une branche "feature" dédiée au nouveau développement à partir de la branche "master"
  • Téléversement de la branche "feature" sur le dépôt distant

• Sur Gitlab :

  • Construction automatique de l'image Docker si le répertoire docker a été modifié, et modification automatique de la référence de l'image Docker dans la configuration de déploiement Kubernetes
  • Déploiement automatique du contenu de la branche "feature" dans l'environnement de développement (dev)
  • Ouverture automatique d'une "merge request" pour intégrer le contenu de la branche "feature" dans la branche "master"
  • Revue de code, ajout à la "merge request" ouverte d'éventuels nouveaux commits téléversés sur la branche "feature"
  • Validation de la "merge request" par un mainteneur de la branche "master"
  • Déploiement automatique du contenu de la branche "master" dans l'environnement de recette (staging)
  • Ouverture automatique d'une "merge request pour intégrer le contenu de la branche "master" dans la branche "prod"
  • Revue de code, ajout à la "merge request" ouverte d'éventuels nouveaux commits téléversés sur la branche "master"
  • Validation de la "merge request" par un mainteneur de la branche "prod"
  • Déploiement automatique du contenu de la branche "prod" dans l'environnement de production (prod)

Création d'une branche dédiée au nouveau développement

• Cloner la branche "master" du dépôt de l'application (ou mettre à jour son dépôt local), exemple pour le service mlfmonde :

git clone https://gitlab.com/mlf-services/mlfmonde

ou (dans le dépôt local existant) :

git checkout master
git pull

• Créer une nouvelle branche "feature" à partir de la branche master, dans le dépôt local :

git checkout -b feature # crée et se positionne sur la branche feature

• Réaliser les développements sur cette nouvelle branche "feature", et versionner le travail :

git commit -am "New feature"

Attention au nommage d'une branche "feature"** Certains noms ont une fonction particulière au sein de Gitlab, exemple : "WIP".

Déploiement du nouveau développement dans l'environnement de développement (dev)

Lorsqu'on téléverse la branche "feature" sur le dépôt distant, le déploiement dans l'environnement de développement est automatiquement déclenché. Le déploiement est précédé d'une étape de construction de l'image Docker (build) si le contenu du répertoire docker a été modifié.

• Téléverser les nouveaux commits de la branche "feature" sur le dépôt distant :

git push origin feature

Ouverture automatique d'une "merge request" pour intégrer le contenu de la branche "feature" dans la branche "master"

Lorsque le déploiement dans l'environnement de développement s'est terminé avec succès, une "merge request" est automatiquement créée.

Dès lors on peut procéder à une revue de code, tester l'application déployée dans l'environnement de développement, échanger avec d'autres développeurs au sein de la merge request. On peut continuer à téléverser de nouvelles modifications dans la branche "feature" qui seront ajoutées à la merge request. Une fois les modifications validées on peut marquer la merge request comme prête à être intégrée à la branche "master".

Un mainteneur autorisé peut alors déclencher l'intégration de la branche "feature" dans la branche "master" (merge).

Le déploiement du contenu de la branche "master" est alors automatiquement déployé dans l'environnement de recette (staging).

Ouverture automatique d'une "merge request pour intégrer le contenu de la branche "master" dans la branche "prod"

Lorsque le déploiement dans l'environnement de recette s'est terminé avec succès, une "merge request" est automatiquement créée.

Dès lors on peut procéder à une revue de code, tester l'application déployée dans l'environnement de recette, échanger avec d'autres développeurs au sein de la merge request. On peut continuer à téléverser de nouvelles modifications dans la branche "master" qui seront ajoutées à la merge request. Une fois les modifications validées on peut marquer la merge request comme prête à être intégrée à la branche "prod".

Un mainteneur autorisé peut alors déclencher l'intégration de la branche "master" dans la branche "prod" (merge).

Le déploiement du contenu de la branche "prod" est alors automatiquement déployé dans l'environnement de production (prod).