Re-architecturer des projets à l’aide de GitHub Copilot pour moderniser

Cet article explique comment utiliser la fonctionnalité de re-architecture dans la modernisation de GitHub Copilot pour réécrire des projets de frameworks hérités vers des architectures modernes, comme de Struts à Spring MVC.

Aperçu

La fonctionnalité de re-architecture vous permet de transformer un projet entier d’une infrastructure héritée vers une architecture moderne à l’aide d’un flux de travail multi-agent alimenté par l’IA. Au lieu de migrer manuellement des fichiers par fichier, décrivez la transformation souhaitée en langage naturel et les agents de modernisation gèrent l’analyse, la planification et la génération de code.

Les scénarios courants de re-architecture sont les suivants :

  • Struts vers Spring MVC
  • De Struts à Spring Boot
  • JSP à Thymeleaf
  • EJB vers Spring Boot
  • Migration des applications WebSphere vers Spring Boot
  • Applications basées sur servlet anciennes vers des architectures modernes basées sur Spring
  • des applications de bureau Windows Forms (WinForms) aux applications web Angular
  • Applications frontend ASP.NET MVC vers des applications web Angular

Prerequisites

  • Visual Studio Code avec l’extension de modernisation GitHub Copilot installée.
  • Un abonnement GitHub Copilot. Pour plus d’informations, consultez Copilot plans.
  • (Facultatif) Python 3.7 ou version ultérieure pour créer un graphe de connaissances, ce qui donne à l’agent une compréhension plus claire de la structure de votre projet pendant le processus de réécriture. Si Python n'est pas disponible, l'étape du graphe de connaissances est ignorée.
  • (Facultatif) Node.js 18 ou version ultérieure pour exécuter des tests playwright dans le cadre de la validation du runtime. Si Node.js n’est pas disponible, l’étape de test Playwright est ignorée.
  • (Facultatif) Docker Desktop pour la validation du runtime. Si Docker n’est pas disponible, l’étape de validation du runtime est ignorée.

Utiliser l’agent de re-architecture

Utilisez l’agent de modernisation dans le panneau Copilot Chat GitHub.

Procédez comme suit pour réécrire un projet :

  1. Ouvrez votre projet dans Visual Studio Code.

  2. Ouvrez le panneau GitHub Copilot Chat.

  3. Sélectionnez l’agent modernize dans la liste des agents.

  4. Décrivez la transformation que vous souhaitez effectuer. Par exemple:

    Rewrite the entire project from Struts to Spring MVC using rearchitecture agent

L’agent coordonne une équipe multi-agent qui effectue les étapes suivantes :

  1. Analyse : examine la base de code existante, identifiant les modèles d’infrastructure, les dépendances et les limites de module.
  2. Planification : génère un plan d’implémentation structuré avec des tâches ordonnées et une traçabilité des exigences.
  3. Exécution : applique des transformations de code en suivant le plan, avec des vérifications de validation à chaque étape.

Important

Une fois les phases d’analyse et de planification terminées, l’agent suspend et demande votre confirmation avant de commencer la génération du code. Passez en revue attentivement le plan à ce stade. Vous pouvez demander des modifications au plan, ajuster les priorités ou ajouter des contraintes avant que l’agent passe à l’implémentation.

Fournir davantage de contexte

Vous pouvez améliorer les résultats de la transformation en fournissant un contexte supplémentaire dans votre invite :

  • Spécifiez les versions du framework cible, par exemple « Utiliser Spring Boot 3.2 et Java 21 ».
  • Liens de documentation de référence ou guides de migration.
  • Décrire des modèles ou des conventions spécifiques à l’organisation.
  • Indiquez les modules ou packages à hiérarchiser.

Par exemple:

Rewrite the entire project from Struts to Spring MVC using Spring Boot 3.2.
Refer to the Spring MVC migration guide at https://docs.spring.io/spring-framework/reference/web/webmvc.html.
Keep the existing backend business logic unchanged.

Résoudre des problèmes courants

Pendant le processus de re-architecture, l’agent génère des artefacts dans le .github/modernize/ répertoire de votre projet. Utilisez ces artefacts pour diagnostiquer les problèmes lorsqu’ils surviennent.

Passer en revue les artéfacts générés

Le .github/modernize/rearchitecture répertoire contient les ressources clés suivantes :

  • board.md - Tableau des tâches qui suit chaque phase et son état. Vérifiez ce fichier pour voir les tâches passées, ayant échoué ou les itérations requises.
  • artifacts/ - Rapports détaillés de chaque tâche. Les fichiers suivent une convention de nommage telle que t21-tester-report.md pour le rapport de test initial ou t21.2-tester-report.md pour une itération de nouvelle tentative.
  • learn.md - Base de connaissances cumulative des découvertes, détection de bogues et techniques enregistrées par chaque rôle pendant l’exécution de la tâche. Consultez ce fichier pour obtenir des informations sur les problèmes rencontrés par l’agent et la façon dont il les a résolus.
  • team/ - Chartes spécifiques aux rôles qui définissent les responsabilités de chaque agent.

Lorsqu'une barrière de qualité n'est pas respectée, l'agent crée des artefacts d’itération (par exemple, t21.1, t21.2) qui documentent les tentatives de correction. Recherchez ces itérations numérotées pour comprendre comment un problème a été détecté et résolu.

Passer en revue l’analyse et le plan

Avant que l’agent commence à écrire du code, il produit des artefacts d’analyse et de planification que vous devez examiner. Ces artefacts vous donnent une visibilité sur ce que l'agent a compris de votre projet et ce qu'il prévoit de construire.

Les artefacts d’analyse sont les suivants :

  • Résumé de l’architecture : vue d’ensemble de la pile technique existante, de la structure de projet, du modèle de données et des points d’intégration. Vérifiez ce résumé pour vérifier que l’agent a correctement identifié les composants clés de votre projet. Recherchez des fichiers tels que artifacts/t2-architect-architecture-summary.md, artifacts/t2-architect-tech-stack.mdet artifacts/t2-architect-data-model.md.
  • Inventaire des fonctionnalités : catalogue de toutes les fonctionnalités de l’application d’origine, chacun a affecté un ID d’exigence (par exemple, REQ-001). Vérifiez que cette liste est complète et précise. Recherchez artifacts/t3-pm-spec.md.
  • Conception de l’architecture cible : les contrats d’API proposés, la structure de module et les choix technologiques pour la nouvelle application. Recherchez des fichiers tels que artifacts/t5-architect-api-contracts.md et artifacts/t5-architect-integration.md.

Les artefacts de planification sont les suivants :

  • Plan d’implémentation : liste triée des tâches avec dépendances, regroupée en phases. Chaque tâche revient à une ou plusieurs exigences de l’inventaire des fonctionnalités. Recherchez artifacts/t7-teamlead-plan.md.
  • Stratégie de test : approche planifiée pour les tests unitaires, les tests d’intégration et les tests de bout en bout. Recherchez artifacts/t7-teamlead-testing-strategy.md.

L’agent s’interrompt après avoir généré ces artefacts et attend votre confirmation. Utilisez cette opportunité pour :

  • Vérifiez qu’aucune fonctionnalité n’est manquante dans l’inventaire.
  • Vérifiez que l’architecture cible correspond à vos attentes.
  • Ajustez les priorités des tâches ou ajoutez des contraintes avant le début de l’implémentation.

Une révision minutieuse à ce stade permet d’éviter les remaniements coûteux pendant les phases d’implémentation et de validation.

Échecs de compilation et de démarrage

Si l’application transformée ne parvient pas à compiler ou démarrer, utilisez l’approche suivante :

  1. Vérifiez l’artefact de rapport du testeur (par exemple t21-tester-report.md) pour obtenir la sortie de build et les traces de pile.
  2. Recherchez le type d’exception ou le message d’erreur dans l’artefact pour identifier la cause racine.
  3. Si l’agent a créé des itérations de correctif (par exemple, t21.1, t21.3), passez en revue ces artefacts pour voir quelles modifications ont été tentées.

Les causes racines courantes incluent les collisions de nommage entre les classes héritées et nouvellement générées, les configurations de profil Spring incorrectes et les dépendances manquantes ou conflictuelles dans pom.xml. Par exemple, si les contrôleurs hérités et modernes partagent le même nom de classe, Spring lève un ConflictingBeanDefinitionException au démarrage.

Erreurs d’exécution

Si l’application démarre mais que les appels d’API retournent des erreurs (telles que 500 ou 400 réponses), utilisez l’approche suivante :

  1. Vérifiez l’artefact de rapport du testeur pour lequel les points de terminaison ont échoué et les messages d’erreur associés.
  2. Passez en revue l’artefact des résultats de sécurité (par exemple, t20-security-findings.md) pour connaître les problèmes de configuration.
  3. Inspectez les classes d’entité générées et le code du contrôleur pour obtenir des incompatibilités entre le schéma de base de données et les mappages ORM.

Les causes racines courantes incluent les conflits de mots clés réservés de base de données dans @Column les annotations, les incompatibilités entre les types de champs DTO et les types de champs d’entité et les annotations de validation manquantes sur les objets de requête.

Échecs de seuil de qualité et itérations

L'agent applique plusieurs garde-fous de qualité pendant le processus de réarchitecture. En cas d’échec d’une porte, l’agent crée automatiquement des tâches de correction et retente la validation. Les défaillances courantes de la porte sont les suivantes :

  • Révision de l’architecture : l’agent vérifie que l’implémentation correspond aux contrats d’API conçus, aux structures DTO et aux mappages de points de terminaison. Les échecs impliquent généralement des points de terminaison manquants, des champs renommés ou des annotations de validation manquantes. Passez en revue l’artefact de rapport d’architecte (par exemple, t19-architect-review.md) afin d'obtenir des résultats spécifiques.
  • Examen de la conformité : l’agent vérifie que la mise en œuvre respecte tous les principes définis dans la constitution initiale. Un échec courant est l’absence de tests de bout en bout au niveau du navigateur lorsque la constitution les requiert. Passez en revue l’artefact de révision du responsable de l’équipe (par exemple t22-teamlead-review.md) pour identifier les principes qui n’ont pas été satisfaits.
  • Validation de la parité des fonctionnalités : l’agent vérifie que toutes les exigences cataloguées sont implémentées. Une validation partielle signifie que certaines fonctionnalités spécifiques sont incomplètes, par exemple, la validation inter-champs manquante, comme s'assurer que fromDate est antérieure à toDate. Passez en revue l'artefact d'approbation du chef de projet (par exemple, t23-pm-signoff.md) pour connaître la répartition exigence par exigence.

Si l’agent atteint sa limite d’itération sans résoudre tous les problèmes, passez en revue les derniers fichiers d’artefact pour comprendre les lacunes restantes et appliquer des correctifs manuels.

Conditions préalables à la validation du runtime

L’agent effectue des étapes de validation d’exécution facultatives qui dépendent d’outils externes. Si aucun outil n’est disponible, l’étape correspondante est ignorée :

  • Python non installé : l’étape du graphe de connaissances est ignorée. L’agent peut toujours effectuer la nouvelle architecture, mais peut avoir moins de contexte sur la structure de votre projet. Installez Python 3.7 ou version ultérieure et vérifiez que python3 est disponible dans votre chemin d’accès.
  • Node.js non installé : les tests de bout en bout au niveau du navigateur playwright sont ignorés. L’agent exécute toujours des tests d’intégration via Maven. Installez Node.js 18 ou version ultérieure pour activer les tests de navigateur.
  • Docker non disponible : la validation du runtime (démarrage de l’application dans un conteneur et vérification de ses demandes) est ignorée. L’agent s’appuie plutôt sur des tests unitaires et d’intégration. Installez et démarrez Docker Desktop pour activer cette étape.

Limites

Gardez à l’esprit les limitations suivantes :

  • Les projets complexes avec des frameworks hérités profondément couplés peuvent nécessiter plusieurs itérations.
  • Vous devez examiner attentivement le code généré avant de valider les modifications.

Fournir des commentaires

Si vous avez des commentaires sur la fonctionnalité de re-architecture, créez un problème dans le dépôt github-copilot-appmod ou utilisez le formulaire de commentaires de modernisation GitHub Copilot.

Voir aussi

Vue d’ensemble de la modernisation de Java avec GitHub Copilot

  • Last updated on