Votre premier pas CI/CD : que faire demain matin

Vous avez lu sur les niveaux de maturité CI/CD. Vous comprenez la théorie. Maintenant, vous êtes assis à votre bureau en vous demandant quoi faire concrètement lundi matin. La réponse n'est pas d'installer un outil ou de reconcevoir l'intégralité de votre pipeline. La réponse est bien plus simple.

Commencez avec une feuille de papier et un stylo. Dessinez comment un changement passe du poste du développeur à la production. Qui écrit le code ? Où va-t-il ensuite ? Qui le vérifie ? Comment est-il déployé ? Que se passe-t-il après le déploiement ? Ne vous inquiétez pas si le processus est en grande partie manuel. L'objectif n'est pas d'avoir un diagramme parfait. L'objectif est que toute l'équipe voie la même image de la façon dont le logiciel atteint réellement les utilisateurs.

Cet exercice simple révèle souvent des surprises. Le développeur pense que le processus prend dix minutes. L'exploitant sait qu'il prend deux heures à cause des vérifications manuelles. Le responsable QA se souvient que quelqu'un oublie toujours de mettre à jour le fichier de configuration. Dessiner le flux rend ces écarts visibles.

Trouvez le point douloureux

Une fois le flux sur papier, cherchez l'étape qui cause le plus de problèmes. Cela pourrait être la build que quelqu'un exécute manuellement sur son poste. Cela pourrait être la migration de base de données que tout le monde repousse par peur de casser quelque chose. Cela pourrait être la vérification manuelle pour confirmer que la nouvelle version fonctionne correctement.

Voici un exemple de ce à quoi ce flux pourrait ressembler pour une équipe typique :

Choisissez le changement le plus simple que vous pouvez automatiser. N'essayez pas d'automatiser l'ensemble du pipeline de déploiement dès le premier jour. Choisissez un type de changement qui se produit fréquemment et qui présente un faible risque. Peut-être s'agit-il du processus de build pour un petit outil interne. Peut-être s'agit-il du déploiement d'un service non critique. L'objectif est de créer une petite victoire qui renforce la confiance.

Rédigez une checklist de release

Reprenez cette feuille de papier. Écrivez trois à cinq lignes qui répondent à ces questions :

• Que faut-il vérifier avant qu'une nouvelle version ne soit mise en production ?
• Comment le vérifiez-vous ?
• Que faites-vous si quelque chose tourne mal ?

Gardez-la courte. Une bonne checklist pour une petite équipe pourrait ressembler à ceci :

• La nouvelle version a-t-elle passé les tests de base ?
• La base de données est-elle prête pour le changement ?
• Avons-nous communiqué le changement aux autres équipes ?
• Savons-nous comment revenir en arrière si quelque chose casse ?

Écrivez-la sur un tableau blanc, dans un document partagé ou dans le chat de votre équipe. Le format n'a pas d'importance. Ce qui compte, c'est l'habitude de la vérifier avant chaque release. Avec le temps, ces vérifications manuelles deviennent des candidates à l'automatisation. Mais demain matin, commencez simplement par écrire ce qui doit être vérifié.

Désignez une personne responsable par release

Choisissez une personne responsable de chaque release. Cela ne signifie pas qu'elle fait tout le travail. Cela signifie qu'elle s'assure que la checklist est suivie, qu'elle sait quand la nouvelle version est mise en production et qu'elle est prête à réagir si quelque chose tourne mal. Faites tourner ce rôle chaque semaine ou chaque release. L'objectif est simple : aucune release n'a lieu sans que quelqu'un en soit pleinement responsable.

Ce rôle ne concerne pas l'autorité. Il concerne la visibilité. Lorsqu'une personne possède la release, il n'y a pas de confusion sur qui surveille le déploiement. Il n'y a pas de supposition que quelqu'un d'autre attrapera le problème. Il y a un point de contact unique en cas de questions.

Pourquoi ces petites étapes comptent

Ces étapes semblent petites. Dessiner un flux, écrire une checklist, désigner un responsable de release. Elles ne ressemblent pas aux transformations CI/CD dont vous lisez dans les articles de blog. Mais elles sont le fondement qui rend tout le reste possible.

Lorsque vous dessinez le flux, vous voyez où l'automatisation aura le plus d'impact. Lorsque vous écrivez une checklist, vous définissez ce que l'automatisation doit vérifier. Lorsque vous désignez un responsable de release, vous créez une responsabilité que l'automatisation ne peut pas remplacer.

Ces étapes créent également l'habitude de penser à la livraison comme à un processus. De nombreuses équipes se précipitent directement sur les outils. Elles installent Jenkins ou GitHub Actions et commencent à construire des pipelines sans comprendre leur flux actuel. Le résultat est une automatisation qui reflète des processus défaillants. Les builds s'exécutent plus vite, mais les releases échouent toujours parce que personne n'a vérifié la migration de base de données.

Commencer par le flux et la checklist signifie que vous automatisez les bonnes choses. Vous automatisez les vérifications qui comptent, pas les vérifications qui sont faciles à scripter.

Et ensuite

Après quelques releases avec ce processus simple, des schémas émergeront. Vous remarquerez quelles vérifications sont toujours les mêmes. Vous remarquerez quelles étapes prennent le plus de temps. Vous remarquerez quelles parties du flux causent le plus d'erreurs. Ces schémas vous indiquent quoi automatiser ensuite.

Peut-être que l'étape de build est toujours la même, alors vous écrivez un script pour l'exécuter sur un serveur partagé. Peut-être que la vérification de migration de base de données est toujours oubliée, alors vous l'ajoutez à votre script de déploiement. Peut-être que la procédure de rollback n'est jamais testée, alors vous planifiez un exercice pratique.

C'est ainsi que le CI/CD se développe organiquement. Cela commence par la compréhension de votre processus actuel, pas par l'installation d'un outil. Cela commence par une checklist, pas par une configuration de pipeline. Cela commence par une personne responsable, pas par une équipe d'ingénieurs plateforme.

L'essentiel à retenir

Demain matin, faites trois choses :

1. Dessinez votre flux de livraison actuel sur papier avec votre équipe.
2. Rédigez une checklist de release de cinq lignes basée sur ce que vous voyez.
3. Désignez une personne pour posséder la prochaine release.

Voilà votre premier pas. Cela ne coûte rien. Cela prend une heure. Et cela vous donne une fondation qu'aucun outil ne peut remplacer.