For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navigation principale
Codex

Codex use case

Effectuer des migrations de code

Faites migrer les stacks historiques en passant par des points de contrôle maîtrisés.

Difficulty Avancé
Time horizon 1 h

Utilisez Codex pour établir la correspondance entre un système existant et une nouvelle stack, mener la migration par jalons et valider la parité avant chaque transition.

Idéal pour

  • Migrations d’une stack historique vers une stack moderne lorsqu’il faut changer de framework, de runtime, de système de build ou de conventions de plateforme.
  • Équipes qui ont besoin de couches de compatibilité, de transitions progressives et d’une validation explicite à chaque point de contrôle de la migration.

Contents

    ← Tous les cas d’utilisation

    Effectuer des migrations de code

    Faites migrer les stacks historiques en passant par des points de contrôle maîtrisés.

    Utilisez Codex pour établir la correspondance entre un système existant et une nouvelle stack, mener la migration par jalons et valider la parité avant chaque transition.

    Avancé
    1 h

    Utilisez Codex pour établir la correspondance entre un système existant et une nouvelle stack, mener la migration par jalons et valider la parité avant chaque transition.

    Avancé
    1 h

    Idéal pour

    • Migrations d’une stack historique vers une stack moderne lorsqu’il faut changer de framework, de runtime, de système de build ou de conventions de plateforme.
    • Équipes qui ont besoin de couches de compatibilité, de transitions progressives et d’une validation explicite à chaque point de contrôle de la migration.

    Skills et plugins

    • Examinez les migrations à risque, les changements de dépendances et les surfaces exposées avant de fusionner.
    • Traitez les échecs de CI après chaque jalon de migration au lieu de reporter le nettoyage à la fin.
    • Suivez les recommandations propres au framework lorsqu’une migration touche aux modèles d’application ASP.NET Core, à `Program.cs`, au middleware, aux tests, aux performances ou aux montées de version.
    Skill Why use it
    Security Best Practices Examinez les migrations à risque, les changements de dépendances et les surfaces exposées avant de fusionner.
    Gh Fix Ci Traitez les échecs de CI après chaque jalon de migration au lieu de reporter le nettoyage à la fin.
    Aspnet Core Suivez les recommandations propres au framework lorsqu’une migration touche aux modèles d’application ASP.NET Core, à `Program.cs`, au middleware, aux tests, aux performances ou aux montées de version.

    Prompt de démarrage

    Faites migrer ce code source de [legacy stack or system] vers [target stack or system]. Exigences : - Commencez par recenser les hypothèses sur lesquelles repose le système existant : routage, modèles de données, authentification, configuration, outils de build, tests, déploiement et contrats externes. - Établissez la correspondance entre l’ancienne stack et la nouvelle, et signalez tout élément sans équivalent direct. - Proposez un plan de migration progressif comprenant des couches de compatibilité ou des points de contrôle, plutôt qu’une réécriture complète en une seule fois. - Préservez le comportement existant, sauf si la migration exige explicitement une modification visible par l’utilisateur. - Procédez par jalons et exécutez le lint, la vérification des types et des tests ciblés après chaque jalon. - Gardez les options de retour arrière ou de repli clairement visibles jusqu’à la fin de la transition. - Si la validation échoue, corrigez le problème avant de continuer. - Commencez par cartographier le périmètre de la migration et par proposer un plan de points de contrôle.
    Faites migrer ce code source de [legacy stack or system] vers [target stack or system]. Exigences : - Commencez par recenser les hypothèses sur lesquelles repose le système existant : routage, modèles de données, authentification, configuration, outils de build, tests, déploiement et contrats externes. - Établissez la correspondance entre l’ancienne stack et la nouvelle, et signalez tout élément sans équivalent direct. - Proposez un plan de migration progressif comprenant des couches de compatibilité ou des points de contrôle, plutôt qu’une réécriture complète en une seule fois. - Préservez le comportement existant, sauf si la migration exige explicitement une modification visible par l’utilisateur. - Procédez par jalons et exécutez le lint, la vérification des types et des tests ciblés après chaque jalon. - Gardez les options de retour arrière ou de repli clairement visibles jusqu’à la fin de la transition. - Si la validation échoue, corrigez le problème avant de continuer. - Commencez par cartographier le périmètre de la migration et par proposer un plan de points de contrôle.

    Introduction

    Lorsque vous passez d’une stack à une autre, vous pouvez utiliser Codex pour cartographier et exécuter une migration maîtrisée : routage, modèles de données, configuration, authentification, tâches d’arrière-plan, outils de build, déploiement, tests, voire les conventions mêmes du langage et du framework.

    Codex est particulièrement utile dans ce contexte : il peut dresser l’inventaire du système existant, faire correspondre les anciens concepts aux nouveaux et effectuer la transition par points de contrôle plutôt que de procéder à une réécriture massive. Cette approche est importante lorsque vous quittez un framework historique, portez le système vers un nouveau runtime ou remplacez progressivement une stack par une autre alors que le produit doit rester opérationnel.

    Utilisation

    1. Commencez par recenser les éléments concernés par la migration : packages du système existant, conventions du framework, routage, accès aux données, authentification, configuration, outils de build, tests, hypothèses liées au déploiement et tout contrat externe qui doit rester valide après la migration.
    2. Demandez à Codex d’établir la correspondance entre les concepts du système existant et la stack cible, et de signaler ceux qui n’ont pas d’équivalent direct.
    3. Choisissez une stratégie progressive : couche de compatibilité, portage module par module, branch-by-abstraction ou remplacement selon le pattern de l’étrangleur, appliqué à une frontière à la fois.
    4. Maintenez le comportement à l’identique jusqu’à ce que la migration elle-même impose un changement visible, et indiquez explicitement les exceptions.
    5. Après chaque jalon, exécutez la validation minimale qui démontre la parité : lint, vérification des types, tests ciblés, tests de contrat, smoke tests ou comparaison côte à côte avec le parcours du système existant.
    6. Après chaque point de contrôle, examinez le diff et les risques qui subsistent pour la transition au lieu d’attendre la fin de la réécriture complète.

    Utiliser les ExecPlans

    Dans notre guide pratique de modernisation du code, nous présentons les ExecPlans : des documents qui permettent à Codex de garder une vue d’ensemble des travaux de nettoyage, de décrire précisément l’état final visé et de consigner les validations effectuées après chaque passe. Lorsque vous demandez à Codex de mener une migration complexe, demandez-lui de créer un ExecPlan pour chaque partie du système afin que chaque décision et chaque choix de stack technologique soient consignés et puissent être examinés ultérieurement.

    Combiner avec un objectif

    Pour les phases de migration de longue durée, utilisez un objectif pour guider Codex tout au long du processus. Définissez cet objectif en précisant clairement l’état final visé, les vérifications de parité, les modalités de retour arrière et la condition d’arrêt.

    Cas d’utilisation associés