Copilot Code Review chega ao Azure Repos com cobrança por revisão e relatório dois dias atrasado

A Microsoft liberou o GitHub Copilot code review para o Azure↳Azure76 conteúdosDeploy de Azure Stream Analytics job com CI/CD usando Azure PipelinesDevSecOps · mai 2019Azure – Como criar uma base de dados SQL no Microsoft Azure pronta para ser utilizadaData · abr 2019Azure Static Web Apps com Vue.js e Visual Studio CodeDevSecOps · out 2023Ver tudo em DevSecOps → Repos a todos os clientes do Azure DevOps, removendo o cadastro que limitava o acesso desde junho, segundo a InfoQ. O recurso posta comentários de revisão em pull requests, cobra por revisão através da assinatura Azure vinculada e reporta o gasto dois dias depois de ele acontecer.

Para quem constrói software em times DevOps no Brasil, isso encerra uma espera antiga: a revisão automática com IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → que já existia no GitHub agora roda sem exigir migração de repositório. Mas o detalhe que decide se vale ligar está no billing e nos limites, não no anúncio.

Por que a Microsoft levou o recurso ao Azure Repos

O anúncio de junho, assinado por Dan Hellem e Andrew Brenner, foi incomumente franco sobre a estratégia. A empresa passou anos empurrando clientes para migrar repositórios do Azure Repos para o GitHub em busca das experiências de IA e desenvolvimento agêntico, e então admitiu o resultado:

Embora muitos clientes estejam ativamente planejando e executando migrações para o GitHub, muitos outros ainda não estão prontos para se mover e continuam dependendo do Azure Repos para o desenvolvimento do dia a dia.

Dan Hellem e Andrew Brenner, Microsoft

A complexidade de migrar varia com tamanho da organização, customizações, exigências de compliance, ferramental e restrições do setor. Em vez de esperar esses times moverem tudo, a Microsoft trouxe a capacidade do GitHub para onde eles já estão. O leitor da fonte resumiu bem o sentimento:

Recursos como esse já estão disponíveis no GitHub há muito tempo. Para muitas empresas é trabalho e risco demais simplesmente migrar para o GitHub. Fico feliz que finalmente estejam chegando ao DevOps.

Marc Selman, comentarista

O movimento não é isolado. O Azure DevOps Remote MCP Server atingiu disponibilidade geral neste mês, dando a assistentes de IA um endpoint hospedado para work items, pull requests, repositórios e pipelines, ainda que Claude, ChatGPT e Cursor não consigam se conectar porque o Entra ainda não tem os mecanismos de registro de cliente que esses clientes exigem. Os dois lançamentos servem à mesma população: times que querem tooling agêntico no Azure DevOps sem mover repositórios.

O que o release de agosto adiciona

A atualização traz controles de onboarding em nível de organização, projeto e repositório, suporte a Managed DevOps Pools, instruções customizadas e revisões automáticas disparadas por branch policies. As instruções customizadas podem valer para toda a organização ou projeto, ser definidas por repositório ou direcionadas a caminhos específicos.

O billing merece leitura atenta

É aqui que o time brasileiro precisa fazer as contas antes de habilitar em escala. Cada revisão concluída consome tokens de entrada, saída e cache, convertidos em créditos de IA do GitHub a um crédito por centavo. Esforço de revisão maior analisa mais contexto e consome mais; tamanho do PR, instruções customizadas e mudança de modelo afetam o total.

As cobranças aparecem no Azure Cost Management sob o produto GitHub Copilot for AzDO, 48 horas depois de a revisão terminar. A atribuição de custo melhorou: agora as cobranças carregam tags de projeto do Azure DevOps, então dá para filtrar ou agrupar o custo por projeto em vez de ver só um total da organização. Como são tags padrão do Azure, funcionam em views de análise, exports e budgets.

Mas a documentação é explícita sobre o limite dos budgets:

Budgets só notificam. Eles não param revisões nem alteram nenhum recurso.

Documentação da Microsoft

Na prática, isso desenha um cenário de risco: um time pode definir um limite e receber um e-mail em até uma hora da próxima avaliação, mas combinado com o atraso de 48h no relatório, uma política de revisão automática aplicada a um projeto movimentado rodaria por dois dias antes de o custo aparecer em qualquer lugar.

Limites de concorrência e infraestrutura

Antes de ligar revisão automática de forma ampla, vale checar os limites de concorrência:

Uma organização com vários times revisando cada novo PR vai enfileirar. O recurso roda sobre a infraestrutura do Azure Pipelines, usando por padrão o agent pool default da organização, que algumas organizações desabilitam. Managed DevOps Pools são suportados e precisam rodar a imagem mais recente do Ubuntu Server; imagens Windows não são suportadas, e a Microsoft desaconselha misturar agentes Ubuntu e Windows no mesmo pool. Agentes self-hosted não são suportados.

É revisão consultiva, não bloqueante

Por design, o Copilot sempre deixa uma revisão do tipo Comment, nunca aprova nem solicita mudanças. Ou seja: o feedback dele não satisfaz políticas de revisor obrigatório e não bloqueia o merge. Ele também não re-revisa após novos commits a menos que seja pedido, e não lê respostas nem faz follow-up. Para quem esperava usar a IA como gate de qualidade automático, a expectativa precisa ser recalibrada: é um segundo par de olhos, não um portão.

Confiabilidade e restrições ainda em aberto

A confiabilidade durante o preview foi irregular. Um cliente relatou que revisões paravam após a fase de execução do plan-tool, ficavam ociosas por cerca de 60 minutos e eram canceladas automaticamente; Hellem confirmou o comportamento como problema conhecido, com correção levando cerca de uma semana para chegar a todas as organizações. Outro não achava a configuração de revisão automática onde a documentação indicava, e Hellem esclareceu que ela fica em nível de branch policy.

A terminologia do preview também segue inconsistente: o post de junho falava em limited public preview rodando um cadastro chamado technical preview; o de agosto chama de public preview sem cadastro; e a documentação ainda carrega banner de limited preview, sem SLA e com suporte limitado.

Há restrições que limitam onde o recurso se aplica:

• Repositórios de 10 GB ou menos
• Pull requests com 100 arquivos alterados ou menos e sem conflitos de merge
• TFVC não é suportado
• Rollout gradual por região, com estimativa de duas a três semanas ou mais para alcançar todas as organizações

O que fazer antes de ativar

A orientação da própria Microsoft é conservadora: habilite o recurso para um ou dois repositórios, compare os níveis de esforço e monitore o uso diário antes de expandir. O caminho que faz sentido para um time DevOps brasileiro é o mesmo: começar por um repositório de baixo volume, acompanhar as tags de custo por projeto no Cost Management e só então avaliar revisão automática por branch policy, sabendo que o custo real só vai aparecer 48h depois. Como o custo de cada revisão escala com o volume de PRs, ligar automático num monorepo movimentado sem esse acompanhamento é a receita para uma surpresa na fatura.

Fonte: InfoQ