Comment évaluer la maturité CI/CD de votre organisation sans la compliquer

Vous avez probablement entendu parler des modèles de maturité CI/CD. Peut-être avez-vous même lu sur les cinq niveaux, les quatre dimensions ou les différents frameworks existants. Mais quand il s'agit de déterminer où se situe réellement votre organisation, il est facile de se retrouver bloqué. Faut-il embaucher un consultant ? Organiser un atelier de trois jours ? Construire un tableur avec cinquante métriques ?

Rien de tout cela n'est nécessaire. Une évaluation pratique de la maturité peut être réalisée en quelques heures avec une poignée de questions honnêtes. L'objectif n'est pas de produire un tableau de bord parfait. L'objectif est d'obtenir une image claire des véritables goulots d'étranglement, afin de savoir quoi corriger en priorité.

Commencez par des questions simples, pas par des frameworks complexes

La façon la plus pratique d'évaluer la maturité CI/CD est de poser une ou deux questions pour chaque dimension clé de votre processus de livraison. Répondez à chaque question sur une échelle de 1 à 4, où :

• 1 (Ad Hoc) : Chacun fait comme il veut. Aucun processus standard n'existe.
• 2 (Standardisé) : Un processus défini existe, mais il nécessite encore des étapes manuelles ou de la coordination.
• 3 (En libre-service) : Les équipes peuvent gérer le processus elles-mêmes sans dépendre d'autres équipes ni ouvrir de tickets.
• 4 (Optimisé) : Le processus est mesuré, des données sont collectées et des améliorations sont apportées sur la base de ces données.

Les questions n'ont pas besoin d'être parfaites. Elles doivent simplement pouvoir être répondues honnêtement par les personnes qui font réellement le travail, pas par celles qui ont rédigé la documentation du processus.

Les quatre niveaux forment une progression claire du chaos à une approche pilotée par les données. Voici un résumé visuel :

Livraison : Comment les changements arrivent-ils réellement en production ?

Posez cette question : Est-ce que chaque équipe utilise la même méthode pour envoyer les changements en production ?

Si la réponse est que chaque équipe a son propre script, ses propres étapes manuelles et sa propre façon de décider quand déployer, vous êtes au niveau 1. S'il existe un pipeline standard mais que quelqu'un doit encore approuver ou déclencher manuellement certaines étapes, vous êtes au niveau 2. Si les équipes peuvent déployer par elles-mêmes sans demander d'aide à une autre équipe, vous êtes au niveau 3. Si les équipes suivent la fréquence et la rapidité de leurs déploiements, et utilisent ces données pour améliorer le processus, vous êtes au niveau 4.

Cette dimension est généralement la première que les équipes améliorent, car c'est la plus visible. Mais ne présumez pas qu'un pipeline fonctionnel signifie que vous êtes au niveau 3 ou 4. De nombreuses équipes ont des pipelines qui semblent automatisés mais nécessitent encore des transferts manuels entre équipes.

Plateforme : Les équipes peuvent-elles obtenir ce dont elles ont besoin sans ouvrir de ticket ?

Posez cette question : Les équipes peuvent-elles provisionner l'environnement ou l'infrastructure dont elles ont besoin sans ouvrir de ticket ?

Le niveau 1 signifie que tout est manuel. Quelqu'un doit demander à une personne spécifique de configurer un serveur, et cette personne peut prendre des jours ou des semaines. Le niveau 2 signifie qu'il existe un processus standard, mais qui passe encore par une file d'attente de tickets. Le niveau 3 signifie que les équipes peuvent provisionner leurs propres environnements via une plateforme ou des outils internes. Le niveau 4 signifie que la plateforme est continuellement améliorée en fonction des modèles d'utilisation et des retours des équipes.

Cette dimension est souvent le goulot d'étranglement pour les organisations qui ont de bonnes pipelines applicatives mais qui luttent encore avec une configuration lente des environnements. Si votre pipeline de livraison est rapide mais que le provisionnement prend deux semaines, votre vitesse de livraison effective est toujours de deux semaines.

Gouvernance : Les règles de sécurité et de conformité sont-elles automatisées ?

Posez cette question : Les règles de sécurité et de conformité sont-elles appliquées automatiquement dans le pipeline, ou sont-elles vérifiées manuellement ?

Le niveau 1 signifie qu'il n'y a pas de règles claires, ou que les règles n'existent que dans la tête des gens. Le niveau 2 signifie qu'il existe une liste de contrôle manuelle que quelqu'un doit parcourir avant une mise en production. Le niveau 3 signifie que les règles sont programmées dans le pipeline et bloquent automatiquement les violations. Le niveau 4 signifie que les règles sont révisées périodiquement et ajustées en fonction des risques réels, pas seulement des menaces théoriques.

De nombreuses organisations restent bloquées au niveau 2 parce qu'elles pensent qu'une liste de contrôle manuelle est suffisante. Le problème est que les listes de contrôle manuelles sont ignorées lorsque les délais sont serrés, et qu'elles ne passent pas à l'échelle lorsque l'équipe grandit.

Base de données : Les changements de schéma peuvent-ils être livrés avec les changements applicatifs ?

Posez cette question : Les changements de schéma de base de données peuvent-ils être livrés en même temps que les changements applicatifs sans étapes manuelles supplémentaires ?

Le niveau 1 signifie que les changements de base de données sont effectués manuellement par un DBA. Le niveau 2 signifie qu'il existe une procédure standard, mais qui nécessite encore de la coordination et de la planification. Le niveau 3 signifie que les migrations de base de données sont intégrées dans le pipeline. Le niveau 4 signifie que les changements de base de données sont automatiquement testés et peuvent être annulés en toute sécurité.

C'est souvent la dimension qui surprend les équipes. Elles peuvent avoir un pipeline applicatif mature, mais chaque changement de base de données nécessite encore un processus manuel séparé. Cela crée un goulot d'étranglement caché qui ne devient visible que lorsqu'un changement de schéma provoque un incident en production.

Infrastructure : Les changements de serveurs et de réseau sont-ils effectués via des pipelines ?

Posez cette question : Les changements de configuration d'infrastructure sont-ils effectués via des pipelines, ou en se connectant directement aux serveurs ?

Le niveau 1 signifie que tout est changé manuellement. Le niveau 2 signifie qu'il existe des scripts standard, mais qu'ils sont encore exécutés manuellement. Le niveau 3 signifie que l'infrastructure est gérée comme du code et que les changements passent par des pipelines. Le niveau 4 signifie qu'il existe des mécanismes automatisés de validation et de récupération si un changement de configuration pose problème.

Cette dimension est étroitement liée à la dimension plateforme, mais elle se concentre spécifiquement sur la façon dont l'infrastructure existante est modifiée, pas sur la façon dont les nouveaux environnements sont provisionnés.

Résultats : Savez-vous à quelle fréquence les déploiements échouent ?

Posez cette question : L'équipe sait-elle à quelle fréquence les déploiements échouent ou à quelle vitesse elle se remet des problèmes ?

Le niveau 1 signifie qu'il n'y a pas de données, seulement des suppositions. Le niveau 2 signifie qu'il existe des journaux manuels mais qu'ils ne sont pas analysés régulièrement. Le niveau 3 signifie que les métriques sont collectées automatiquement et visibles par l'équipe. Le niveau 4 signifie que ces métriques sont utilisées pour décider quoi améliorer ensuite.

C'est la dimension qui sépare les équipes qui font simplement semblant de celles qui s'améliorent réellement. Si vous ne mesurez pas votre fréquence de déploiement, votre taux d'échec des changements et votre temps de récupération, vous ne pouvez pas savoir si vos changements améliorent ou détériorent les choses.

Une liste de contrôle pratique pour l'évaluation

Voici une liste de contrôle simple que vous pouvez utiliser avec votre équipe. Répondez à chaque question honnêtement, pas en fonction de ce que vous souhaiteriez qui soit vrai.

Que faire des résultats

L'évaluation vous donne un profil, pas une note. Vous n'avez pas besoin d'atteindre le niveau 4 dans chaque dimension. Ce dont vous avez besoin, c'est de trouver la dimension qui retient tout le reste.

Si votre livraison est au niveau 3 mais que votre base de données est au niveau 1, votre véritable goulot d'étranglement est les changements de base de données. Améliorer davantage le pipeline n'aidera pas si chaque changement de base de données nécessite encore un processus manuel de DBA. Concentrez-vous sur la dimension la moins bien notée qui affecte directement votre capacité à livrer des changements de manière sûre et rapide.

L'étape suivante consiste à élaborer une feuille de route basée sur ces goulots d'étranglement. Mais avant cela, réalisez l'évaluation avec votre équipe. La conversation elle-même est souvent plus précieuse que les scores.