Compartir a través de


Procedimientos recomendados para la modernización de GitHub Copilot

Siga estas instrucciones para obtener los mejores resultados en la modernización con GitHub Copilot al actualizar y migrar proyectos .NET.

Antes de comenzar

Prepare los proyectos antes de iniciar una actualización para obtener los mejores resultados.

Verifica que tu solución se compile y las pruebas se superen

El agente valida los cambios que realiza mediante la ejecución de compilaciones y pruebas. Si la solución ya está rota antes de comenzar, el agente no puede distinguir los fallos preexistentes de los problemas que introdujo.

Documente los errores de prueba conocidos en scenario-instructions.md para que el agente sepa omitirlos.

Confirmar o guardar trabajos no confirmados

Comience con un directorio de trabajo limpio para evitar mezclar los cambios no confirmados con las modificaciones del agente. Una línea base limpia facilita la revisión o reversión de los cambios.

git stash
git status

Copia de seguridad de repositorios que no son de Git

El agente también funciona con carpetas que no están bajo control de código fuente. Si el proyecto no está en un repositorio de Git, el agente omite las operaciones de bifurcación y confirmación. Si es así, realice una copia de seguridad de la carpeta del proyecto antes de empezar para poder restaurarla si es necesario.

Considere inicializar un repositorio Git local antes de iniciar la actualización, incluso si no envía a un proveedor de nube. Un repositorio git local le permite:

  • Revierte los cambios individuales con git revert.
  • Realice un seguimiento del progreso de la actualización paso a paso en el historial de confirmaciones.
  • Controlar qué cambios se van a mantener o descartar.
  • Mantenga el código original seguro en la rama principal mientras el agente funciona en una rama independiente.
cd your-project-folder
git init
git add .
git commit -m "Baseline before upgrade"

Revisión de la cobertura de pruebas

El agente se basa en pruebas para validar que sus cambios no interrumpen el comportamiento. Los proyectos con una buena cobertura de pruebas obtienen actualizaciones de mayor confianza.

Sugerencia

No necesita una cobertura del 100%. Céntrese en el código que es más probable que cambie la actualización, como los límites de api, la serialización, el acceso a la base de datos y la autenticación.

Inicio pequeño

Si esta es la primera vez que usa el agente, elija un proyecto pequeño y de bajo riesgo como piloto. Un proyecto de biblioteca de clases o de utilidad es ideal. El inicio pequeño le permite comprender el flujo de trabajo, crear confianza y detectar cualquier problema específico del repositorio antes de abordar la aplicación principal.

Durante la actualización

Siga estas instrucciones mientras el agente ejecuta su actualización.

Usar el modo guiado para la primera actualización

El agente admite modos guiados y automáticos. En el modo guiado, el agente se detiene en los puntos de decisión clave para su revisión y aprobación. Comience con el modo guiado para comprender lo que hace el agente y por qué. Cambie al modo automático una vez que se sienta cómodo con el flujo de trabajo.

Revise cuidadosamente la evaluación.

La evaluación es la mejor oportunidad de detectar problemas antes de que el agente empiece a realizar cambios. Busque:

  • Proyectos que el agente podría haber pasado por alto o identificado incorrectamente.
  • Dependencias que usted sabe que son problemáticas.
  • ¿Alguna cosa inusual sobre la solución que el agente deba conocer?

Si detecta algo, indique al agente en el chat o agregue la información a scenario-instructions.md. También puede editar assessment.md directamente para agregar contexto, corregir proyectos mal identificados o señalar preocupaciones antes de que el agente continúe con la planificación.

Dedique tiempo a la fase de planificación

El agente genera un plan en función de su evaluación. Revise el plan antes de continuar:

  • ¿Tiene sentido el orden del código base?
  • ¿Es posible que el agente no conozca las dependencias?
  • ¿Deben excluirse o controlarse proyectos de forma diferente?

Pida al agente que reordene las tareas, omita proyectos o cambie su enfoque. Conoce mejor el código base que el agente, por lo que debe usar ese conocimiento. Edite el archivo directamente para ajustar el plan.md orden de tareas, agregar tareas o quitar tareas.

Precaución

Tenga cuidado al editar plan.md directamente. Es posible que el agente no interprete completamente los cambios si estos crean instrucciones contradictorias. Por ejemplo, quitar un proyecto de dependencia mientras mantiene los proyectos que dependen de él.

Enviar comentarios inmediatamente

El agente aprende de tus correcciones durante una sesión. Si el agente toma una decisión con la que usted no está de acuerdo:

  • Dígalo inmediatamente: "No use ese patrón, use X en su lugar".
  • Agregue orientación persistente a scenario-instructions.md para que el agente lo recuerde a través de tareas y sesiones.

Mantener el compromiso durante la ejecución

La ejecución no es automática. Antes de indicar al agente que se inicie, revise tasks.md:

  • ¿Tiene sentido el orden de tareas para el código base?
  • ¿Hay tareas que quiera omitir o reordenar?
  • ¿Faltan tareas?

Pida al agente que ajuste la lista de tareas o edite tasks.md directamente antes de que comience la ejecución. Una vez que se inicia la ejecución, si el agente realiza una llamada incorrecta a la mitad de la tarea, infórmeselo inmediatamente: aplicará su corrección en adelante.

Conoce mejor el código base que el agente, por lo que debe usar ese conocimiento en cada fase.

Dificultades habituales

Observe estos problemas comunes que pueden ralentizar o complicar una actualización.

Soluciones grandes con más de 50 proyectos

El agente funciona proyecto por proyecto, por lo que las soluciones grandes llevan tiempo. Sea paciente y supervise el progreso. Considere la posibilidad de empezar con un proyecto representativo de un extremo a otro antes de confirmar la solución completa. Un piloto de un solo proyecto expone problemas sistémicos al principio.

Fuentes de NuGet privadas

Para fuentes privadas de NuGet, autentíquese antes de iniciar la actualización (por ejemplo, a través del proveedor de credenciales o la configuración de fuente de la organización). Sin autenticación, los errores de restauración de paquetes bloquean el progreso.

Objetivos e importaciones personalizados de MSBuild

Las personalizaciones de compilación complejas, como archivos personalizados .targets , importaciones condicionales o lógica de compilación no estándar, pueden confundir la evaluación y provocar errores de compilación inesperados. Si la solución tiene estas personalizaciones, mencione estas personalizaciones en el chat o en scenario-instructions.md para que el agente pueda tenerlas en cuenta.

Tiempos de espera de sesión

Las actualizaciones de larga duración pueden abarcar varias sesiones. El agente realiza un seguimiento de su progreso en los archivos de flujo de trabajo (en .github/upgrades/), de modo que puede reanudar donde lo dejó. Al iniciar una nueva sesión, mencione dónde estaba: "Continuar la actualización de .NET 10. Estaba en medio del proyecto Data.Access."

Colaborar de forma eficaz

La calidad de la interacción afecta directamente a la calidad de los resultados.

Ser específico sobre el ámbito

Cuanto más específico sea, mejor rendimiento tendrá el agente.

En lugar de Probar
"Actualizar todo" "Actualizar el proyecto Data.Access a .NET 10"
"Corregir la compilación" "Corrección del error de compilación en CustomerService.cs relacionados con la API eliminada"
"Migrar los elementos de la base de datos" "Migración de Entity Framework 6 a EF Core en el proyecto de repositorio"

Comparte tus restricciones

Informe al agente sobre las restricciones reales por adelantado:

  • "No podemos interrumpir la compatibilidad con versiones anteriores de la API pública".
  • "Tenemos una fecha límite de lanzamiento en dos semanas, así que priorice los proyectos web".
  • "El módulo de informes heredado debe excluirse de esta actualización".

Explicación de la arquitectura

El agente analiza la estructura de código, pero no conoce el modelo mental del equipo. Ayude al agente a comprender lo siguiente:

  • "Project A es nuestra biblioteca compartida. B, C y D dependen de él."
  • "El proyecto WebApi es nuestra API pública; Internal.Api solo es para servicios internos".
  • "El proyecto Models se genera automáticamente a partir de nuestra especificación de OpenAPI. No lo modifiques directamente".

Pregunte por qué

El agente puede explicar su razonamiento. Si una decisión no parece correcta, pregunte:

  • "¿Por qué ha elegido el orden de abajo arriba?"
  • "¿Por qué va a actualizar este paquete a la versión X en lugar de Y?"
  • "¿Por qué lo dividiste en subtareas?"

Comprender el razonamiento le ayuda a proporcionar mejores comentarios.

Guardar las preferencias antes

Si tiene preferencias sólidas sobre el estilo de codificación, los patrones o los enfoques, agréguelos a scenario-instructions.md en la primera sesión. Este archivo persiste entre sesiones y siempre está en el contexto del agente, lo que lo convierte en la manera más confiable de influir en el comportamiento.

Recuperarse de problemas

Use estas estrategias cuando la actualización no vaya según lo previsto.

Errores de compilación después de una tarea

Indique al agente: "Se produce un error en la compilación después de la última tarea". El agente analiza el error e intenta corregirlo. Si el agente no puede resolver el problema:

  1. Proporcione una corrección manual e indique al agente lo que hizo. El agente aprende de la corrección que haces.
  2. Revierta la confirmación (git revert o restablezca a la confirmación anterior) y pida al agente que pruebe un enfoque diferente.
  3. Omita la tarea problemática y vuelva a ella más adelante.

Estrategia incorrecta elegida

Si el enfoque general del agente no funciona para el código base, reinicie la fase de planeación:

  • "Rehagamos el plan. Quiero actualizar primero los proyectos web en lugar de abajo arriba".
  • "Cambie la estrategia para actualizar todas las bibliotecas compartidas en un lote".

Agente bloqueado en un bucle

Si el agente repite la misma corrección sin progreso, diga "Detener" y describa lo que observa o detenga la sesión manualmente. El agente puede restablecer su enfoque e intentar algo diferente.

Deshacer todos los cambios

Si ha usado una rama de Git para la actualización, deshaga todo cambiando a la rama original:

git checkout your-original-branch
git branch -D upgrade-branch

Tu código original está intacto. Si está trabajando sin control de código fuente, restaure desde la copia de seguridad que realizó antes de empezar.

Seguridad y privacidad

  • Fragmentos de código: GitHub Copilot los procesa según la política de privacidad de GitHub Copilot y no los conserva más allá de la sesión inmediata.
  • Los archivos de flujo de trabajo (scenario-instructions.md, tareas personalizadas, preferencias) permanecen en el repositorio en .github/upgrades/. GitHub no transmite estos archivos a servicios externos.
  • La .github/upgrades/ carpeta forma parte del repositorio. Confirme la carpeta porque contiene el progreso y el estado de la actualización. El agente necesita la carpeta para reanudar el trabajo entre sesiones. Puede quitarlo una vez completada la actualización.
  • Telemetría: deshabilite a través de la configuración de telemetría del IDE.

Consejos de rendimiento

  • Cierre archivos y pestañas innecesarios: el agente analiza el área de trabajo activa y menos archivos abiertos significa menos ruido.
  • Actualizar en fases para soluciones muy grandes: en lugar de actualizar todos los proyectos a la vez, procesarlos por lotes. Por ejemplo, actualice primero todas las bibliotecas, luego todos los proyectos web y, a continuación, pruebe.
  • Uso del almacenamiento en caché de compilación: el agente ejecuta muchas compilaciones incrementales durante la validación. Las cachés de compilación calientes hacen que la validación sea significativamente más rápida. Evite limpiar la salida de compilación entre tareas.