Ambiente e limites de recursos da trilha prática

Estes exercícios são uma trilha complementar sem fantasia do Awesome Copilot Adventures. Mantêm o formato de exercícios/tarefas do material de aprendizagem importado. Você não precisa concluir as aventuras primeiro.

Para a primeira instalação e a preparação das contas, comece por Pré-requisitos e contas: VS Code/Insiders, Copilot Free e outros planos, a CLI independente e uso opcional de Codespaces ou Azure. As regras de runtime e recursos abaixo continuam valendo para o exercício selecionado.

[!TIP] Começando sem um clone? Use o catálogo de ZIPs do aprendiz. Cada kit inclui uma lição completa, imagens locais, um manifesto de integridade e KIT-START.md com a raiz exata do workspace e a baseline. As instruções abaixo são a alternativa para quem já tem o checkout do currículo.

Trabalhe em uma cópia descartável

1. Comece na raiz de awesome-copilot-adventures.
2. Selecione um laboratório no catálogo. Use o lab_id, não o título exibido.
3. Escolha um diretório absoluto não usado fora deste repositório em uma unidade de trabalho existente. Crie e inspecione primeiro o diretório pai. Os exemplos a seguir usam 02-csharp; substitua o ID do laboratório pela sua escolha. Não instale o .NET se você estiver fazendo um exercício de Node ou Python.

macOS: Bash ou zsh

No Mac do workshop, a unidade T9 é a unidade de trabalho selecionada:

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

Substitua D:\WorkshopRuns por um diretório na sua unidade de trabalho aprovada existente; o exemplo não cria nem pressupõe que uma unidade D: exista.

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

Linux: Bash

Substitua /mnt/work pelo ponto de montagem da sua unidade de trabalho existente antes de executar o exemplo:

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

A preparação copia apenas a fixture nomeada. Ela recusa um destino existente; não instala dependências, não executa código gerado, não inicializa Git nem sobrescreve um projeto.

Continue a partir da cópia preparada

1. Abra o diretório impresso como a única raiz em uma nova janela do VS Code. Um workspace com várias raízes pode herdar instruções do projeto errado.

2. Execute a baseline do laboratório selecionado a partir do diretório de trabalho documentado.

3. Se o laboratório precisar de controle de versão, inicialize apenas essa cópia e faça uma baseline:

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

   Inspecione os arquivos antes de adicioná-los à área de staging. Use uma identidade Git local ao repositório se necessário; não substitua a identidade global da pessoa em aprendizagem. Um repositório GitHub, visibilidade pública e um push não são pré-requisitos de um laboratório local.

Para quem usa Git pela primeira vez, o guia de download e repositório cobre identidade local, revisão de arquivos, o primeiro commit, a criação de um repositório privado vazio no GitHub, adicionar o remoto e fazer push sem force.

Mantenha arquivos temporários e caches na unidade de trabalho

Para Bash/zsh na máquina T9 do workshop, execute isto no terminal que executará o exercício. Um novo terminal precisa das mesmas exportações:

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"

Em outro sistema operacional, escolha uma unidade externa/de projeto equivalente e defina estas variáveis usando a sintaxe de ambiente desse shell. C:\ em si não é um workspace. Os scripts usam as APIs de caminhos do Node; não cole sintaxe Bash no PowerShell.

No Linux, use os mesmos nomes de variáveis do Bash com o caminho da sua unidade de trabalho. Para PowerShell, a configuração equivalente de cache é:

$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

Substitua primeiro o caminho da unidade e repita as variáveis em cada novo terminal. Esses exemplos descrevem sintaxe de shell; eles não afirmam que o passo a passo do Windows ou Linux foi executado no Mac do workshop.

[!IMPORTANT] Uma worktree isola alterações de código-fonte, não CPU, memória, rede ou credenciais. Não altere HOME, desabilite a verificação de certificados, conceda todas as permissões de ferramentas nem instale um servidor MCP para todo o workspace para fazer um laboratório funcionar.

Opções de runtime

Use a versão exata e o status das ferramentas impressos pelo seu ambiente. Um SDK mais novo não fornece automaticamente runtimes mais antigos nem garante compatibilidade com terceiros. Instale dependências somente para a fixture selecionada. Não compile todas as cópias da solução da biblioteca de uma vez.

Orçamento de recursos

• Execute um laboratório, compilação, executor de testes ou profiler por vez.
• Para .NET, use -m:1 e -p:UseSharedCompilation=false quando apropriado.
• Use node --test --test-concurrency=1 e pytest comum com processo único.
• Inicie servidores em loopback e em uma porta não utilizada; pare-os com Ctrl+C no terminal responsável por eles. Nunca encerre processos em massa pelo nome.
• Analise o desempenho de uma entrada pequena primeiro. Não gere milhões de linhas nem execute um teste de carga nesta máquina compartilhada.
• Não instale SDK, navegador, banco de dados, runtime de contêiner ou pacote global, a menos que o exercício escolhido realmente o exija.
• Mantenha os logs pequenos e oculte identificadores antes de compartilhá-los.

Registre uma linha de base

Salve uma nota de evidências na cópia descartável, não nas fontes do currículo:

Uma compilação aprovada comprova a compilação. Não comprova comportamento da funcionalidade, descoberta de testes, qualidade do modelo ou preservação de dados. Uma captura de tela de outra execução não comprova nenhuma dessas coisas para sua cópia.

Restaure com segurança

1. Salve as evidências que deseja manter.
2. Pare somente o servidor/profiler iniciado para o exercício.
3. Inspecione git status --short na cópia descartável.
4. Ao restaurar um arquivo rastreado do exercício, restaure esse arquivo nomeado a partir da linha de base; não use uma redefinição forçada em todo o repositório.
5. Para uma nova tentativa, escolha um novo destino para o script de preparação.
6. Remova cópias antigas pelo gerenciador de arquivos somente depois de conferir seus caminhos absolutos. Nunca exclua recursivamente o repositório, a unidade de trabalho ou a raiz do cache compartilhado.

Referências oficiais

• Configuração do Copilot no VS Code
• Worktrees no VS Code
• Testes Python
• Testes C#
• Variáveis de ambiente da CLI do .NET