Guia

Impor a qualidade do código (build, teste, cobertura) antes de mesclar uma pull request.

→No branch de destino, configure uma política de validação de build que aciona um pipeline na criação da PR. O pipeline deve publicar os resultados da cobertura de código. Defina uma política de branch para cobertura mínima.

Por quê: Isso impõe a qualidade pré-mesclagem. Um gatilho CI padrão é executado pós-mesclagem. Os "release gates" são para implantações, não para PRs.

Selecionar uma estratégia de ramificação Git que minimize conflitos de mesclagem e suporte implantação rápida e contínua em produção.

→Implementar desenvolvimento baseado em "trunk" com branches de recurso de curta duração que são mesclados ao `main` frequentemente (diariamente ou mais).

Por quê: Evita que os branches divirjam significativamente, reduzindo conflitos de mesclagem e garantindo que o branch `main` esteja sempre próximo de um estado liberável.

Proteger um branch crítico (por exemplo, `main`) impondo revisões de código, builds bem-sucedidos e vinculação de itens de trabalho antes das mesclagens.

→Configure Políticas de Branch no branch `main` no Azure Repos. Habilite políticas para um número mínimo de revisores, validação de build e vinculação de itens de trabalho.

Por quê: As políticas de branch fornecem imposição do lado do servidor que não pode ser contornada pelos desenvolvedores, garantindo qualidade consistente e conformidade com o processo.

Selecionar uma estratégia de ramificação Git para uma equipe com lançamentos agendados, desenvolvimento paralelo de recursos e a necessidade de branches de hotfix dedicados.

→Implementar o modelo de ramificação GitFlow, que usa os branches `main`, `develop`, `feature/*`, `release/*` e `hotfix/*`.

Por quê: GitFlow fornece uma estrutura robusta para gerenciar ciclos de lançamento complexos, isolando o novo desenvolvimento da estabilização de lançamento e correções de emergência.

Um segredo foi acidentalmente commitado e enviado. Ele deve ser completamente removido de todo o histórico do Git.

→Primeiro, rotacione o segredo exposto. Em seguida, use uma ferramenta como `git-filter-repo` ou BFG Repo-Cleaner para reescrever o histórico, removendo o arquivo. Faça um force-push das alterações e notifique todos os desenvolvedores para clonarem novamente.

Por quê: Um simples `git rm` ou revert não remove o segredo do histórico. A reescrita do histórico é necessária para uma purga permanente.

Modelar um fluxo de trabalho complexo com estágios paralelos e dependências entre os estágios.

→Use pipelines YAML multi-estágios. Use a palavra-chave `dependsOn` para dependências de estágio e configure jobs paralelos dentro dos estágios.

Por quê: YAML oferece a abordagem mais flexível e baseada em código para orquestração complexa, superior aos pipelines clássicos ou ao encadeamento de pipelines separados.

Implementar implantação sem tempo de inatividade e de baixo risco para um aplicativo web com capacidade de rollback instantâneo.

→Use os slots de implantação do Azure App Service. Implante em um slot de preparação (verde), valide e, em seguida, realize uma troca de slot com a produção (azul).

Por quê: Uma troca de slot é uma operação atômica e quase instantânea que redireciona o tráfego. O rollback é tão simples quanto trocar de volta.

Referência↗

Minimizar a duplicação de pipelines para inúmeros microsserviços que compartilham etapas comuns de build/implantação, mas exigem personalizações específicas.

→Crie modelos YAML em um repositório central. Em cada pipeline específico do serviço, use a palavra-chave `extends` e passe parâmetros para personalização.

Por quê: `extends` promove os princípios DRY e impõe padrões, ao mesmo tempo em que permite flexibilidade através de parâmetros. Mais poderoso do que grupos de tarefas para estruturas de pipeline inteiras.

Restringir um estágio de pipeline (por exemplo, implantação em produção) para ser executado apenas em mesclagens para um branch específico (por exemplo, main).

→Use uma `condition` no estágio ou job. Por exemplo, `condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`.

Por quê: Os builds de validação de PR usam uma referência de branch de origem diferente (por exemplo, `refs/pull/...`), então esta condição impede corretamente a implantação durante o ciclo de vida da PR.

Implantar aplicativos do Azure DevOps em servidores on-premises atrás de um firewall corporativo.

→Instale agentes self-hosted nos servidores on-premises. Registre-os em um pool de agentes no Azure DevOps.

Por quê: Agentes self-hosted iniciam comunicação de saída com o Azure DevOps, portanto, não são necessárias regras de firewall de entrada. Eles podem acessar recursos de rede local para implantação.

Exigir aprovação de várias pessoas para implantações em produção e restringi-las a janelas de manutenção específicas.

→Defina um Ambiente do Azure DevOps para produção. Configure aprovações com aprovadores necessários. Adicione uma verificação de "Horário Comercial" como um "gate" para impor a janela de tempo.

Por quê: Ambientes centralizam os controles de implantação. Aprovações e "gates" fornecem aplicação de políticas robusta e automatizada antes que um estágio seja executado.

Controlar a exposição de recursos aos usuários sem reimplantar o aplicativo, com atualizações em tempo quase real.

→Use o Azure App Configuration para gerenciamento de recursos. Instrumente o aplicativo para ler "flags" e habilite suas capacidades de atualização dinâmica.

Por quê: Desacopla os lançamentos de recursos das implantações. O App Configuration fornece uma UI centralizada e SDKs para atualizações dinâmicas, evitando reinícios do aplicativo.

Gerenciar o estado do cluster Kubernetes de forma declarativa, onde o Git é a única fonte da verdade e as alterações são aplicadas automaticamente.

→Implante um agente GitOps como Flux ou ArgoCD no cluster AKS. Configure o agente para monitorar um repositório Git contendo manifestos Kubernetes e sincronizar automaticamente o estado do cluster.

Por quê: Este modelo baseado em "pull" permite reconciliação contínua e detecção de desvios, que é essencial para GitOps. É mais robusto do que os pipelines `kubectl` baseados em "push".

Gerenciar o estado do Terraform para colaboração em equipe, garantindo segurança e prevenindo modificações concorrentes.

→Configure o backend do Terraform para usar uma Azure Storage Account. Isso fornece armazenamento de estado remoto, com o bloqueio de estado tratado via "lease" de Azure Blob.

Por quê: Evita a corrupção do arquivo de estado por operações `apply` simultâneas e mantém dados de estado sensíveis fora do controle de código-fonte.

Referência↗

Em um monorepo, acionar o pipeline CI de um aplicativo somente quando arquivos em seu diretório específico (ou um diretório compartilhado) forem alterados.

→No YAML do pipeline, use o filtro `trigger.paths.include` para especificar os diretórios relevantes, por exemplo, `include: ['/apps/frontend/**', '/apps/shared/**']`.

Por quê: Isso evita builds desnecessários para alterações de código não relacionadas, economizando tempo de CI e recursos de computação.

Otimizar um estágio de teste com testes rápidos (unitários) e lentos (de integração) para um feedback mais rápido.

→Execute testes unitários e testes de integração em jobs paralelos dentro do mesmo estágio.

Por quê: A execução paralela fornece resultados de testes unitários muito mais rapidamente enquanto testes mais lentos são executados simultaneamente. A duração total do estágio é determinada pelo job mais longo, não pela soma.

Versionar automaticamente um pacote de biblioteca com base no histórico de commits para comunicar claramente o impacto das alterações (quebra, recurso, correção).

→Integre uma ferramenta como GitVersion ao pipeline de CI. Ela analisa mensagens de commit, branches e tags para calcular automaticamente uma versão SemVer (Major.Minor.Patch).

Por quê: SemVer fornece versionamento significativo em que os consumidores podem confiar para gerenciamento de dependências, ao contrário de números de build ou hashes de commit.

Implantar um aplicativo em várias regiões geográficas, uma a uma, com validação após cada implantação regional.

→Use um pipeline YAML multi-estágios com estágios sequenciais, um para cada região, usando `dependsOn` para impor a ordem. Use "environment gates" entre os estágios para validação.

Por quê: Este modelo de implantação baseado em anel contém o raio de impacto de uma implantação ruim para uma única região, permitindo o rollback antes de impactar todos os usuários.

Configurar um pipeline para suportar um modelo de desenvolvimento baseado em "trunk", garantindo que o branch principal seja sempre implantável.

→Configure um gatilho CI no branch `main`. Imponha PRs com uma política de validação de build que execute testes rápidos e abrangentes. Integre notificações rápidas (por exemplo, para Teams/Slack) para falhas de build.

Por quê: O feedback imediato é crítico no desenvolvimento baseado em "trunk". Esta combinação evita que código quebrado seja mesclado e garante uma rápida remediação quando ocorrem problemas.

Passar artefatos grandes (por exemplo, modelos de ML, >5GB) entre os estágios do pipeline de forma eficiente.

→Carregue o artefato grande para o Azure Blob Storage no estágio produtor. Passe o URI do blob para o estágio consumidor como uma variável de saída.

Por quê: O Azure Blob Storage é mais econômico e performático do que os artefatos de pipeline integrados para arquivos de vários gigabytes.

Reduzir os tempos de build, evitando o download repetido de dependências (por exemplo, NuGet, npm) a cada execução.

→Use a tarefa `Cache@2`. Defina uma chave baseada no arquivo de bloqueio do pacote (por exemplo, `packages.lock.json`). A tarefa armazenará e restaurará a pasta de dependências.

Por quê: Pode economizar vários minutos por build, restaurando de um cache local rápido em vez de buscar de repositórios externos.

Compilar ou implantar o mesmo código em vários alvos (por exemplo, diferentes sistemas operacionais, regiões) em paralelo.

→Use uma `strategy: matrix` no job do pipeline YAML. Defina variáveis para cada combinação, o que gerará um job para cada entrada da matriz.

Por quê: Uma estratégia de matriz mantém a definição do pipeline DRY, criando múltiplas variações de job a partir de uma única definição e executando-as em paralelo.

Implementar uma implantação canary no AKS que automaticamente alterna o tráfego e promove ou reverte com base em métricas em tempo real.

→Use um controlador de entrega progressiva como Flagger, integrado com uma "service mesh" (por exemplo, Istio) e um provedor de métricas (por exemplo, Prometheus).

Por quê: Flagger automatiza todo o processo de análise canary, fornecendo entrega progressiva mais segura e confiável do que scripts manuais.

Um pipeline de aplicativo precisa ser acionado quando o código é alterado em seu próprio repositório OU em um repositório de biblioteca compartilhado separado.

→No YAML do aplicativo, defina a biblioteca compartilhada em `resources.repositories` e configure um bloco `trigger` nesse recurso.

Por quê: Cria uma dependência declarativa entre repositórios, garantindo que o aplicativo seja sempre reconstruído com os componentes compartilhados mais recentes.

Um pipeline precisa criar infraestrutura temporária para teste e garantir que ela seja destruída depois, mesmo que os testes falhem.

→Use um pipeline multi-estágios com estágios separados de "apply" e "destroy" para IaC (Terraform/Bicep). Configure o estágio de "destroy" com `condition: always()`

Por quê: A condição `always()` garante que o estágio de limpeza seja executado independentemente do sucesso ou falha dos estágios anteriores, evitando recursos órfãos.

Impedir que uma implantação em produção prossiga, a menos que haja uma solicitação de mudança aprovada em uma ferramenta ITSM como ServiceNow.

→Configure um "Environment gate" que invoca o "Query ServiceNow" gate para verificar o status da solicitação de mudança.

Por quê: Automatiza a integração com processos de gerenciamento de mudanças corporativas, garantindo conformidade sem transferências manuais.

Fornecer um pool de agentes de build self-hosted que escala dinamicamente com a demanda para reduzir tempos de fila e controlar custos.

→Configure um pool de agentes do Azure DevOps usando um Azure Virtual Machine Scale Set (VMSS), configurado para escalar automaticamente com base no número de jobs pendentes.

Por quê: Agentes VMSS combinam a personalização de agentes self-hosted com a elasticidade de agentes hospedados na nuvem, otimizando desempenho e custo.

Implantar alterações de esquema de banco de dados de forma a prevenir perda de dados e suportar rollbacks.

→Use uma ferramenta de migração (por exemplo, Flyway, DbUp). Implemente o padrão "expand/contract" para alterações de esquema para manter a compatibilidade com versões anteriores.

Por quê: Ferramentas de migração fornecem versionamento e controle. O padrão "expand/contract" desacopla rollbacks de aplicação e banco de dados, permitindo implantações mais seguras.

Agentes self-hosted estão ficando sem espaço em disco devido a artefatos de build acumulados.

→No YAML do pipeline, no nível do job, configure `workspace: clean: all`.

Por quê: Esta configuração preventiva de pipeline resolve a causa raiz sem exigir intervenção manual ou mudanças contínuas na infraestrutura.

Testes de integração exigem uma instância de banco de dados isolada para cada execução do pipeline.

→Defina um recurso de contêiner (por exemplo, SQL Server, Postgres) como um serviço no YAML do pipeline. O job de teste pode então se conectar a este serviço efêmero.

Por quê: Fornece dependências rápidas, isoladas e automaticamente limpas para testes, prevenindo interferência de teste e simplificando a configuração.

Melhorar a confiabilidade e o desempenho da restauração de pacotes de repositórios públicos (por exemplo, npmjs, nuget.org).

→No Azure Artifacts, crie um feed e configure fontes upstream apontando para os repositórios públicos. Faça com que os clientes consumam pacotes do feed do Azure Artifacts.

Por quê: O feed armazena em cache pacotes de fontes upstream, protegendo contra interrupções de repositórios públicos e acelerando as restaurações para pacotes frequentemente usados.

Implantar um Helm chart em múltiplos ambientes (dev, prod) com diferentes valores de configuração.

→Use arquivos `values-<env>.yaml` separados para cada ambiente. Na tarefa `HelmDeploy`, use a entrada `valueFile` para especificar o arquivo apropriado e `overrideValues` para injetar valores dinâmicos como tags de imagem.

Por quê: Este padrão separa a configuração estática do ambiente de variáveis dinâmicas de pipeline, mantendo as implantações limpas e de fácil manutenção.

Gerenciar e consumir segredos (por exemplo, strings de conexão) de forma segura em pipelines sem codificá-los diretamente.

→Armazene segredos no Azure Key Vault. No Azure DevOps, crie um Grupo de Variáveis vinculado ao Key Vault. Referencie os segredos do grupo de variáveis no pipeline.

Por quê: Centraliza o gerenciamento de segredos, permite a rotação sem alterações no pipeline e fornece controle de acesso e auditoria robustos através do Key Vault.

Implementar varredura de segurança no pipeline de CI para detectar vulnerabilidades no código do aplicativo (SAST) e dependências de terceiros (SCA).

→Integre a extensão Microsoft Security DevOps, que inclui vários scanners. Considere também o GitHub Advanced Security para Azure DevOps para um conjunto nativo e abrangente.

Por quê: Esta abordagem de "shift-left" identifica vulnerabilidades precocemente no ciclo de vida de desenvolvimento, reduzindo custos e riscos.

Restringir o acesso de desenvolvedores a ambientes de produção para prevenir alterações diretas, ao mesmo tempo em que permite acesso de emergência auditado.

→Remova as funções permanentes de Colaborador/Proprietário. Use Conexões de Serviço de pipeline para implantações. Para emergências, use o Azure AD Privileged Identity Management (PIM) para acesso elevado Just-In-Time (JIT).

Por quê: O PIM fornece acesso elevado com limite de tempo, com aprovação e totalmente auditado, aderindo ao princípio do menor privilégio.

Fornecer segredos para microsserviços no AKS de forma segura, com rotação automática e acesso específico da carga de trabalho.

→Use o Azure Key Vault integrado com o Secrets Store CSI Driver para AKS. Use identidade de carga de trabalho para pods autenticarem-se no Key Vault.

Por quê: Monta segredos diretamente nos pods do Key Vault, evitando Kubernetes Secrets. Habilita identidade no nível do pod e rotação de segredos sem interrupções.

Referência↗

Impor que apenas imagens de contêiner verificadas e assinadas possam ser implantadas em um cluster Kubernetes de produção.

→Use a confiança de conteúdo do Azure Container Registry (ACR) para assinatura de imagem. Use o Microsoft Defender for Containers para varredura. Use o Azure Policy para Kubernetes para impor políticas no AKS.

Por quê: Fornece uma estratégia abrangente, orientada por políticas e de defesa em profundidade para segurança de imagens de contêiner, desde o build até o tempo de execução.

Conectar Azure Pipelines a recursos do Azure sem usar segredos de cliente ou certificados.

→Crie uma conexão de serviço do Azure Resource Manager usando "Workload Identity Federation".

Por quê: Elimina a necessidade de gerenciar e rotacionar segredos, melhorando a postura de segurança do sistema CI/CD.

Implantar em uma assinatura Azure de um cliente a partir da sua organização Azure DevOps sem trocar segredos.

→Implante um agente self-hosted dentro do ambiente Azure do cliente. Atribua uma Managed Identity à VM/VMSS do agente e conceda a ela os papéis RBAC necessários.

Por quê: Mantém todos os principais de autenticação dentro do "tenant" do cliente, aderindo a um modelo de confiança zero. Nenhum segredo cruza os limites do "tenant".

Gerenciar o trabalho de várias equipes em um grande produto, permitindo autonomia da equipe enquanto fornece visibilidade entre equipes para a liderança.

→Use um único Projeto com "Area Paths" para cada equipe para fornecer-lhes backlogs filtrados. Use "Delivery Plans" para visualizar o progresso e as dependências entre as equipes.

Por quê: Permite relatórios agregados e rastreamento de dependências, ao mesmo tempo em que permite que cada equipe gerencie seus próprios sprints e itens de trabalho independentemente.

Vincular automaticamente commits/PRs a itens de trabalho e fazer a transição do estado do item de trabalho (por exemplo, para "Resolvido") após a mesclagem da PR.

→Nas Configurações do Projeto, habilite "Completar automaticamente itens de trabalho com pull requests". Os desenvolvedores devem usar `#<ID>` nas mensagens de commit ou vincular PRs.

Por quê: Reduz a sobrecarga manual para os desenvolvedores, mantém o status dos itens de trabalho atualizado e melhora a rastreabilidade entre código e requisitos.

Medir métricas chave de processo como Cycle Time, Lead Time e métricas DORA para análise do fluxo de valor.

→Use o serviço Azure DevOps Analytics e seu feed OData. Conecte o Power BI ou use widgets de dashboard integrados para visualizar essas métricas.

Por quê: O serviço Analytics fornece os dados subjacentes para métricas chave de fluxo e SRE, permitindo a melhoria de processos orientada por dados.

Investigar tempos de resposta lentos intermitentes que são ocultados pelas métricas de desempenho médias.

→No Application Insights, use a guia Desempenho com análise percentil (P95, P99) e a Pesquisa de Transações para investigar amostras específicas de solicitações lentas.

Por quê: As médias podem ser enganosas. Os percentis revelam a "cauda longa" dos problemas de desempenho, que frequentemente representam os usuários mais frustrados.

Rastrear uma única solicitação de usuário enquanto ela viaja por vários microsserviços para identificar gargalos ou pontos de falha.

→Instrumente todos os serviços com o SDK do Application Insights. Ele propaga automaticamente um ID de correlação de W3C Trace Context entre as chamadas de serviço.

Por quê: Fornece uma visão unificada de uma transação distribuída no Mapa de Aplicativos, tornando possível depurar interações complexas.

Monitorar proativamente o Objetivo de Nível de Serviço (SLO) de um aplicativo e ser alertado *antes* que o SLO seja violado.

→Defina SLIs usando consultas KQL no Azure Monitor. Crie uma regra de alerta que seja acionada com base na taxa de consumo do orçamento de erro (quão rápido o orçamento está sendo consumido).

Por quê: Alertas de taxa de consumo são preditivos, fornecendo tempo para reagir antes que um SLO seja violado e os usuários sejam significativamente impactados.

Validar se uma implantação foi funcionalmente bem-sucedida da perspectiva do usuário, não apenas que as tarefas do pipeline foram concluídas.

→Como uma etapa pós-implantação ou "release gate", execute testes de disponibilidade do Application Insights (monitoramento sintético) que simulam fluxos chave do usuário.

Por quê: O sucesso do pipeline indica apenas que os bits foram movidos. Testes sintéticos confirmam que o aplicativo está realmente funcionando, capturando configurações incorretas ou falhas de dependência.

Correlacionar visualmente eventos de implantação com mudanças no desempenho do aplicativo e métricas de taxa de erro.

→Use a tarefa do Azure Pipelines para criar "Release Annotations" no Application Insights, que coloca um marcador em gráficos de métricas.

Por quê: Fornece feedback visual imediato para identificar rapidamente se uma implantação recente introduziu uma regressão de desempenho ou um bug.

Testar proativamente a resiliência de aplicativos e infraestrutura a falhas de maneira controlada.

→Integre o Azure Chaos Studio em pipelines de release. Crie experimentos que injetam falhas (por exemplo, desligamento de VM, latência de rede) e validam o comportamento do sistema.

Por quê: Vai além de testar o comportamento esperado para testar falhas inesperadas, construindo confiança na resiliência do sistema.