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.mdcon 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
- Empieza en la raíz de
awesome-copilot-adventures. - Selecciona un laboratorio en el catálogo. Usa su
lab_id, no su título mostrado. - 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
-
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.
-
Ejecuta la baseline del laboratorio seleccionado desde su directorio de trabajo documentado.
-
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:1y-p:UseSharedCompilation=falsecuando corresponda. - Usa
node --test --test-concurrency=1y pytest normal de un solo proceso. - Inicia servidores en la interfaz de bucle local y un puerto sin usar; detenlos con
Ctrl+Cen 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
- Guarda la evidencia que quieras conservar.
- Detén únicamente el servidor o perfilador iniciado para el ejercicio.
- Inspecciona
git status --shorten la copia desechable. - 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.
- Para un nuevo intento, elige un destino nuevo para el script de preparación.
- 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.