O GitHub Actions foi a plataforma de CI/CD do currículo principal desta série — uma escolha natural para projetos que hospedam código no GitHub. Mas no mercado corporativo, especialmente em empresas que já adotaram o ecossistema Microsoft, o Azure DevOps é frequentemente a plataforma consolidada de desenvolvimento de software. Entender o Azure DevOps é, portanto, uma habilidade prática para quem vai trabalhar nesse ambiente.
Este artigo cobre o Azure DevOps de forma completa: o que é cada componente da plataforma, como os pipelines funcionam com YAML, como integrar com o AKS para deploy, e a discussão sobre quando usar Azure DevOps versus manter o GitHub Actions mesmo em projetos Azure.
O Que É o Azure DevOps
O Azure DevOps não é apenas uma ferramenta de CI/CD — é uma plataforma integrada de gestão do ciclo de vida de software que a Microsoft oferece como serviço (azure.microsoft.com/products/devops) ou instalável on-premises (Azure DevOps Server). Ele tem cinco componentes principais.
O Azure Boards é rastreamento de trabalho com Kanban, Scrum e épicos — equivalente ao GitHub Issues + Projects ou ao Jira, com integração nativa com PRs e commits.
O Azure Repos são repositórios Git (ou TFVC legado) — equivalente ao GitHub Repositories, com pull requests, code review e branch policies.
O Azure Pipelines é o CI/CD declarativo em YAML — o coração do Azure DevOps, equivalente ao GitHub Actions mas com conceitos próprios (stages, jobs, tasks).
O Azure Artifacts é o registro de pacotes (npm, NuGet, Maven, PyPI, Docker) — equivalente ao GitHub Packages ou ao AWS CodeArtifact.
O Azure Test Plans é a gestão de testes manuais e exploratórios — sem equivalente direto no GitHub, mais relevante para times com QA dedicado.
A orientação atual da própria Microsoft é usar GitHub Actions para novos projetos que hospedam código no GitHub, e Azure DevOps Pipelines quando há necessidade de integração profunda com Azure Boards, Azure Artifacts, ou quando o código está no Azure Repos. Muitas organizações usam os dois: código no GitHub, rastreamento de trabalho no Azure Boards, pipeline no GitHub Actions conectado ao Azure.
Estrutura de um Pipeline YAML
O pipeline YAML do Azure DevOps usa conceitos similares ao GitHub Actions mas com nomenclatura diferente. O mapeamento é: GitHub Actions usa workflow → job → step; Azure DevOps usa pipeline → stage → job → step (task ou script).
O Azure DevOps adiciona o conceito de stage como agrupamento de jobs que representam fases do processo (Build, Test, Deploy Staging, Deploy Production). Isso que no GitHub Actions exige conventions e dependências explícitas entre jobs, no Azure DevOps é um conceito de primeira classe.
O arquivo azure-pipelines.yml na raiz do repositório é equivalente aos arquivos em .github/workflows/. O trigger define branches e paths que disparam o pipeline — o pr define o gatilho para pull requests. Variáveis globais são declaradas com variables e podem referenciar grupos de variáveis do Azure DevOps Library (equivalente aos Secrets do GitHub). O pool.vmImage equivale ao runs-on do GitHub Actions.
Um stage de Build contém jobs paralelos para testes unitários, lint e análise de segurança. A task PublishTestResults@2 publica os resultados dos testes no painel do Azure DevOps — um recurso que o GitHub Actions não tem nativamente. A task PublishCodeCoverageResults@1 equivale ao upload para Codecov.
O stage de BuildImagem usa a task Docker@2 com command: buildAndPush para fazer build e push para o ACR em uma única operação. O stage de DeployStaging usa o tipo especial deployment (em vez de job), que habilita rastreamento de deploys no Environment. A task AzureCLI@2 é o equivalente ao step com uses: azure/login@v2 seguido de comandos kubectl.
O stage de DeployProducao referencia um Environment configurado no portal com aprovação manual — equivalente aos Environments do GitHub com required reviewers. A estratégia runOnce com os blocos preDeploy, deploy, routeTraffic, postRouteTraffic, on.failure e on.success oferece um controle granular do processo de deploy que o GitHub Actions não tem nativamente.
Templates Reutilizáveis
O recurso mais poderoso dos Azure Pipelines para times com múltiplos repositórios são os templates. Ao contrário dos GitHub Actions reutilizáveis, os templates do Azure DevOps podem ser compostos de maneira muito mais granular: templates de steps individuais, de jobs inteiros ou de stages completos.
Um repositório central de templates é referenciado nos pipelines com o bloco resources.repositories, apontando para o nome da organização, repositório e branch. O template é chamado com template: caminho/arquivo.yml@nomeDoRepositorioRemoto, passando parâmetros tipados. Os parâmetros do template declaram tipo (string, number, boolean), nome e valor padrão — o Terraform YAML valida os tipos em tempo de parse, antes de executar.
Service Connections: Autenticando com Azure Resources
As Service Connections do Azure DevOps são o equivalente dos secrets de credenciais no GitHub Actions, mas gerenciadas centralmente e reutilizáveis em múltiplos projetos e pipelines. Para conectar ao Azure, a recomendação é Workload Identity Federation — sem client secrets com prazo de expiração. A criação pode ser feita pelo portal do Azure DevOps ou via az devops service-endpoint azurerm create com --azure-rm-service-principal-authentication-scheme WorkloadIdentityFederation.
Ambientes e Gates Automáticos
Os Environments do Azure DevOps fornecem controle de aprovação para deploys em ambientes críticos. Mas o Azure DevOps vai além do GitHub Actions: suporta múltiplos aprovadores com lógica (qualquer um aprova vs. todos precisam aprovar), timeouts de aprovação, e gates automáticos.
Gates automáticos permitem que o pipeline verifique condições externas antes de prosseguir — por exemplo, verificar que a taxa de erro em staging está abaixo de 1% antes de permitir o deploy em produção, ou que não há alertas críticos ativos no Azure Monitor. Os gates são configurados no portal do Azure DevOps no painel de Approvals and Checks do Environment, e executam periodicamente até a condição ser satisfeita ou o timeout ser atingido.
O tipo deployment com strategy runOnce oferece os blocos preDeploy (antes do deploy), deploy (o deploy em si), routeTraffic (roteamento de tráfego), postRouteTraffic (verificações pós-roteamento), on.failure (rollback automático) e on.success (notificações). Esse ciclo de vida estruturado é exclusivo do Azure DevOps — no GitHub Actions, toda essa lógica precisa ser implementada manualmente com steps condicionais.
Azure Artifacts: Registro Privado de Pacotes
Times que desenvolvem bibliotecas internas compartilhadas entre múltiplos projetos precisam de um registro privado de pacotes. O Azure Artifacts oferece feeds para npm, NuGet, Maven, PyPI e Universal Packages.
A publicação de um pacote npm no pipeline usa a task npmAuthenticate@0 para configurar o arquivo .npmrc com as credenciais do feed do Azure Artifacts, seguida de npm publish. O arquivo .npmrc do projeto aponta para a URL do feed no formato pkgs.dev.azure.com/organização/projeto/_packaging/feed/npm/registry/. Não é necessário configurar tokens manualmente — a task de autenticação cuida disso usando a Service Connection configurada.
Branch Policies via Terraform
As Branch Policies do Azure Repos são o equivalente às Branch Protection Rules do GitHub. O provider Terraform microsoft/azuredevops permite gerenciá-las como código. As políticas mais comuns são: azurerm_branch_policy_min_reviewers (mínimo de revisores, com opção de impedir que o próprio autor aprove), azurerm_branch_policy_build_validation (exige que um pipeline específico passe antes de mergear) e azurerm_branch_policy_comment_resolution (todos os comentários de revisão devem ser resolvidos antes do merge).
Quando Usar o Quê
A decisão entre GitHub Actions e Azure DevOps raramente é binária em organizações de médio e grande porte. O cenário mais comum é uma combinação.
Código no GitHub + Pipeline no GitHub Actions + Azure como infraestrutura é a combinação mais simples para novos projetos. O GitHub Actions autentica no Azure via Workload Identity Federation e faz deploy para o AKS. Toda a gestão de código e pipeline fica em um único lugar.
Código no Azure Repos + Pipeline no Azure Pipelines + AKS é o padrão em organizações que já adotaram o Azure DevOps como plataforma corporativa, especialmente aquelas com controles de compliance que exigem que o código não saia do ambiente Microsoft.
Código no GitHub + Rastreamento no Azure Boards + Pipeline misto é uma combinação comum em organizações que usam o GitHub pela experiência do desenvolvedor mas mantêm o Azure Boards para gestão de projetos por causa da integração com Power BI e Microsoft Teams.
Com os quatro artigos desta extensão, a transição de AWS para Azure está coberta nos pontos mais importantes: conceitos e equivalências (E1), compute, storage e redes (E2), Kubernetes com AKS (E3) e CI/CD com Azure DevOps (E4). O engenheiro que domina ambas as plataformas tem uma versatilidade de mercado significativa — e percebe, na prática, que os fundamentos são sempre os mesmos: automação, observabilidade, segurança por padrão e infraestrutura como código.
Referências para Aprofundamento
— O Que São os Azure Pipelines: https://learn.microsoft.com/pt-br/azure/devops/pipelines/get-started/what-is-azure-pipelines — Service Connections — Azure DevOps Docs: https://learn.microsoft.com/pt-br/azure/devops/pipelines/library/service-endpoints — Templates de Pipeline — Azure DevOps Docs: https://learn.microsoft.com/pt-br/azure/devops/pipelines/process/templates — Introdução ao Azure Artifacts: https://learn.microsoft.com/pt-br/azure/devops/artifacts/start-using-azure-artifacts — AzureDevOps Provider — Terraform Registry: https://registry.terraform.io/providers/microsoft/azuredevops/latest/docs