Réponse.

Dans une architecture à multiples services, chaque service est souvent responsable de sa propre base de données. Pour gérer les migrations de schémas de données, il est nécessaire d'utiliser des outils de migration spécialisés (Liquibase, Flyway, Alembic), et de les exécuter via un pipeline CI/CD pour garantir l'automatisme et la prévisibilité des résultats.

Une bonne pratique consiste à préparer chaque migration comme un script de migration avec versioning et Idempotence - le redémarrage d'un même changement ne conduira pas à une erreur ou à un désaccord.

Exemple de migration en Python avec Alembic:

from alembic import op
import sqlalchemy as sa

def upgrade():
    op.add_column('user', sa.Column('status', sa.String(8)))

def downgrade():
    op.drop_column('user', 'status')

Points clés :

• Automatisation des migrations au niveau CI/CD
• Idempotence - possibilité de réappliquer sans nuire à la structure
• Versioning des schémas de données et rollback

Questions pièges.

Est-il possible de modifier manuellement le schéma de la BDD en production sans migrations (DDL manuel)?

Cela est catégoriquement déconseillé : cela entraînera une perte de contrôle sur l'état du schéma et des difficultés avec le rollback/le suivi des modifications.

Est-il vrai qu'avec une architecture microservices, les migrations doivent être effectuées de manière centralisée pour tous les services?

Non, chaque équipe/service est responsable de son propre schéma et de son propre pipeline de migrations. La centralisation contredit les principes d'indépendance des services.

Le rollback des migrations est-il complètement sûr?

Non : il n'est pas toujours possible de revenir en arrière sur les modifications, surtout si la structure ou le format des données a changé (par exemple, si un champ a été supprimé et que les données ont été perdues). Il est préférable de concevoir les migrations en tenant compte du rollback.