Comprendre le CI/CD : c'est quoi et pourquoi ça change tout

Le déploiement manuel

Avant de comprendre ce qu'est le CI/CD, parlons du problème qu'il résout.

Sans automatisation, déployer une application ressemble à ça :

1. Tu écris du code en local
2. Tu le pousses sur ton dépôt Git
3. Tu te connectes manuellement au serveur en SSH
4. Tu tires le nouveau code avec git pull
5. Tu installes les dépendances
6. Tu relances l'application
7. Tu vérifies que tout fonctionne

Le problème ? Cette procédure est répétitive, source d'erreurs humaines, et ne passe pas à l'échelle. Si tu as une équipe de 5 développeurs qui poussent du code plusieurs fois par jour, qui s'occupe des déploiements ? Et si quelqu'un oublie une étape ?

Pire encore, aucune vérification automatique ne t'empêche de déployer du code cassé en production.

CI/CD, la définition simple

CI/CD signifie Intégration Continue / Déploiement Continu.

• CI (Intégration Continue) : à chaque fois qu'un développeur pousse du code, des vérifications automatiques s'exécutent pour s'assurer que le code est correct.
• CD (Déploiement Continu) : si toutes les vérifications passent, le code est automatiquement déployé en production sans intervention humaine.

En résumé : tu pousses du code, le pipeline fait le reste.

Les 3 étapes d'un pipeline CI/CD

Un pipeline CI/CD est une suite d'étapes qui s'exécutent automatiquement dans un ordre précis. Chaque étape doit réussir pour que la suivante démarre.

1. Test

C'est la première ligne de défense. Avant de faire quoi que ce soit, on vérifie que le code ne contient pas d'erreurs. Selon le projet, ça peut être une vérification de syntaxe, des tests unitaires, ou une analyse de qualité du code avec un linter.

Si cette étape échoue, le pipeline s'arrête. Le code cassé ne passe jamais en production.

2. Build

Une fois le code validé, on le transforme en quelque chose de déployable. Dans notre cas, on construit une image Docker, un paquet autonome qui contient l'application et tout ce dont elle a besoin pour fonctionner.

Cette image est ensuite stockée dans un registry. Elle peut être déployée sur n'importe quel serveur qui fait tourner Docker.

3. Deploy

C'est la dernière étape. Le serveur de production télécharge la nouvelle image Docker et remplace l'ancienne version de l'application par la nouvelle. L'opération prend quelques secondes et l'utilisateur ne voit rien.

Le GitLab Runner

GitLab sait quoi faire grâce au fichier .gitlab-ci.yml que tu places à la racine de ton projet. Mais GitLab ne peut pas exécuter les jobs lui-même, il a besoin d'un agent externe. C'est le rôle du GitLab Runner.

Le Runner est un logiciel que tu installes sur un serveur. Il écoute GitLab en permanence et exécute les jobs dès qu'un développeur pousse du code.

Concrètement, voici ce qui se passe à chaque push :

1. Tu pousses du code sur GitLab
2. GitLab lit ton fichier .gitlab-ci.yml et crée un pipeline
3. GitLab envoie les jobs au Runner
4. Le Runner exécute chaque job dans un container Docker isolé
5. Le Runner renvoie les résultats à GitLab
6. GitLab affiche le résultat dans l'interface

Sans Runner, GitLab sait quoi faire mais n'a personne pour le faire.

Pourquoi GitLab ?

Il existe d'autres outils CI/CD comme GitHub Actions, Jenkins ou CircleCI. GitLab a plusieurs avantages :

• Tout est intégré : le dépôt Git, le CI/CD, le Container Registry, la gestion des secrets, tout est dans la même plateforme
• Gratuit : le plan gratuit inclut un Runner partagé avec 400 minutes par mois, suffisant pour débuter
• Flexible : tu peux installer ton propre Runner sur ton serveur pour avoir des minutes illimitées
• Simple : le fichier .gitlab-ci.yml est facile à comprendre et à maintenir

Ce que tu vas apprendre dans l'article suivant

Dans le prochain article, on passe à la pratique. Tu vas apprendre à installer et configurer un GitLab Runner sur ton propre serveur, écrire un fichier .gitlab-ci.yml complet, gérer les secrets de façon sécurisée, et déployer automatiquement ton application à chaque push sur la branche main.

Conclusion

Le CI/CD n'est pas réservé aux grandes équipes ou aux entreprises. Même seul sur un projet personnel, automatiser tes déploiements te fait gagner du temps, évite les erreurs humaines et te donne la confiance de pousser du code sans craindre de casser la production.

Dans le prochain article, on met les mains dans le cambouis.