Sélectionner vos préférences de cookies

Nous utilisons des cookies essentiels et des outils similaires qui sont nécessaires au fonctionnement de notre site et à la fourniture de nos services. Nous utilisons des cookies de performance pour collecter des statistiques anonymes afin de comprendre comment les clients utilisent notre site et d’apporter des améliorations. Les cookies essentiels ne peuvent pas être désactivés, mais vous pouvez cliquer sur « Personnaliser » ou « Refuser » pour refuser les cookies de performance.

Si vous êtes d’accord, AWS et les tiers approuvés utiliseront également des cookies pour fournir des fonctionnalités utiles au site, mémoriser vos préférences et afficher du contenu pertinent, y compris des publicités pertinentes. Pour accepter ou refuser tous les cookies non essentiels, cliquez sur « Accepter » ou « Refuser ». Pour effectuer des choix plus détaillés, cliquez sur « Personnaliser ».

Modifications du schéma de la base de données - Mise en pratique de l'intégration continue/livraison continue sur AWS

Modifications du schéma de la base de données

Les logiciels modernes disposent fréquemment d'une couche de base de données. En règle générale, on utilise une base de données relationnelle, qui stocke les données et la structure des données. Il est souvent nécessaire de modifier la base de données dans le cadre du processus de livraison continue. La gestion des modifications dans une base de données relationnelle nécessite une attention particulière. Elle présente en outre d'autres difficultés que celles rencontrées lors du déploiement de fichiers binaires d'application. En général, lorsque vous mettez à niveau un fichier binaire d'application, vous arrêtez l'application, la mettez à niveau, puis vous la redémarrez. Vous ne vous souciez pas vraiment de l'état de l'application, qui est géré en dehors de celle-ci.

Lors de la mise à niveau des bases de données, vous devez tenir compte de l'état de l'application, car une base de données contient de nombreuses informations d'état, mais relativement peu d'informations sur la logique et la structure.

Le schéma de la base de données avant et après l'application d'une modification doit être considéré comme différentes versions de la base de données. Pour gérer les versions, vous pouvez utiliser des outils tels que Liquibase et Flyway.

En général, ces outils appliquent des variantes des méthodes ci-dessous :

  • Ajout d'une table à la base de données dans laquelle une version de base de données est stockée.

  • Suivi des commandes de modification de la base de données et regroupement de ces commandes dans des jeux de modifications avec contrôle de version. Dans le cas de Liquibase, ces modifications sont stockées dans des fichiers XML. Flyway applique une méthode légèrement différente, selon laquelle les jeux de modifications sont traités sous forme de fichiers SQL distincts ou occasionnellement comme des classes Java distinctes pour des transitions plus complexes.

  • Lorsque Liquibase est invité à mettre à niveau une base de données, il examine la table des métadonnées et détermine les jeux de modifications à exécuter afin de mettre la base de données à jour vers la dernière version.

ConfidentialitéConditions d'utilisation du sitePréférences de cookies
© 2025, Amazon Web Services, Inc. ou ses affiliés. Tous droits réservés.