Chapitre 5.3.4
CI/CD

Comment le code passe-t-il du poste du développeur jusqu'aux utilisateurs ?

Historiquement, et jusqu'au début des années 2010, quelqu'un copiait manuellement les fichiers sur le serveur de production, lançait des commandes, vérifiait que tout fonctionne... C'était un processus manuel, stressant et risqué.

L'intégration continue et le déploiement continu (CI/CD) ont automatisé tout ça. Ils concilient les méthodes d'organisation des branches Git et le déploiement sur les différents environnements pour assurer la sécurité et la cohérence du flux de livraison des fonctionnalités.

Intégration continue

L'intégration continue (Continuous Integration, CI), c'est l'idée que chaque modification de code est automatiquement vérifiée dès qu'elle est poussée sur le dépôt Git partagé.

Dès qu'un développeur envoie son code sur GitHub ou GitLab, une machine appelée "runner" ou "agent" se déclenche automatiquement et exécute une série de vérifications :

1. Compilation : est-ce que le code est syntaxiquement correct ?
2. Tests automatiques : est-ce que rien n'est cassé ?
3. Analyse de qualité : est-ce que le code respecte les conventions de l'équipe ? Nommage, architecture, couverture de tests...
4. Analyse de sécurité : est-ce qu'il y a des failles connues dans les dépendances ?

Si une étape échoue, le développeur est prévenu. Chacun peut adopter sa propre stratégie : envoi d'un email, blocage de la fusion depuis Github, simple affichage d'alerte...

Livraison et déploiement continu (Continuous Delivery)

La livraison continue (Continuous Delivery, CD), c'est le fait de déployer automatiquement le code sur différents environnements.

Par exemple :

• Déployer en préproduction dès la création d'une branche "release".
• Sur un UAT particulier dès que du code est ajouté sur une branche suivant la convention de nommage "projet_{X}".

La livraison continue produit un résultat prêt à partir en production, mais une action manuelle est nécessaire pour déclencher la suite du process.

Les entreprises avec des pratiques de code solides, une CI/CD de qualité, des tests automatisés robustes et de bons outils de surveillance, peuvent se permettre de déployer en production chaque petite fonctionnalité en temps réel. Amazon, par exemple, déploie en production toutes les 11 secondes en moyenne.

Elles mettent en place du déploiement continue (Continuous Deployment). Ici, la fusion du code sur master déclenche automatiquement la mise en production dès que les contrôles sont en succès. Chaque modification est petite, ciblée, et si un problème survient, il est automatiquement détecté par les outils.

Rollback

Même avec une CI/CD solide, une erreur peut toujours se produire. Un comportement utilisateur inattendu, une dépendance instable... Il faut alors pouvoir revenir rapidement à une version précédente fonctionnelle.

C'est ce qu'on appelle un rollback : le fait de redéployer une version antérieure du code pour rétablir un état stable. Chaque version déployée doit donc être identifiable, versionnée et redeployable immédiatement.

Quelques stratégies en cas de problème :

• Rollback manuel : un humain redéploie la version précédente.
• Rollback automatisé : le système détecte une anomalie et revient automatiquement en arrière.
• Feature flags : on désactive une fonctionnalité sans redéployer, grâce à une configuration externe au code.
• Blue/Green deployment : deux environnements de production existent en parallèle, chacun avec une version différente. Le trafic est redirigé sur l'architecture faisant tourner l'ancienne version si quelque chose est détecté sur la nouvelle version.
• Canary release : on limite l'impact en exposant une nouvelle version à un faible pourcentage d'utilisateurs.

Le rollback peut s'avérer très complexe quand la mise en production incluait des changements de base de données, des modifications de formats stockés dans des caches, la synchronisation avec un partenaire ou un autre système interne... Pour chaque bout de code mis en production, les développeurs planifient une stratégie de retour en arrière. Généralement, on se sert des techniques de gestion de versions que nous aborderons dans le prochain chapitre.

En règle générale, plus les déploiements sont fréquents, plus les modifications sont petites.
Et plus les modifications sont petites, plus le rollback est simple.

La capacité à revenir en arrière rapidement est un élément central d'une organisation qui déploie souvent. Ce n'est pas un aveu d'échec, c'est une stratégie de maîtrise du risque.

Le pipeline

L'ensemble des étapes automatisées (compilation, tests, déploiement) forme ce qu'on appelle un pipeline. C'est une chaîne de montage logicielle.

Un pipeline typique ressemble à quelque chose comme :

1. Analyse de la Pull Request
2. Installation des bibliothèques
3. Analyse de sécurité
4. Tests unitaires
5. Tests d'intégration
6. Déploiement en préproduction
7. Validation manuelle
8. Test de montée en charge
9. Déploiement en production

Chaque étape est un point de contrôle. Si une étape échoue, le pipeline s'arrête et le code ne progresse pas. C'est un filet de sécurité qui empêche les erreurs d'atteindre les utilisateurs.

Les outils les plus utilisés pour construire ces pipelines sont GitHub Actions, GitLab CI, Jenkins et CircleCI. Ils sont intégrés directement dans les plateformes de gestion de code, ce qui rend la mise en place assez naturelle.

L'impact sur les équipes

La CI/CD a profondément changé la façon de travailler des équipes :

• Moins de stress : les mises en production sont moins des événements à risque. Elles deviennent routinières et prévisibles.
• Plus de confiance : quand le pipeline est vert, tout le monde sait que le code a été vérifié automatiquement.
• Des livraisons plus fréquentes : au lieu de livrer une grosse version tous les mois, on livre de petites modifications chaque jour.

La CI/CD est aujourd'hui considérée comme une pratique essentielle. Un projet sans pipeline CI/CD, c'est un peu comme une usine sans contrôle qualité : ça fonctionne, mais pour combien de temps ?