Étendre le CI/CD à la base de données et à l'infrastructure : une feuille de route pratique

Votre pipeline applicatif fonctionne parfaitement. Les modifications de code passent du commit à la production avec des tests, builds et déploiements automatisés. L'équipe se sent confiante pour pousser les mises à jour. Mais il y a un problème : les changements de schéma de base de données se font encore via des scripts SQL exécutés manuellement en production, et l'infrastructure est configurée en se connectant aux consoles cloud et en cliquant sur des boutons.

Ce décalage crée des frictions. Un développeur ajoute une nouvelle colonne à une table, mais le script de migration est envoyé par e-mail à un DBA qui l'exécute manuellement. Un serveur nécessite une modification de configuration, mais quelqu'un doit se connecter en SSH et éditer les fichiers. Ces étapes manuelles brisent la cohérence que vous avez construite ailleurs. Elles introduisent des risques, manquent de pistes d'audit et rendent les rollbacks quasi impossibles.

La bonne nouvelle, c'est que les mêmes principes de pipeline s'appliquent aux bases de données et à l'infrastructure. La différence réside dans les détails : ce que vous testez, comment vous gérez les risques et comment vous gérez les rollbacks.

Intégrer les migrations de base de données dans le pipeline

Les changements de base de données sont différents du code applicatif car ils opèrent sur des données en direct. Un bug dans le code applicatif peut provoquer des erreurs faciles à corriger. Une mauvaise migration peut corrompre ou supprimer définitivement des données. Cette réalité rend les équipes hésitantes à automatiser les déploiements de base de données, mais l'alternative – l'exécution manuelle – est pire.

Commencez par traiter chaque changement de schéma comme du code. Chaque migration doit être un script stocké dans un système de contrôle de version, soit dans le même dépôt que votre application, soit dans un dépôt dédié. Le script doit avoir une version claire, une description de ce qu'il fait et un script de rollback correspondant.

Par exemple, une migration pour ajouter une colonne pourrait ressembler à ceci :

-- V002__add_status_column.sql
-- Migration forward : ajouter une colonne status avec une valeur par défaut
ALTER TABLE users ADD COLUMN status VARCHAR(20) NOT NULL DEFAULT 'active';

-- V002__add_status_column_rollback.sql
-- Migration de rollback : supprimer la colonne status
ALTER TABLE users DROP COLUMN status;

Le diagramme suivant illustre comment les étapes de base de données et d'infrastructure s'intègrent dans votre pipeline existant :

flowchart TD A[Commit de code] --> B[Build & Tests unitaires] B --> C[Déploiement applicatif en staging] C --> D[Exécution à blanc de la migration BDD] D --> E[Provisionnement de l'infrastructure] E --> F[Tests d'intégration] F --> G{Passerelle d'approbation ?} G -- Oui --> H[Déploiement en production] G -- Non --> I[Rollback] H --> J[Application de la migration BDD] J --> K[Application de l'infrastructure] K --> L[Tests de fumée] L -- Succès --> M[Déploiement terminé] L -- Échec --> I I --> N[Restauration de l'état précédent]

Votre pipeline exécute ensuite ces migrations automatiquement dans tous les environnements : développement, staging et production. Mais comme les enjeux sont plus élevés, vous avez besoin de passerelles supplémentaires :

  • Exécutions à blanc en staging : Avant d'exécuter une migration en production, exécutez-la en staging avec un volume de données qui reflète la production. Cela permet de détecter les problèmes de performance et les comportements de verrouillage inattendus.
  • Tests de compatibilité : Vérifiez si la migration fonctionne avec les données existantes. Une migration qui ajoute une colonne NOT NULL sans valeur par défaut échouera si des lignes existantes ont des valeurs NULL dans cette colonne.
  • Passerelles d'approbation pour les modifications destructrices : Supprimer une colonne, changer un type de données ou retirer une table doit nécessiter une approbation manuelle. Ces modifications sont difficiles, voire impossibles à annuler.

Chaque migration doit avoir un script de rollback testé. Ajouter une colonne est généralement sûr à annuler. Supprimer une table ne l'est pas. Votre pipeline doit être capable d'exécuter le rollback automatiquement si la migration échoue ou si l'équipe décide de revenir en arrière.

Infrastructure as Code : déclarez, ne cliquez pas

L'infrastructure comprend les serveurs, les réseaux, les équilibreurs de charge, les instances de base de données et tous les composants nécessaires au fonctionnement de votre application. Lorsque vous provisionnez ces éléments manuellement via les consoles cloud, vous créez plusieurs problèmes :

  • Les environnements dérivent. Le développement peut avoir des paramètres légèrement différents de la production.
  • Les modifications sont difficiles à reproduire. Si un serveur plante, pouvez-vous le recréer à l'identique ?
  • Il n'y a pas de piste d'audit. Qui a modifié les règles du pare-feu la semaine dernière ?

La solution consiste à déclarer votre infrastructure sous forme de code. Écrivez des fichiers de configuration qui décrivent à quoi votre infrastructure doit ressembler, puis laissez le pipeline appliquer ces configurations. C'est l'infrastructure as code (IaC).

Des outils comme Terraform, AWS CloudFormation ou Pulumi vous permettent de définir des ressources dans des fichiers. Ces fichiers passent par le même pipeline que votre code applicatif : ils entrent dans un dépôt, subissent une revue de code, sont testés en développement, puis appliqués en staging et en production.

Tester l'infrastructure est différent de tester les applications. Les tests applicatifs vérifient si le code se comporte correctement. Les tests d'infrastructure vérifient si la configuration produit l'environnement attendu :

  • Les ports requis sont-ils ouverts ?
  • Le pare-feu est-il configuré correctement ?
  • La version du système d'exploitation est-elle correcte ?
  • Les tailles des ressources (CPU, mémoire, disque) sont-elles conformes ?

Certaines équipes vont plus loin en provisionnant l'infrastructure dans un environnement isolé, en exécutant des tests contre elle, puis en la détruisant. Cela donne une grande confiance avant d'appliquer les modifications en production.

Les passerelles de risque pour l'infrastructure suivent le même schéma que pour les bases de données. Un changement qui ajuste la taille du disque peut ne nécessiter que des tests automatisés. Un changement qui restructure le réseau ou remplace un type de base de données nécessite une approbation manuelle et une validation plus approfondie.

Stratégies de rollback pour la base de données et l'infrastructure

Revenir en arrière sur du code applicatif est généralement simple : déployer la version précédente. Revenir en arrière sur une migration de base de données ou un changement d'infrastructure nécessite plus de planification.

Pour les migrations de base de données, le script de rollback doit être écrit en même temps que la migration forward. Testez le rollback dans votre pipeline, pas seulement dans votre tête. Certaines migrations sont additives (ajout d'une colonne) et se rollback proprement. D'autres sont transformatrices (division d'une table) et nécessitent une logique de rollback minutieuse. Si une migration ne peut pas être rollbackée en toute sécurité, c'est un signal pour repenser l'approche de migration.

Pour l'infrastructure, votre pipeline doit stocker l'état précédent de votre configuration. Lorsque vous devez revenir en arrière, le pipeline applique la configuration précédente. Cela fonctionne bien avec les outils IaC déclaratifs car ils gèrent automatiquement le diff entre l'état actuel et l'état souhaité.

Liste de contrôle pratique pour étendre votre pipeline

Domaine Quoi ajouter Passerelle de risque Rollback
Base de données Scripts de migration dans le contrôle de version Exécution à blanc en staging, approbation pour les modifications destructrices Script de rollback testé par migration
Infrastructure Fichiers de configuration IaC Validation automatisée, approbation pour les changements d'architecture Configuration précédente stockée et déployable

Le schéma se répète

Une fois que vous avez intégré la base de données et l'infrastructure dans votre pipeline, vous remarquerez que le même schéma s'applique à d'autres domaines : configuration d'environnement, feature flags, releases d'applications mobiles. Les spécificités changent – ce que vous testez, comment vous gérez les risques, comment vous rollbackez – mais l'idée centrale reste la même. Chaque changement suit un chemin cohérent, testé et réversible.

Commencez par une migration de base de données dans votre pipeline. Puis un changement d'infrastructure. Les premiers seront lents car vous construisez le processus. Mais chacun rend le suivant plus rapide et plus sûr.

L'objectif n'est pas l'automatisation pour elle-même. C'est de s'assurer que quand quelque chose casse – et ça cassera – vous savez exactement ce qui a changé, comment le réparer et comment éviter que cela ne se reproduise.