Awesome CopilotAdventures

Documentación del producto verificada

Entorno y límites de recursos del itinerario práctico

Estos ejercicios son un itinerario complementario sin fantasía de Awesome Copilot Adventures. Conservan el formato de ejercicios y tareas del material de aprendizaje importado. No necesitas completar primero las aventuras.

Para la primera instalación y la preparación de cuentas, empieza por Requisitos previos y cuentas: VS Code/Insiders, Copilot Free y los demás planes, la CLI independiente y el uso opcional de Codespaces o Azure. Las reglas de entornos de ejecución y recursos de abajo siguen siendo aplicables al ejercicio elegido.

[!TIP] ¿Empiezas sin una clonación? Usa el catálogo de ZIP del aprendiz. Cada kit incluye una lección completa, imágenes locales, un manifiesto de integridad y KIT-START.md con la raíz exacta del espacio de trabajo y la baseline. Las instrucciones de abajo son la alternativa para quienes ya tienen el checkout del currículo.

Trabaja en una copia desechable

  1. Empieza en la raíz de awesome-copilot-adventures.
  2. Selecciona un laboratorio en el catálogo. Usa su lab_id, no su título mostrado.
  3. Elige un directorio absoluto no usado fuera de este repositorio en una unidad de trabajo existente. Crea e inspecciona primero su directorio padre. Los siguientes ejemplos usan 02-csharp; reemplaza el ID del laboratorio con tu selección. No instales .NET si estás tomando un ejercicio de Node o Python.

macOS: Bash o zsh

En el Mac del taller, la unidad T9 es la unidad de trabajo seleccionada:

mkdir -p /Volumes/T9/Dev/oss/workshop-runs
node scripts/prepare-hands-on.js --lab 02-csharp --destination /Volumes/T9/Dev/oss/workshop-runs/02-csharp

Windows: PowerShell

Reemplaza D:\WorkshopRuns por un directorio en tu unidad de trabajo aprobada existente; el ejemplo no crea ni supone que exista una unidad D:.

New-Item -ItemType Directory -Force -Path 'D:\WorkshopRuns'
node scripts/prepare-hands-on.js --lab 02-csharp --destination 'D:\WorkshopRuns\02-csharp'

Linux: Bash

Reemplaza /mnt/work por tu punto de montaje de unidad de trabajo existente antes de ejecutar el ejemplo:

mkdir -p /mnt/work/workshop-runs
node scripts/prepare-hands-on.js --lab 02-csharp --destination /mnt/work/workshop-runs/02-csharp

La preparación copia solo la fixture nombrada. Rechaza un destino existente; no instala dependencias, no ejecuta código generado, no inicializa Git ni sobrescribe un proyecto.

Continúa desde la copia preparada

  1. Abre el directorio impreso como la única raíz en una nueva ventana de VS Code. Un workspace de varias raíces puede heredar instrucciones del proyecto equivocado.

  2. Ejecuta la baseline del laboratorio seleccionado desde su directorio de trabajo documentado.

  3. Si el laboratorio necesita control de versiones, inicializa solo esa copia y haz una baseline:

    git init -b training
    git status --short
    git add .
    git commit -m "Record untouched hands-on baseline"
    

    Inspecciona los archivos antes de prepararlos para el commit. Usa una identidad de Git local al repositorio si hace falta; no reemplaces la identidad global del estudiante. Un repositorio de GitHub, la visibilidad pública y un push no son requisitos previos para un laboratorio local.

Para quienes usan Git por primera vez, la guía de descarga y repositorio cubre la identidad local, la revisión de archivos, el primer commit, la creación de un repositorio privado vacío en GitHub, agregar su remoto y hacer push sin force.

Mantén los archivos temporales y las cachés en la unidad de trabajo

Para Bash/zsh en la máquina del taller con T9, ejecuta esto en el terminal que vaya a ejecutar el ejercicio. Un terminal nuevo necesita las mismas exportaciones:

export HANDS_ON_HOME=/Volumes/T9/Dev/oss/workshop-runs
export TMPDIR="$HANDS_ON_HOME/.cache/tmp"
export XDG_CACHE_HOME="$HANDS_ON_HOME/.cache"
export npm_config_cache="$HANDS_ON_HOME/.cache/npm"
export PIP_CACHE_DIR="$HANDS_ON_HOME/.cache/pip"
export UV_CACHE_DIR="$HANDS_ON_HOME/.cache/uv"
export UV_TOOL_DIR="$HANDS_ON_HOME/.tools/uv"
export UV_TOOL_BIN_DIR="$HANDS_ON_HOME/.tools/bin"
export UV_PYTHON_INSTALL_DIR="$HANDS_ON_HOME/.tools/python"
export DOTNET_CLI_HOME="$HANDS_ON_HOME/.cache/dotnet"
export NUGET_PACKAGES="$HANDS_ON_HOME/.cache/nuget"
export PYTHONDONTWRITEBYTECODE=1
export DOTNET_CLI_TELEMETRY_OPTOUT=1
export DOTNET_CLI_WORKLOAD_UPDATE_NOTIFY_DISABLE=true
export DOTNET_GENERATE_ASPNET_CERTIFICATE=false
mkdir -p "$TMPDIR" "$UV_TOOL_BIN_DIR" "$DOTNET_CLI_HOME" "$NUGET_PACKAGES"

Para otro sistema operativo, elige una unidad externa o de proyecto equivalente y establece estas variables usando la sintaxis de entorno de ese shell. C:\ por sí mismo no es un espacio de trabajo. Los scripts usan las API de rutas de Node; no pegues sintaxis de Bash en PowerShell.

En Linux, usa los mismos nombres de variables de Bash con la ruta de tu unidad de trabajo. Para PowerShell, la configuración equivalente de caché es:

$env:HANDS_ON_HOME = 'D:\WorkshopRuns'
$env:TMP = Join-Path $env:HANDS_ON_HOME '.cache\tmp'
$env:TEMP = $env:TMP
$env:npm_config_cache = Join-Path $env:HANDS_ON_HOME '.cache\npm'
$env:PIP_CACHE_DIR = Join-Path $env:HANDS_ON_HOME '.cache\pip'
$env:UV_CACHE_DIR = Join-Path $env:HANDS_ON_HOME '.cache\uv'
$env:UV_TOOL_DIR = Join-Path $env:HANDS_ON_HOME '.tools\uv'
$env:UV_TOOL_BIN_DIR = Join-Path $env:HANDS_ON_HOME '.tools\bin'
$env:UV_PYTHON_INSTALL_DIR = Join-Path $env:HANDS_ON_HOME '.tools\python'
$env:DOTNET_CLI_HOME = Join-Path $env:HANDS_ON_HOME '.cache\dotnet'
$env:NUGET_PACKAGES = Join-Path $env:HANDS_ON_HOME '.cache\nuget'
$env:PYTHONDONTWRITEBYTECODE = '1'
$env:DOTNET_CLI_TELEMETRY_OPTOUT = '1'
$env:DOTNET_CLI_WORKLOAD_UPDATE_NOTIFY_DISABLE = 'true'
$env:DOTNET_GENERATE_ASPNET_CERTIFICATE = 'false'
New-Item -ItemType Directory -Force -Path $env:TMP,$env:UV_TOOL_BIN_DIR,$env:DOTNET_CLI_HOME,$env:NUGET_PACKAGES

Reemplaza primero la ruta de la unidad y repite las variables en cada nueva terminal. Estos ejemplos describen sintaxis de shell; no afirman que la guía de Windows o Linux se haya ejecutado en el Mac del taller.

[!IMPORTANT] Un worktree aísla los cambios de código fuente, no la CPU, la memoria, la red ni las credenciales. No cambies HOME, no desactives la verificación de certificados, no concedas todos los permisos de herramientas ni instales un servidor MCP para todo el espacio de trabajo para hacer funcionar un laboratorio.

Opciones de entorno de ejecución

Itinerario Entorno de ejecución Motivo
Biblioteca y refactorización de C# SDK de .NET 10; C# Dev Kit si se usan pruebas del editor Los fixtures importados tienen como destino net10.0 tras la integración
Biblioteca y pruebas de Python Un intérprete compatible de Python 3.x; requisitos del fixture pytest es el ejecutor existente, no un nuevo framework de pruebas
Ejemplos de JavaScript/TypeScript Node 24 Ejecutor de pruebas nativo y eliminación de tipos de TypeScript para ejemplos ligeros
Spec Kit Python y uv requeridos por la versión seleccionada de Specify La pila de la aplicación no necesita ser Python
Copilot SDK Entorno de ejecución y paquete indicados por el laboratorio del SDK Las pruebas de aplicación sin conexión y la inferencia autenticada son independientes

Usa la versión exacta y el estado de las herramientas mostrados por tu entorno. Un SDK más reciente no proporciona automáticamente entornos de ejecución anteriores ni garantiza compatibilidad con terceros. Instala dependencias solo para el fixture seleccionado. No compiles todas las copias de la solución de biblioteca a la vez.

Presupuesto de recursos

  • Ejecuta un laboratorio, compilación, ejecutor de pruebas o perfilador a la vez.
  • Para .NET usa -m:1 y -p:UseSharedCompilation=false cuando corresponda.
  • Usa node --test --test-concurrency=1 y pytest normal de un solo proceso.
  • Inicia servidores en la interfaz de bucle local y un puerto sin usar; detenlos con Ctrl+C en su terminal de origen. Nunca termines todos los procesos por nombre.
  • Analiza primero el rendimiento con una entrada pequeña. No generes millones de filas ni ejecutes una prueba de carga en esta máquina compartida.
  • No instales un SDK, navegador, base de datos, entorno de ejecución de contenedores ni paquete global salvo que el ejercicio elegido realmente lo requiera.
  • Mantén los registros pequeños y oculta los identificadores antes de compartirlos.

Registra una línea base

Guarda una nota de evidencia en la copia desechable, no en las fuentes del contenido formativo:

Elemento Registrar
Fixture y entorno de ejecución ID del laboratorio, ruta de origen, versión del entorno de ejecución
Configuración de Copilot Rol, harness/destino, modelo si se muestra, permisos
Comando de referencia Comando exacto y directorio de trabajo
Resultado Código de salida, pruebas descubiertas, salida observable
Cambio Criterio de aceptación y rutas afectadas
Después del cambio Mismas comprobaciones, resultado de regresión, limitaciones

Una compilación exitosa demuestra que se compiló. No demuestra el comportamiento de una función, el descubrimiento de pruebas, la calidad del modelo ni la preservación de datos. Una captura de otra ejecución no demuestra ninguna de esas cosas para tu copia.

Restablece de forma segura

  1. Guarda la evidencia que quieras conservar.
  2. Detén únicamente el servidor o perfilador iniciado para el ejercicio.
  3. Inspecciona git status --short en la copia desechable.
  4. Si restableces un archivo rastreado del ejercicio, restaura ese archivo nombrado desde la línea base; no uses un restablecimiento forzado de todo el repositorio.
  5. Para un nuevo intento, elige un destino nuevo para el script de preparación.
  6. Elimina las copias antiguas mediante tu administrador de archivos solo después de comprobar sus rutas absolutas. Nunca elimines recursivamente el repositorio, la unidad de trabajo ni la raíz de la caché compartida.

Referencias oficiales

Buscar

Búsqueda en español. Las rutas y los ejemplos ejecutables conservan el texto original.