Commencez par un petit changement demain matin

Vous venez de terminer la lecture sur le CI/CD, les pipelines de livraison, les plateformes internes et l'amélioration continue. Ça a l'air génial. Mais quand vous regardez votre propre équipe, l'écart entre ce que vous avez lu et ce que vous faites réellement semble énorme.

Peut-être que votre processus de build tourne encore sur le portable d'un développeur. Peut-être que votre checklist de release vit dans la tête de quelqu'un. Peut-être que votre environnement de staging a tellement dérivé de la production que déployer ressemble à un pari. Peut-être que vous n'avez même pas encore d'équipe — juste vous et une idée.

Cet écart est normal. Chaque équipe qui livre aujourd'hui de manière fiable a commencé exactement là où vous êtes. Ils ne se sont pas réveillés un matin avec un pipeline parfait qui déploie dix fois par jour sans aucun échec. Ils l'ont construit un petit changement à la fois.

Le vrai point de départ

La plupart des équipes n'ont pas un problème de livraison qui nécessite une refonte grandiose. Elles ont une seule étape dans leur processus actuel qui fait le plus mal. C'est par cette étape que vous commencez.

Regardez comment votre équipe livre un changement aujourd'hui. Du moment où quelqu'un écrit du code au moment où les utilisateurs commencent à utiliser cette nouvelle version, listez chaque étape. Soyez honnête sur ce qui se passe réellement, pas sur ce qui devrait se passer.

  • Qui exécute le build ?
  • Comment savez-vous que le build a réussi ?
  • Que se passe-t-il si un test échoue ?
  • Qui décide qu'il est sûr de déployer ?
  • Comment mettez-vous réellement la nouvelle version en production ?
  • Comment savez-vous que ça fonctionne une fois en place ?

Quelque part dans cette liste se trouve une étape qui dépend d'une seule personne qui se souvient de faire quelque chose. Quelque part se trouve une étape qui ne peut pas être répétée deux fois de la même manière. Quelque part se trouve une étape qui rend les gens nerveux avant chaque release.

Choisissez cette étape. Une seule.

À quoi ressemble un changement

Disons que le build tourne encore sur la machine d'un développeur. Quand ce développeur est en congé, personne ne peut builder. Quand il utilise une version de bibliothèque légèrement différente, le build se comporte différemment. Quand son portable tombe en panne de batterie en plein build, l'équipe attend.

Voici un exemple minimal de ce à quoi ce script pourrait ressembler :

#!/bin/bash
set -e

echo "Clonage du dépôt..."
git clone https://github.com/your-org/your-app.git
cd your-app

echo "Installation des dépendances..."
npm install

echo "Exécution du build..."
npm run build

echo "Build réussi !"

Enregistrez ceci sous build.sh, ajoutez-le à votre dépôt, et exécutez-le depuis un serveur partagé ou un service CI. Maintenant, n'importe qui peut déclencher un build reproductible.

Un changement : déplacer ce build vers un serveur partagé ou un service CI simple. Pas besoin que ce soit sophistiqué. Un simple script qui récupère le code, exécute le build et rapporte le succès ou l'échec est déjà mieux qu'un build sur un portable. Maintenant, n'importe qui peut le déclencher. Maintenant, le résultat est visible par tout le monde. Maintenant, le build est reproductible.

Ou peut-être que le problème est différent. Peut-être que le build est automatisé, mais que le déploiement est toujours une séquence manuelle de commandes SSH que seule une personne connaît. Un changement : écrivez ces commandes dans un script, ajoutez-le au dépôt, et exécutez-le depuis le système CI. Maintenant, le déploiement est documenté, reproductible, et ne dépend plus de la mémoire.

Ou peut-être que le problème est que le staging ne correspond jamais à la production. Un changement : utilisez le même script de déploiement pour les deux environnements. Si le script fonctionne sur le staging mais échoue en production, la différence entre les deux environnements devient visible et corrigeable.

Aucun de ces changements ne nécessite une nouvelle équipe plateforme. Aucun ne nécessite l'achat d'outils coûteux. Aucun ne nécessite que tout le monde soit d'accord sur un workflow complet. Ils nécessitent simplement de choisir une étape douloureuse et de la rendre légèrement meilleure.

L'effet boule de neige

Voici ce qui se passe après ce premier changement : vous le ressentez. La prochaine release est un peu moins stressante. Le prochain build ne nécessite pas un message Slack pour demander qui a le bon portable. Le prochain déploiement ne nécessite pas un partage d'écran pour que quelqu'un puisse regarder les commandes être tapées.

Cette sensation vous donne envie de corriger l'étape suivante. Et la suivante. Pas parce que quelqu'un vous l'a dit, mais parce que vous avez goûté à ce que c'est quand une partie de la livraison devient prévisible. Vous en voulez plus.

C'est ainsi que se produit une véritable adoption du CI/CD. Pas par un plan grandiose. Pas par une migration de plateforme de six mois. Par une série de petites améliorations pratiques qui s'accumulent avec le temps.

Un moyen rapide de trouver votre première étape

Avant de fermer cet article, faites ceci :

  1. Ouvrez le dépôt de votre application.
  2. Notez chaque étape, du commit de code au déploiement en production, telle qu'elle se déroule réellement aujourd'hui.
  3. Marquez l'étape qui fait le plus mal — celle qui échoue le plus souvent, prend le plus de temps, ou dépend du plus de connaissances tacites.
  4. Décidez d'une chose concrète que vous pouvez faire demain pour rendre cette étape légèrement meilleure. Pas parfaite. Meilleure.

C'est votre point de départ.

Ce qu'est réellement le CI/CD

Après tous les chapitres, diagrammes et discussions sur les pipelines, les plateformes et la gouvernance, voici la vérité fondamentale : le CI/CD n'est pas une question d'outils. Ce n'est pas une question d'avoir le diagramme de pipeline parfait. Ce n'est pas une question de copier ce que fait une entreprise de la FAANG.

Le CI/CD est la capacité de votre organisation à continuer de livrer des changements — au code applicatif, aux schémas de base de données et à l'infrastructure — en toute sécurité, et à s'améliorer constamment à chaque livraison.

Cette capacité ne peut pas s'acheter. Elle ne peut pas s'installer. Elle ne peut pas être configurée par un consultant en deux semaines. Elle se construit, un petit changement à la fois, par des personnes qui décident que la release d'aujourd'hui sera un peu moins douloureuse que celle d'hier.

Commencez demain matin. Choisissez une étape. Améliorez-la. Puis recommencez.