Avant de construire un pipeline, vous avez besoin de ces trois choses

Il y a quelques mois, j'étais dans une réunion de planification où une équipe était enthousiaste à propos de son nouveau pipeline CI/CD. Ils avaient passé des semaines à configurer des outils, écrire des fichiers YAML et mettre en place des tests automatisés. Le pipeline était au vert. Les déploiements étaient rapides. Tout le monde se sentait bien.

Puis quelqu'un a demandé : « Qu'essayons-nous réellement d'accomplir avec tout cela ? »

Le silence s'est installé dans la salle. Certains parlaient de livraisons plus rapides. D'autres mentionnaient moins de bugs. Quelques-uns disaient vouloir réduire le travail manuel. Personne n'avait la même réponse. Le pipeline fonctionnait, mais personne ne pouvait expliquer à quoi ressemblait le succès.

Cette équipe avait construit un pipeline sans répondre d'abord à trois questions fondamentales. Et c'est pourquoi leur pipeline, aussi bien conçu soit-il, ne résolvait pas les bons problèmes.

Commencez par le pourquoi : le résultat métier

Chaque effort d'ingénierie a besoin d'une destination. Sans cela, les équipes dérivent. Elles construisent des fonctionnalités que personne n'a demandées. Elles optimisent des processus qui n'ont pas d'importance. Elles mesurent des choses qui ont belle apparence sur les tableaux de bord mais n'ont aucun lien avec les résultats réels.

Un résultat métier n'est pas une liste de fonctionnalités. Ce n'est pas un cahier des charges techniques. C'est un résultat mesurable qui compte pour les personnes qui utilisent votre produit ou qui le paient.

Exemples de résultats métier :

  • Les nouveaux utilisateurs peuvent finaliser leur inscription en moins de deux minutes.
  • Le temps de génération des rapports mensuels passe de trois jours à une heure.
  • Les tickets de support client liés aux problèmes de connexion diminuent de 40 pour cent.

Remarquez ce que ces exemples ne sont pas. Ils ne disent pas « nous allons implémenter OAuth » ou « nous allons migrer vers Kubernetes ». Ce sont des solutions techniques. Un résultat métier décrit l'effet que vous voulez créer, pas comment vous comptez le créer.

Lorsque les équipes ont un résultat métier clair, les décisions deviennent plus faciles. Doit-on ajouter cette nouvelle fonctionnalité ou corriger le problème de stabilité ? Regardez le résultat métier. Quelle option fait bouger l'aiguille ? Sans cette ancre, chaque équipe définit le succès différemment. L'équipe frontend mesure le temps de chargement des pages. L'équipe backend mesure la latence des API. L'équipe plateforme mesure la disponibilité. Tout le monde est occupé. Personne n'est aligné.

Cartographiez le flux : la chaîne de valeur

Une fois que vous savez ce que vous voulez accomplir, vous devez comprendre comment le travail circule réellement de l'idée à l'utilisateur. C'est votre chaîne de valeur.

Une chaîne de valeur n'est pas la même chose qu'un pipeline CI/CD. Un pipeline est une implémentation technique. Une chaîne de valeur est le parcours complet : depuis le moment où quelqu'un écrit du code, en passant par les tests, la construction, la revue, l'approbation, le déploiement, la vérification, jusqu'à atteindre l'utilisateur qui en tire de la valeur.

La chaîne de valeur inclut également des éléments que les pipelines ignorent souvent :

  • Les processus de revue de code et d'approbation
  • Les étapes de vérification manuelle
  • Les temps d'attente entre les transferts
  • Les boucles de rétroaction en cas de problème
  • Les surcoûts de communication entre les équipes

Cartographier une chaîne de valeur signifie lister chaque étape qui se produit entre « le code est écrit » et « l'utilisateur obtient de la valeur ». Pour chaque étape, posez trois questions :

  1. Que produit cette étape ?
  2. Qui est impliqué ?
  3. Comment savons-nous si elle ajoute de la valeur ?

De nombreuses équipes découvrent que la moitié des étapes de leur chaîne de valeur ne contribuent pas directement au résultat métier. Elles existent parce que « c'est comme ça qu'on a toujours fait ». Une réunion d'approbation hebdomadaire à laquelle personne n'assiste. Une validation manuelle qui est systématiquement approuvée. Une phase de test qui exécute les mêmes vérifications que le pipeline automatisé.

Ces étapes sont du gaspillage. Elles ralentissent la livraison sans améliorer la qualité. Lorsque vous les voyez dans votre chaîne de valeur, vous avez deux choix : les supprimer ou les reconcevoir.

Attribuez la propriété : l'équipe

Vous avez une destination et une carte. Maintenant, vous avez besoin de personnes pour avancer.

Le composant équipe concerne qui possède quelle partie de la chaîne de valeur. Il ne s'agit pas d'organigrammes ou de lignes hiérarchiques. Il s'agit de clarté des responsabilités.

Chaque étape de la chaîne de valeur doit avoir un propriétaire clair. Ce propriétaire sait :

  • De quoi il est responsable
  • Comment sa production est liée au résultat métier
  • Qui dépend de son travail
  • De quoi il a besoin des autres pour faire son travail

Lorsque la responsabilité n'est pas claire, des lacunes apparaissent. L'équipe applicative pense que le déploiement est le travail de l'équipe infrastructure. L'équipe infrastructure pense que le déploiement est le travail de l'équipe applicative. Les nouvelles versions restent en staging pendant des semaines parce que personne ne prend la responsabilité du push final en production.

Différentes organisations structurent les équipes différemment. Certaines utilisent des équipes fonctionnelles qui incluent développeurs, QA et ops dans un même groupe. D'autres ont une équipe plateforme séparée qui fournit l'infrastructure et les outils aux équipes applicatives. Aucune approche n'est intrinsèquement meilleure. Ce qui compte, c'est que chaque partie de la chaîne de valeur ait un propriétaire nommé, et que ce propriétaire comprenne comment son travail contribue au résultat métier.

Comment ces trois éléments se connectent

Le résultat métier, la chaîne de valeur et l'équipe ne sont pas indépendants. Ils forment un système.

Le diagramme ci-dessous montre comment ces trois éléments forment un système qui guide la conception du pipeline.

flowchart TD BO[Résultat métier] --> VS[Chaîne de valeur] VS --> TO[Propriété d'équipe] TO --> PD[Conception du pipeline] PD -.->|retour| BO PD -.->|retour| VS PD -.->|retour| TO
  • Le résultat métier donne la direction. Sans lui, les équipes prennent des décisions basées sur des préférences personnelles ou une optimisation locale.
  • La chaîne de valeur donne le chemin. Sans elle, les équipes ne peuvent pas voir où se cachent les retards et le gaspillage.
  • L'équipe donne la capacité. Sans une propriété claire, le travail passe entre les mailles du filet.

Lorsque l'un de ces éléments manque, les autres peinent. Une équipe qui ne connaît pas le résultat métier optimisera pour les mauvaises choses. Une chaîne de valeur non cartographiée cachera les goulots d'étranglement. Une équipe sans responsabilité claire créera des retards de transfert et des jeux de reproches.

Ce n'est qu'après avoir clarifié ces trois composants que vous devriez commencer à parler de plateformes, de pipelines et de stratégies de déploiement. Les outils et l'automatisation accélèrent un processus. Mais si le processus lui-même est mal aligné, l'accélération ne fait qu'empirer les choses plus rapidement.

Une vérification rapide avant de construire

Avant de concevoir votre prochain pipeline ou de choisir votre prochain outil de déploiement, parcourez cette courte liste de vérification avec votre équipe :

  • Tout le monde peut-il nommer le ou les deux principaux résultats métier sur lesquels votre équipe travaille ?
  • Avez-vous cartographié la chaîne de valeur complète, du code à l'utilisateur, y compris les étapes manuelles et les temps d'attente ?
  • Chaque étape de cette chaîne de valeur a-t-elle un propriétaire clair ?
  • Chaque propriétaire peut-il expliquer comment son travail se connecte au résultat métier ?

Si une réponse est non, corrigez cela d'abord. Le pipeline peut attendre.

L'essentiel à retenir

Un pipeline est un outil. Une stratégie de déploiement est une technique. Ni l'un ni l'autre ne remplace le besoin de clarté sur ce que vous essayez d'accomplir, comment le travail circule pour y parvenir, et qui est responsable de chaque partie de ce flux.

Commencez par le résultat métier. Cartographiez votre chaîne de valeur. Attribuez des responsabilités claires. Ensuite, construisez le pipeline qui sert ce système, et non l'inverse.