Fluxo de trabalho do desenvolvedor de ponta a ponta

Um fluxo de trabalho moderno de desenvolvimento no Azure conecta o controle de código-fonte, a CI/CD, a infraestrutura de contêineres e a observabilidade em um ciclo interno contínuo, desde o commit do código até uma produção observável. Os principais componentes são: GitHub (código-fonte), GitHub Actions (pipeline de compilação e implantação), Azure Container Registry (armazenamento de imagens), Azure Container Apps (ambiente de execução) e Application Insights (observabilidade). Cada alteração passa automaticamente do computador do desenvolvedor para a produção em poucos minutos, com gates de qualidade em cada etapa.

Organize seu código em um repositório do GitHub usando desenvolvimento baseado em tronco ou uma estratégia de ramificação GitFlow. Para a maioria dos microsserviços, o desenvolvimento baseado em tronco (ramificações de funcionalidades de curta duração mescladas diariamente à main) reduz conflitos de integração e mantém o pipeline simples. Use regras de proteção de ramificação na main para exigir revisões de solicitações de pull e verificações de CI aprovadas antes da mesclagem. Um arquivo CODEOWNERS garante que alterações em serviços críticos exijam a aprovação dos engenheiros seniores da equipe responsável.

O pipeline de CI é executado em cada solicitação de pull. Um fluxo de trabalho típico é: baixar o código → restaurar dependências → executar testes unitários → executar testes de integração → compilar a imagem do Docker → enviar para o Azure Container Registry. A imagem recebe uma etiqueta com o SHA do commit do git para permitir o rastreamento. Use autenticação baseada em OIDC do GitHub Actions para o Azure (por meio de identidade federada) para evitar armazenar segredos de entidades de serviço do Azure no GitHub — um equivalente de identidade gerenciada para pipelines de CI.

Depois que o pipeline de CI é concluído com êxito após uma mesclagem na main, o pipeline de CD implanta automaticamente no ambiente de preparação. O pipeline atualiza a etiqueta da imagem do Container App para o SHA recém-compilado, aguarda a nova revisão ficar íntegra e executa testes de fumaça no URL de preparação. Os testes de fumaça verificam se os pontos de extremidade críticos da API retornam as respostas esperadas. Se os testes de fumaça falharem, o pipeline reverte a alteração direcionando novamente o tráfego de entrada para a revisão anterior, sem nenhuma intervenção manual.

Após a validação no ambiente de preparação, o pipeline de CD pausa em um gate de aprovação. As proteções de ambiente do GitHub Actions permitem configurar revisores obrigatórios para o ambiente de production. O pipeline envia uma notificação do Slack ao engenheiro de plantão, que analisa os resultados dos testes de preparação, as diferenças e quaisquer incidentes em aberto antes de aprovar. Somente após a aprovação o pipeline prossegue para implantar a mesma imagem SHA em produção. Essa etapa com participação humana é essencial para serviços de alto tráfego ou regulamentados.

Depois da implantação em produção, o Application Insights oferece visibilidade em tempo real. O SDK do App Insights (ou a instrumentação automática para ambientes de execução compatíveis) acompanha: taxas de solicitações, taxas de falha e latência (os três sinais dourados), chamadas de dependência (para bancos de dados, Service Bus e outras APIs) e exceções com rastreamentos completos da pilha. O Mapa de Aplicações visualiza como os serviços chamam uns aos outros e destaca quais dependências contribuem mais para falhas ou latência.

Use anotações do Application Insights para marcar eventos de implantação nos gráficos de métricas. Quando uma anotação de versão é criada (por meio da ação azure/appinsights-annotation do GitHub Actions), ela aparece como uma linha vertical em todos os gráficos de métricas do App Insights. Isso torna imediatamente evidente se um aumento de latência ou da taxa de erros está correlacionado com uma implantação recente, reduzindo significativamente o tempo médio para diagnosticar (MTTD) incidentes.

Para os pipelines mais resilientes, implemente a reversão automática. Após a implantação em produção, o pipeline aguarda 10 minutos e consulta o Application Insights para obter a taxa de erros. Se a taxa de erros exceder um limite configurável (por exemplo, >5%), o pipeline reverte automaticamente a alteração, atualizando o tráfego de entrada do Container App para direcionar 100% à revisão anterior. Esse padrão de entrega progressiva reduz o raio de impacto de uma implantação problemática e permite que as equipes implantem com confiança, mesmo no caso de alterações complexas ou sensíveis.

Os desenvolvedores devem poder executar e testar toda a pilha localmente, sem se conectar aos recursos do Azure em produção. Use o Azure Storage Emulator (Azurite) para armazenamento local de blobs e filas, o Cosmos DB Emulator para testes locais de banco de dados e o Service Bus Emulator para mensagens locais. A variável de ambiente AZURE_ENVIRONMENT=local pode alternar o DefaultAzureCredential para usar cadeias de conexão apontando para emuladores, enquanto o mesmo código usa identidade gerenciada no Azure. O Docker Compose orquestra todas as dependências locais em um único comando docker compose up.

Integre a segurança a cada etapa do fluxo de trabalho do desenvolvedor: o Dependabot verifica dependências vulneráveis em solicitações de pull; o GitHub Advanced Security (verificação de código com CodeQL) detecta vulnerabilidades como injeção de SQL e segredos codificados diretamente; o Microsoft Defender for DevOps integra-se ao GitHub para apresentar recomendações de segurança do Azure junto às alterações de código; e a verificação de vulnerabilidades do ACR Defender verifica as imagens de contêiner em busca de CVEs do OS e da camada da aplicação após cada envio. As descobertas de segurança aparecem como comentários nas solicitações de pull, para que sejam corrigidas antes da mesclagem.

O fluxo de trabalho completo do desenvolvedor é um ciclo contínuo de feedback: um desenvolvedor faz commit do código, a CI compila e testa a imagem do contêiner, a imagem é enviada ao ACR com o SHA do commit como etiqueta, a CD implanta no ambiente de preparação e executa testes de fumaça, uma pessoa aprova a implantação em produção, o pipeline implanta em produção e cria uma anotação de versão, e o Application Insights monitora as taxas de erros, com reversão automática se os limites forem ultrapassados. A infraestrutura como código (Bicep ou Terraform) no mesmo repositório garante que o pipeline, o Container App e a configuração de monitoramento sejam todos controlados por versão junto com o código da aplicação.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) abordados nesta lição.

Nesta lição, você aprendeu que o fluxo de trabalho de desenvolvimento de ponta a ponta conecta o controle de código-fonte do GitHub, o CI/CD do GitHub Actions, o Azure Container Registry, o Container Apps e o Application Insights; as anotações de versão correlacionam implantações com alterações nas métricas para diagnosticar incidentes mais rapidamente; e a reversão automática baseada em consultas da taxa de erros reduz o raio de impacto de implantações problemáticas. A seguir, passaremos à preparação para o exame com uma revisão abrangente dos conceitos de nuvem e da arquitetura do Azure.