Aller au contenu principal

Documentation de la pipeline CI/CD

Cette documentation décrit l'organisation et le fonctionnement de la pipeline CI/CD de votre repository d'application.

👉 Pour le contexte global, voir :

🔧 Configuration de la pipeline​

Fichier .gitlab-ci.yml​

La configuration de votre pipeline CI/CD se trouve dans le fichier .gitlab-ci.yml à la racine de votre repository.

attention

⚠️ Important : Ne modifiez pas ce fichier ! Il est configuré pour fonctionner avec l'infrastructure DevOps du projet.

Implémentation centralisée​

Ce fichier .gitlab-ci.yml fait appel à l'implémentation de la pipeline qui est stockée dans un repository privé géré par l'équipe DevOps. Cette approche centralisée permet :

  • Une mise à jour simplifiée de la pipeline pour tous les projets
  • Une maintenance centralisée des configurations
  • Une cohérence entre tous les repositories d'applications

🚀 Stages et Jobs de la pipeline​

Vous pouvez suivre l'exécution de la pipeline dans GitLab via Build > Pipelines après vos commits, merge requests ou déploiements.

🏷️ generate-tag​

  • Objectif : Génère automatiquement le tag qui sera utilisé pour les images Docker du frontend et du backend
  • Déclenchement : À chaque exécution de pipeline

✨ prettier-check​

  • Objectif : Formate automatiquement votre code selon les standards du projet
  • Déclenchement : À chaque push
  • Action : Application automatique du formatage Prettier

🧪 test-integration​

  • Objectif : Exécute les tests d'intégration de votre application
  • Comportement : Si les tests échouent, le job échoue et bloque la pipeline
  • Impact : Empêche le déploiement en cas de régression

🗄️ test-migration​

  • Objectif : Vérifie la sécurité des migrations de base de données
  • Règles de sécurité : Le job échouera si les migrations contiennent des actions destructives :
    • DROP TABLE
    • DROP COLUMN
    • DELETE FROM
    • TRUNCATE
    • DROP INDEX
    • DROP CONSTRAINT
  • Protection : Évite la suppression accidentelle de données en production

🐳 Jobs de build​

  • Objectif : Construisent et publient les images Docker de votre application
  • Artefacts produits :
    • Image Docker du frontend
    • Image Docker du backend
  • Stockage : Images disponibles dans Deploy > Container Registry de votre repository GitLab

📚 deploy-doc​

  • Objectif : Déploie la documentation mise à jour
  • Déclenchement : Push ou merge request sur la branche dev
  • Source : Contenu du dossier docs/ de votre repository

🚀 Jobs de deploy​

  • Objectif : Déclenchent les déploiements de votre application dans un des environnements (dev, pre-prod, prod)
  • Fonctionnement :
    • Ces jobs appellent une pipeline externe gérée par l'équipe DevOps et Socle
    • L'image est récupérée et les variables d'environnement sont appliquées
    • Après quelques minutes, votre application devrait être accessible dans l'environnement ciblé, vous pouvez vérifier grâce aux hash du commit affiché dans l'interface
  • Environnements : Déploiement selon les branches (dev, pre-prod, main)

🔍 Suivi de la pipeline​

Dans GitLab​

  • Build > Pipelines : Vue d'ensemble des exécutions
  • Deploy > Container Registry : Images Docker générées
  • Logs détaillés : Cliquez sur chaque job pour voir les détails d'exécution

En cas d'échec​

  • Les jobs bloquants (tests, migrations) empêchent la progression
  • Consultez les logs pour identifier la cause
  • Corrigez le problème avant de relancer
  • Si vous ne parvenez pas à corriger, contactez les DevOps

🪲 Bugs connus​

Runner Gitlab​

Si votre job échoue et que GitLab vous indique l’erreur suivante : Erreur Gitlab runner -> Relancez simplement votre job. Cette erreur est due à une surcharge des runners utilisés pour exécuter vos jobs. Cela peut arriver si un trop grand nombre de jobs nécessitant trop de ressources sont lancés en même temps.

🚀 Pour aller plus loin​