Aller au contenu principal

Tutoriel de release – Déploiement en production

Ce document décrit les étapes à suivre pour effectuer une release et déployer une version en production via GitLab.

Les releases ont pour objectif de livrer en production une nouvelle version stable de votre application. Nous vous recommandons d’en effectuer une par sprint, idéalement à la fin de celui-ci, lorsque tous vos tickets sont complétés et que vous êtes prêts pour la démonstration de JC. ⚠️ Évitez d’attendre la veille de la démonstration : un imprévu pendant la release peut retarder la mise en production.

Pré-requis​

Avant de lancer une release, assurez-vous :

  • d’avoir la dernière version du template fourni par l’équipe DevOps : vérifiez sur la page d’accueil de votre dépôt GitLab qu’aucune mise à jour du fork n’est proposée ;
  • que la version de l’application à déployer est à jour sur l’environnement de développement et fonctionne correctement ;
  • d’avoir réalisé un déploiement en pré-production de cette nouvelle version, que celui-ci se soit bien déroulé et que l’application soit accessible à l’adresse : https://[APP_NAME].preprod.ubsi.fr.
  • d’avoir vérifié que toutes les pipelines de déploiement dans l’environnement actuel se sont terminées avec succès avant de passer à l’environnement suivant (vous pouvez contrôler cela dans l’onglet Build > Pipelines de GitLab).

Étapes pour créer une release​

1. Accéder à la page de release​

Dans l'interface web GitLab du projet :

  • Aller dans Deploy > Releases
  • Cliquer sur Create new release

ℹ️ Note : Dans cet onglet Releases, vous retrouverez un historique de toutes vos releases. Pour le moment, il n'y en a qu'une sur votre repo : la release 0.0.0 effectuée par l'équipe DevOps en amont du début du développement de l'application.

2. Configurer et créer la release​

Interface GitLab - Configuration du tag

  • Tag name : saisir un nouveau tag au format X.Y.Z-release (voir conventions de versionnage)
    • Exemple : 1.3.0-release
  • Create from : sélectionner la branche pre-prod

⚠️ Le suffixe -release est OBLIGATOIRE pour déclencher le déploiement en production.

Interface GitLab - Création du tag

  • Titre de la release : utiliser le format suivant :
[TEAM NAME] [DATE] Déploiement en production de la version X.Y.Z

Exemple pour l'équipe E-COMMERCE :

[E-COMMERCE] [2025-08-03] Déploiement en production de la version 1.3.0

  • Milestone : sélectionner le milestone que vous venez de finir

  • Release notes : exemple de release notes (libre à vous d'y mettre le contenu que vous souhaitez) :

## 🚀 Nouvelles fonctionnalités
- [Feature] Ajout du système de notifications push
- [Feature] Nouveau tableau de bord utilisateur

## 🐛 Corrections de bugs
- [Fix] Correction du calcul des frais de livraison
- [Fix] Résolution du problème de synchronisation panier

## ⚠️ Limitations connues
- Temps de réponse plus élevé sur les gros catalogues (correction prévue v1.3.1)
  • Release date : vérifier que la date est correcte
  • Cliquer sur Create release pour finaliser

Le déploiement en production se lance automatiquement. Vous pouvez observer l’exécution de la pipeline et vérifier que tous les jobs se terminent avec succès.

Si l’un d’eux échoue, assurez-vous que le job 'deploy-prod' ne s’est pas lancé :

  • S’il s’est lancé, contactez l’équipe DevOps.
  • S’il ne s’est pas lancé, supprimez le tag créé dans l’onglet Code > Tags de GitLab : cela supprimera la release échouée.
  • Reprenez ensuite chaque étape de cette documentation attentivement et relancez le processus.
  • En cas d’un nouvel échec, contactez l’équipe DevOps.

Si la pipeline réussit, vous accéderez à la nouvelle version de votre application à l’adresse : https://[APP_NAME].ubsi.fr

🎉 Félicitations, vous venez de livrer une nouvelle version fonctionnelle de votre application !

Conventions de versionnage​

Les versions suivent le format X.Y.Z (Semantic Versioning) :

  • X (majeur) : changement incompatible, breaking change
  • Y (mineur) : nouvelle fonctionnalité compatible
  • Z (patch) : correction de bug ou amélioration mineure

Exemples de versionnage​

  • 1.0.0 → 1.0.1 (correction de bug)
  • 1.0.1 → 1.1.0 (nouvelle fonctionnalité)
  • 1.1.0 → 2.0.0 (breaking change)

Format des tags​

Format obligatoire :

X.Y.Z-release

Exemples valides :

  • 1.0.0-release
  • 1.2.3-release
  • 2.0.0-release

🚀 En résumé​

  1. GitLab → Deploy → Releases → Create new release
  2. Tag : X.Y.Z-release depuis pre-prod
  3. Titre : [TEAM NAME] [Date] Version X.Y.Z
  4. Milestone : sélectionner le milestone terminé
  5. Create release

C'est terminé ! La production est mise à jour automatiquement.

info

⚠️ Important - Pipeline de déploiement : À chaque déploiement, une pipeline automatique s'exécute pour vérifier plusieurs éléments critiques:

  • Migrations de base de données : vérification que les migrations DB se sont bien passées et ne risquent pas d'endommager la base de données de l'environnement suivant (pre-prod après dev, prod après pre-prod)
  • Santé de l'environnement précédent : vérification que l'environnement précédent est toujours opérationnel (dev up avant déploiement en pre-prod, pre-prod up avant déploiement en prod)

Si l'une de ces vérifications échoue, le déploiement sera automatiquement bloqué. Pour plus de détails, consultez la documentation de la pipeline.

👉 Voir aussi :