migration-architect

Présentation du skill migration-architect

À quoi sert migration-architect

Le skill migration-architect aide à préparer des migrations logicielles, bases de données, services et infrastructures à haut risque, lorsque l’indisponibilité, la perte de données, la rupture d’API ou une stratégie de retour arrière floue peuvent créer un risque métier. Il est particulièrement utile quand une simple checklist générique ne suffit pas : exécution par phases, validation de compatibilité, plan de bascule, réconciliation des données et runbook de rollback exploitable par les équipes d’exploitation.

Utilisateurs et scénarios de migration les plus adaptés

Utilisez le skill migration-architect si vous êtes architecte logiciel, staff engineer, platform engineer, SRE, responsable base de données ou owner de programme technique chargé d’une transition en production. Il convient aux montées de version PostgreSQL ou d’autres bases de données, aux migrations de monolithe vers services, au remplacement progressif de services avec le pattern strangler fig, aux bascules cloud, à l’évolution de schémas, au versionnement d’API et aux migrations soumises à des contraintes de conformité comme GDPR, SOX ou PCI DSS.

Ce qui différencie ce skill

Le repository apporte un support pratique au-delà du simple texte de prompt : scripts/migration_planner.py, scripts/compatibility_checker.py et scripts/rollback_generator.py, ainsi que des exemples de spécifications de migration de base de données et de service. Les fichiers de référence couvrent les patterns de migration, les techniques de zéro interruption et les stratégies de réconciliation des données, ce qui rend le skill plus solide pour les décisions de Software Architecture qu’un prompt ponctuel du type « fais-moi un plan ».

Points à considérer avant l’adoption

Ce skill donne ses meilleurs résultats lorsque vous pouvez fournir de vraies contraintes : budget d’indisponibilité, dépendances, changements de schéma, profil de trafic, volume de données, exigences de conformité, portes de validation et déclencheurs de rollback. Il ne remplace pas les tests propres à votre environnement, les tests de charge, l’expertise sur le moteur de base de données ni les validations formelles de changement. Considérez sa sortie comme un accélérateur de planification d’architecture, pas comme une autorisation automatique de mise en production.

Comment utiliser le skill migration-architect

Installation de migration-architect et premiers fichiers à lire

Installez le skill dans un environnement compatible avec Claude Skills avec :

npx skills add alirezarezvani/claude-skills --skill migration-architect

Puis inspectez le skill dans :

engineering/skills/migration-architect

Lisez d’abord README.md pour comprendre la carte des composants et les commandes de démarrage rapide, puis SKILL.md pour le workflow attendu. Parcourez assets/sample_database_migration.json et assets/sample_service_migration.json avant de rédiger votre propre entrée, car ces fichiers montrent le niveau de détail attendu par les scripts et les prompts. Consultez expected_outputs/ pour comprendre la forme des livrables utiles avant de demander une sortie personnalisée.

Les entrées qui rendent migration-architect efficace

Un prompt faible dirait : « Planifie notre migration de base de données. » Un prompt plus robuste donne au skill un contexte exploitable pour la décision :

• type de migration : base de données, service, infrastructure ou hybride
• plateformes source et cible, versions et modèle d’hébergement
• limite d’indisponibilité et tolérance à la perte de données
• volume de données, nombre de lignes, criticité des tables ou charge de requêtes
• services dépendants, clients, jobs, files, analytics et sauvegardes
• changements de schéma ou d’API, y compris les risques de breaking change
• exigences de conformité, d’audit, de conservation et de chiffrement
• métriques de succès, requêtes de validation, déclencheurs de rollback et rôles des owners

Exemple de prompt :

« Use the migration-architect skill to create a phased zero-downtime migration plan for PostgreSQL 13 on-prem to PostgreSQL 15 managed cloud. Data volume is 2.5 TB. Max downtime is 30 minutes. Critical dependencies are authentication, notification, analytics, and backups. Include compatibility risks, validation gates, reconciliation checks, rollback criteria, and a stakeholder communication timeline. »

Utiliser les scripts inclus

Le README montre l’utilisation en ligne de commande pour générer des plans et des rapports. Un workflow typique ressemble à ceci :

python3 scripts/migration_planner.py \
  --input assets/sample_database_migration.json \
  --output migration_plan.json \
  --format both

Utilisez scripts/compatibility_checker.py avec des fichiers de schéma avant/après, comme assets/database_schema_before.json et assets/database_schema_after.json, afin de faire ressortir les risques de compatibilité. Utilisez scripts/rollback_generator.py une fois le plan de migration créé, afin que les étapes de rollback soient alignées avec les phases prévues plutôt qu’avec une gestion d’échec générique.

Workflow pratique pour obtenir de meilleurs plans

Commencez par copier un asset d’exemple dans votre propre spécification de migration, puis remplacez chaque placeholder par des faits de production. Demandez au skill un premier plan, puis demandez séparément un rapport de compatibilité, un runbook de rollback et une checklist de bascule. Comparez le résultat avec expected_outputs/sample_database_migration_plan.txt, schema_compatibility_report.txt et rollback_runbook.txt pour vérifier si la sortie est assez précise pour être revue par l’ingénierie, les SRE, la sécurité et les owners métier.

FAQ du skill migration-architect

migration-architect sert-il uniquement aux migrations de base de données ?

Non. Le repository contient des exemples de migration de base de données et de service. Le parcours base de données est particulièrement concret, car il inclut des assets de schémas avant/après et une vérification de compatibilité, mais l’exemple service couvre aussi la migration strangler fig, la compatibilité des endpoints, les changements de profil de charge, les dépendances clients et la continuité de session.

En quoi est-ce mieux qu’un prompt de migration ordinaire ?

Un prompt ordinaire produit souvent une checklist plausible. Le skill migration-architect est structuré autour des patterns de migration, des techniques de zéro interruption, de l’analyse de compatibilité, de la réconciliation des données et de la génération de rollback. Les scripts inclus et les sorties attendues facilitent la création d’artefacts qui ressemblent à de vrais runbooks d’ingénierie plutôt qu’à des notes de stratégie.

Les débutants peuvent-ils utiliser le skill migration-architect ?

Oui, mais les débutants devraient partir des fichiers JSON d’exemple et éviter de passer sous silence les contraintes. Le skill peut aider à comprendre la structure d’une bonne planification, mais il suppose que vous pouvez identifier les systèmes, les dépendances, les data stores, les limites opérationnelles et les besoins de validation. Si ces éléments sont inconnus, utilisez le premier passage pour générer des questions de découverte avant de demander un plan final.

Quand ne faut-il pas utiliser ce skill ?

Ne vous appuyez pas uniquement sur migration-architect pour une récupération d’urgence en production, du tuning de base de données propre à un fournisseur, une validation juridique de conformité ou des changements qui nécessitent un accès approfondi à une infrastructure propriétaire. Il est également peu adapté aux migrations triviales sans utilisateurs en production, sans risque de compatibilité et sans exigence de rollback.

Comment améliorer le skill migration-architect

Améliorer les résultats de migration-architect avec des contraintes plus précises

Le mode d’échec le plus fréquent est un plan qui semble complet mais qui n’est pas exécutable. Évitez-le en fournissant des chiffres fermes : indisponibilité maximale, RPO/RTO, taille des données, trafic de pointe, fenêtres de batch, tolérance au lag de réplication, limite de temps pour le rollback et personnes habilitées à approuver chaque gate. Remplacez les formules vagues comme « downtime minimal » par des seuils mesurables, par exemple « pas plus de 5 minutes d’indisponibilité en écriture ».

Ajouter des détails de validation et de réconciliation

Pour les travaux sur base de données, incluez les clés primaires, les nombres de lignes, les tables critiques, les changements de schéma, les index, les contraintes et des requêtes de validation représentatives. Pour les travaux sur service, incluez les listes d’endpoints, les codes de statut attendus, les engagements de compatibilité, la stratégie de répartition du trafic, les cibles de latence et les versions clients. Le skill fonctionne mieux lorsqu’il peut transformer ces éléments en gates, smoke tests et contrôles de réconciliation.

Itérer du plan au runbook

Ne vous arrêtez pas au premier plan de migration. Demandez une revue des risques, puis un runbook de rollback, puis une checklist opérateur. Un prompt de suivi utile serait : « Review this plan for hidden coupling, missing validation gates, rollback ambiguity, and data reconciliation gaps. Return only changes that would reduce production risk. » Cela fait passer migration-architect du rôle de planificateur à celui d’assistant de revue.

Étendre le repository pour votre environnement

Pour améliorer le skill migration-architect dans le cadre d’un usage interne récurrent, ajoutez des templates propres à votre organisation : gates d’approbation, contacts d’incident, commandes de fournisseur cloud, procédures de sauvegarde de base de données, dashboards d’observabilité, standards de feature flags et contrôles de monitoring post-bascule. Conservez-les comme fichiers de référence réutilisables plutôt que de les enfouir dans un seul prompt, afin que les futurs plans de migration héritent des mêmes standards opérationnels.