Avant de planifier votre feuille de route CI/CD, faites d'abord l'inventaire

Vous vous réunissez avec votre équipe pour planifier la mise en œuvre de la CI/CD. Quelqu'un suggère de commencer par l'application la plus critique. Un autre veut corriger le processus de déploiement qui cause le plus de douleur. Une troisième personne argue pour construire un nouveau pipeline de zéro. Tout le monde a un point valable, mais personne ne sait avec certitude ce que l'équipe a réellement à disposition.

C'est là que la plupart des feuilles de route CI/CD échouent. Elles commencent par des décisions avant de comprendre l'état actuel. Vous ne pouvez pas prioriser ce qu'il faut changer si vous ne savez pas ce qui existe. La première étape n'est pas la planification. La première étape est l'inventaire.

Ce que vous devez cataloguer

L'inventaire semble administratif, mais c'est le fondement de chaque décision qui suit. Sans lui, vous devinez quels changements comptent le plus. Avec lui, vous voyez des schémas, des lacunes et des dépendances qui resteraient autrement invisibles jusqu'à ce qu'ils bloquent votre progression.

Applications

Commencez par chaque application que votre équipe gère. Incluez celles qui changent rarement, les outils internes dont personne ne parle et les systèmes legacy que tout le monde évite. Pour chaque application, enregistrez :

  • Langage de programmation et framework
  • Où se trouve le code source (dépôt, stratégie de branche)
  • Comment fonctionne le processus de build aujourd'hui (commandes manuelles, scripts, automatisation existante)
  • Qui connaît le mieux l'application

Ce dernier point compte plus qu'il n'y paraît. Lorsque vous commencerez à modifier les pipelines pour une application spécifique, vous aurez besoin de quelqu'un qui comprend ses particularités. Cette personne est votre ressource principale. Sans elle, vous ferez des hypothèses qui casseront des choses.

Bases de données

De nombreuses équipes oublient que les bases de données font partie du processus de livraison. Un pipeline CI/CD qui gère le code applicatif mais ignore les changements de base de données échouera dès qu'une migration s'exécutera en production. Pour chaque base de données connectée à vos applications, notez :

  • Type et version de la base de données
  • Comment les changements de schéma sont actuellement gérés (scripts manuels, outils de migration, rien du tout)
  • Qui gère les changements de base de données et qui intervient lorsque les migrations échouent
  • Si les changements de base de données sont testés avant d'atteindre la production

Les changements de base de données comportent des risques différents de ceux du code applicatif. Un mauvais déploiement peut souvent être annulé rapidement. Une mauvaise migration peut corrompre les données ou nécessiter des heures de récupération. Connaître votre paysage de bases de données vous aide à décider combien d'automatisation et de tests appliquer.

Infrastructure

Les applications et les bases de données s'exécutent quelque part. Enregistrez où se trouve ce quelque part pour chaque composant :

  • Serveurs physiques, machines virtuelles ou services cloud
  • Comment les environnements sont créés et configurés
  • Si la configuration est documentée ou gérée via des sessions SSH manuelles
  • Qui a accès aux environnements de production
  • Qui gère généralement les problèmes d'infrastructure

L'infrastructure gérée manuellement limitera la quantité d'automatisation que vous pouvez introduire. Si chaque serveur est un flocon de neige avec une configuration unique, votre pipeline ne pourra pas se déployer de manière fiable sur aucun d'eux. L'inventaire vous montrera quelles parties de votre infrastructure sont prêtes pour l'automatisation et lesquelles nécessitent d'abord un nettoyage.

Pipelines existants

Votre équipe peut déjà avoir une certaine automatisation en place, même si elle est incomplète. Documentez ce qui existe :

  • Quelles applications ont des processus automatisés de build, test ou déploiement
  • Ce que chaque pipeline fait réellement (build uniquement, build et test, déploiement complet)
  • Ce qui manque (pas de scan de sécurité, pas de migration de base de données, étapes d'approbation manuelles)
  • Quelle est la fiabilité des pipelines existants (échecs fréquents, tests instables, temps d'exécution longs)

Les pipelines existants ne sont pas inutiles simplement parce qu'ils sont imparfaits. Ils vous montrent ce que l'équipe a déjà compris et où se trouvent les lacunes. Un pipeline qui build et teste mais déploie manuellement vous indique sur quoi vous concentrer ensuite.

Propriété

Chaque composant a besoin d'un propriétaire. Enregistrez qui est responsable de chaque application, base de données et élément d'infrastructure. La propriété compte car les changements de pipeline nécessitent une coordination. Vous ne pouvez pas modifier le pipeline d'une application appartenant à une autre équipe sans les impliquer. Vous ne pouvez pas changer la façon dont une migration de base de données s'exécute sans parler à la personne qui gère les changements de base de données.

Notez également qui peut prendre des décisions concernant les changements. La personne qui maintient un composant peut ne pas être celle qui approuve les modifications. Connaître la chaîne de décision évite les retards plus tard.

Comment construire l'inventaire

Ne visez pas la perfection. Un inventaire complet mais approximatif vaut mieux qu'un inventaire partiel mais soigné. Utilisez l'outil que votre équipe trouve confortable : un tableur, un document partagé, un tableau blanc numérique. Le format importe moins que le contenu.

Le diagramme suivant décrit le processus d'inventaire recommandé :

flowchart TD A[Démarrer l'inventaire] --> B[Lister les applications] B --> C[Lister les bases de données] C --> D[Lister l'infrastructure] D --> E[Lister les pipelines existants] E --> F[Assigner les propriétaires] F --> G[Examiner avec l'équipe] G --> H[Identifier les lacunes] H --> I[Analyser les schémas] I --> J[Planifier la feuille de route]

Commencez par ce que vous savez. Remplissez d'abord les entrées évidentes, puis demandez aux membres de l'équipe de vérifier et de compléter leurs domaines. Planifiez une courte réunion où tout le monde examine l'inventaire ensemble. Cela révèle souvent des composants oubliés ou des dépendances supposées mais jamais confirmées.

Attendez-vous à trouver des lacunes. Certaines applications peuvent ne pas avoir de propriétaire clair. Certaines bases de données peuvent avoir des processus de migration non documentés. Certaines infrastructures peuvent fonctionner avec des identifiants dont personne ne se souvient. Ces lacunes ne sont pas des échecs. Ce sont exactement les informations dont vous avez besoin pour planifier vos prochaines étapes.

Ce que l'inventaire révèle

Une fois l'inventaire terminé, des schémas émergent. Vous pourriez voir qu'une équipe a un pipeline mature tandis qu'une autre déploie encore manuellement. Vous pourriez constater que les changements de base de données sont gérés avec soin mais que le provisionnement de l'infrastructure est chaotique. Vous pourriez découvrir que votre application la plus critique a le moins d'automatisation.

Ces schémas vous indiquent par où commencer. L'équipe avec le pipeline mature peut servir de modèle. L'application avec un déploiement manuel mais une propriété claire est un bon candidat pour l'automatisation. La base de données qui a déjà des scripts de migration est plus facile à intégrer dans un pipeline que celle qui n'a jamais été versionnée.

L'inventaire révèle également des dépendances que vous ne pouvez pas ignorer. Une application qui dépend d'une base de données sans processus de migration ne peut pas être entièrement automatisée tant que le côté base de données n'est pas traité. Une application qui s'exécute sur une infrastructure configurée manuellement nécessitera des changements d'infrastructure avant que le pipeline puisse se déployer de manière fiable.

Liste de contrôle pratique

Utilisez cette liste de contrôle pour guider votre effort d'inventaire :

  • Listez chaque application que votre équipe gère, y compris les systèmes internes et legacy
  • Pour chaque application, enregistrez le langage, le dépôt, le processus de build et le contact principal
  • Listez chaque base de données connectée à ces applications
  • Pour chaque base de données, enregistrez le type, la version, le processus de migration et la personne responsable
  • Documentez où chaque application et base de données s'exécute (serveur, VM, cloud)
  • Notez comment les environnements sont créés et configurés
  • Documentez les pipelines existants : ce qu'ils font, ce qui leur manque, leur fiabilité
  • Enregistrez la propriété pour chaque composant
  • Identifiez qui peut approuver les changements pour chaque composant

L'essentiel à retenir

L'inventaire n'est pas un exercice bureaucratique. C'est la chose la plus utile que vous puissiez faire avant de planifier toute amélioration CI/CD. Une équipe qui sait exactement ce qu'elle a peut prendre des décisions basées sur des faits plutôt que sur des suppositions. Une équipe qui saute l'inventaire continuera de découvrir des surprises en cours de mise en œuvre, et ces surprises coûteront du temps, de la confiance et de l'élan.

Commencez votre feuille de route en sachant ce que vous possédez déjà. Les schémas dans votre inventaire vous diront où aller ensuite.