Azure Repos: así bloquea un merge un revisor de IA

En pocas palabras: Un revisor de IA bloquea un merge en Azure Repos solo si existe una política de rama con un status check requerido cuyo genre y name coincidan con el estado que ese servicio postea vía la PR Status API; comentarios y votos no afectan el botón Complete.

En Azure Repos, un revisor de IA solo bloquea un merge si existe una política de rama que exige un status check cuyo género y nombre coincidan con el que ese servicio postea. Los comentarios y los votos del reviewer no tocan el botón Complete, según documenta el análisis de Emil Reiter sobre merge gating en Azure Repos.

Las políticas de rama de Azure Repos son reglas que el repositorio aplica antes de permitir completar un pull request: revisores mínimos, builds de validación, enlace a work items y checks de estado externos. La política de status check es la pieza que conecta un revisor de IA con el bloqueo real, a través de la PR Status API de Azure DevOps. Sin una política requerida, el estado que postea un servicio queda en modo informativo y el merge sigue disponible. Lo que cambia todo acá no es cuánta inteligencia tenga el reviewer, sino un detalle de configuración que casi nadie revisa dos veces.

¿Por qué los comentarios y votos de un revisor de IA no bloquean el merge en Azure Repos?

Porque el botón Complete depende de las políticas de rama de Azure Repos, no de lo que opine el reviewer dentro de su propia lógica. Un comentario, un voto de aprobación o incluso un “Request changes” interno del servicio no mueven ninguna aguja si esa política no existe. El mecanismo real es la combinación de la PR Status API y una política de status check requerida, y vive en la configuración de la rama, no en los ajustes del reviewer.

Ponele que instalás un revisor de IA, lo conectás al repo, y empieza a comentar en cada pull request con sugerencias bastante acertadas (algunas, al menos). Vos das por sentado que si marca un problema grave, el merge queda frenado.

No es así.

Si esa integración no postea un status contra la PR Status API y no hay una política requerida esperando ese status exacto, el equipo puede mergear igual, con el problema grave adentro del código y el reviewer gritando en los comentarios sin que nadie lo escuche técnicamente. El botón no sabe que el reviewer existe. La distinción separa dos categorías de herramientas: las que son un gate real y las que son un comentarista avanzado con buena memoria para patrones de código.

¿Qué hace la política de status check y cómo se configura paso a paso?

La política de status check en las políticas de rama de Azure Repos conecta un servicio externo con el pull request a través de cuatro campos configurables: requisito, identidad autorizada, condiciones de reset y aplicabilidad. Se configura desde Branch policies, sección Status checks, y cada campo decide una parte distinta del comportamiento de bloqueo.

• Policy requirement: optional o required. Solo required bloquea el Complete; optional muestra el status en el PR sin frenar nada, útil para correr el reviewer en modo observación antes de confiarle el gate.
• Authorized identity: restringe qué cuenta puede satisfacer el check. Dejarlo abierto significa que cualquier identidad con permiso de Contribute to pull requests puede postear ese status, un agujero real en organizaciones grandes con integraciones acumuladas.
• Reset conditions: decide si un status posteado sigue valiendo cuando cambia la rama origen. Sin reset en cada push, la aprobación de una revisión vieja deja el gate abierto para código que el reviewer nunca llegó a leer.
• Policy applicability: apply by default aplica desde la creación del PR (se exceptúa posteando notApplicable); conditional espera el primer status posteado para activarse, lo que sirve para orquestar un check que decide qué otros checks aplican.

Hay un detalle que complica el primer setup: el dropdown de status solo lista genre y name de servicios que ya postearon al menos un status contra algún PR. Si la integración es nueva, directamente no aparece en la lista y hay que tipear genre/name a mano. Hasta que el servicio postea por primera vez, la política muestra notSet. Esto se conecta con lo que analizamos en conectarte por SSH a tu VM de Azure.

¿Qué significan los estados succeeded, failed, pending, notApplicable y notSet en la tabla de Azure DevOps?

Azure DevOps define seis estados posibles para un status check, y el comportamiento cambia según la política sea requerida u opcional: succeeded desbloquea, failed y error bloquean el merge, pending y notSet bloquean a la espera de resultado, y notApplicable exceptúa el PR sin tocar la política de fondo.

Estado	Con política requerida	Con política opcional
succeeded	Desbloquea la política	Informativo
failed	Bloquea el merge	Informativo
error	Bloquea el merge	Informativo
pending	Bloquea, a la espera del resultado	Informativo
notApplicable	Exceptúa el requisito de la política	Informativo
notSet	Se trata como pending	Informativo

notApplicable es la forma documentada de exceptuar un PR puntual sin editar la política entera, pensada para casos como un cambio que es solo documentación. notSet es la trampa silenciosa: si el servicio crea la política pero nunca llega a postear nada, el PR queda bloqueado para siempre y no hay ningún mensaje de error que lo explique. Nada avisa. El pull request simplemente no avanza, y en un primer rollout eso se confunde fácil con “el reviewer está tardando”.

Vale la pena notar algo que las fuentes dejan entrever pero no dicen con esas palabras: el diseño de notSet como pending no es un descuido, es una decisión de seguridad por defecto. Si el sistema tratara “sin estado” como “aprobado”, cualquier integración rota abriría el gate en lugar de cerrarlo. El costo de ese diseño conservador es que el error se manifiesta como silencio —un PR trabado— en vez de un mensaje claro, y ese silencio es justamente lo que un equipo tiene que aprender a leer antes de depender del mecanismo.

¿Por qué la política de Copilot code review en Azure Repos no es un merge gate?

Porque “Automatically request Copilot code review” solo agrega a Copilot como reviewer del pull request, sin postear ningún status check. Microsoft no documenta ninguna ruta para que Copilot code review bloquee un merge en Azure Repos, y ninguno de los checks nativos de la referencia de estados pertenece a esta función. La política cambia quién revisa, el gate sigue donde estaba.

El habilitado corre en tres escalas distintas, algo que conviene planificar antes de activarlo en un equipo grande: Cubrimos ese tema en detalle en certificaciones de Azure organizadas por rol.

• Organización: un Project Collection Administrator la habilita a nivel organización.
• Proyecto: un Project Administrator puede escoparla por proyecto, con nivel de effort configurable (más effort, más tokens consumidos).
• Repositorio: el owner del repo la habilita puntualmente, siempre que la configuración del proyecto permita overrides.

El billing corre por una suscripción de Azure vinculada a la organización y Azure Cost Management, un camino de facturación distinto a un plan por asiento. La función está en preview limitado, sin SLA, y Microsoft avisa que puede cambiar o desaparecer. ¿Tiene algún sentido confiarle el gate a algo así todavía? Mejor no. Y en Azure DevOps Server la función ni existe: la documentación está acotada a Azure DevOps Services.

¿Qué documentan CodeRabbit, Qodo y Kodus sobre el bloqueo de merges en Azure Repos?

Los tres vendors documentan mecanismos de revisión distintos, pero en ningún caso el bloqueo nace del lado del reviewer: siempre depende de si esa herramienta termina posteando un status que una política requerida de Azure Repos esté esperando.

Herramienta	Ruta en Azure Repos	Qué dice su documentación sobre bloqueo
CodeRabbit	PAT o service principal de Entra, más webhook de Service Hooks	Pre-Merge Checks en warning por defecto; error solo bloquea combinado con Request Changes
Qodo	Conexión por portal; deployment matrix marca Azure DevOps Cloud sin soporte on-prem	Hallazgos por debajo del umbral quedan advisory en el resumen, no bloquean
Kodus	Webhook con token firmado AES-256-CBC, una suscripción por tipo de evento	Request Changes es opcional; el cookbook de compliance recomienda activarlo para bloquear

Kodus exige un parámetro token cifrado en la URL del webhook, generado a partir de CODE_MANAGEMENT_WEBHOOK_TOKEN y CODE_MANAGEMENT_SECRET con AES-256-CBC, y devuelve 403 si falta. Cada tipo de evento necesita su propia suscripción de Service Hooks: crear solo la de pull request created y no la de updated significa que los pushes posteriores no disparan una nueva revisión, sin ningún aviso en la interfaz que lo señale.

CodeRabbit, por su parte, documenta que el permiso Edit Subscriptions sobre Service Hooks no se puede otorgar desde la UI y hay que concederlo por proyecto, trabajo real en una organización grande. Qodo on-premises apunta a Azure DevOps Services según su propia guía, no a Azure Repos autoalojado. Lo explicamos a fondo en el incidente de repos de GitHub comprometidos.

El patrón que se repite en los tres casos (y que conviene tener presente al leer cualquier documentación de un cuarto vendor) es que el default de fábrica rara vez es el modo bloqueante. Tiene sentido desde el lado del vendor: nadie quiere que su producto frene merges el primer día de prueba y genere el reclamo de “esto me rompió el flujo”. El costo de ese diseño lo paga el equipo que asume que “instalar” equivale a “bloquear”.

Criterios de decisión: ¿cuándo conviene optional y cuándo required?

No hay una respuesta única, pero las fuentes permiten armar un criterio razonable según el momento del rollout y el tipo de cambio que protege la rama. Estos no son hechos documentados por los vendors, sino una lectura propia de cómo combinar lo que sí está documentado.

• Primeras dos o tres semanas de un reviewer nuevo: optional. El objetivo en esta etapa no es bloquear, es aprender qué tasa de falsos positivos tiene la herramienta sobre el código real del equipo. Bloquear desde el día uno con una herramienta todavía no calibrada tiende a generar la reacción contraria: deshabilitarla por “frenar todo”.
• Rama de producción o release, una vez calibrado el reviewer: required, con authorized identity fijada al service account del reviewer y reset activado en cada push. Acá el costo de un falso negativo (un bug que entra) suele pesar más que el costo de un falso positivo (un PR que espera un poco más).
• Ramas de feature o de corta vida: el caso más discutible. Una política required agrega fricción en cada PR chico; optional deja pasar cambios sin revisión efectiva. Una posición intermedia, razonable según lo que documenta Azure DevOps sobre applicability condicional, es usar conditional: que un check liviano decida si corresponde exigir la revisión completa o no, según el tamaño o el tipo de archivo tocado.
• Cambios que el reviewer no puede evaluar bien (configuración generada, vendoring, archivos binarios): ahí notApplicable documentado tiene sentido real, en vez de forzar un status que de todos modos no refleja nada útil.

El hilo común entre estos cuatro casos es que la decisión no depende de “qué tan bueno” es el reviewer marcando problemas, sino de qué tan caro sale cada tipo de error en esa rama puntual. Esa pregunta no la responde la documentación de ningún vendor, porque depende del equipo que la lee.

¿Qué pasos verificar antes de confiar en un revisor de IA como merge gate?

Antes de tratar a cualquier revisor de IA como un gate real, hay un checklist mínimo que conviene correr una sola vez y documentar, porque después nadie se acuerda por qué el PR quedó trabado tres semanas.

• Confirmar que el servicio postea un status a través de la PR Status API, no solo comentarios.
• Anotar el genre/name exacto que usa, porque el dropdown no lo va a mostrar hasta que postee por primera vez.
• Crear una política requerida con esos valores exactos, no una aproximación.
• Fijar authorized identity al service account o service principal del reviewer, no dejarlo abierto a cualquier cuenta.
• Pushear un commit después de una review aprobada y confirmar que el status resetea. Si queda verde después de un cambio nuevo, está aprobando código que nadie leyó.

Eso sí: en pull requests con más de 100.000 archivos modificados, Azure Repos no crea nuevas iterations, así que el check cae a nivel de pull request completo y postear contra una iteration inexistente devuelve error. Es un caso de borde hasta que un agente abre un refactor que toca medio repositorio, y ahí deja de serlo.

Errores comunes al configurar merge gating con revisores de IA en Azure Repos

• Confundir “optional” con bloqueo real: la política opcional muestra el status en el PR, pero jamás frena el Complete. Si querés gate real, tiene que ser required.
• No fijar authorized identity: dejarlo abierto permite que cualquier cuenta con permiso de Contribute to pull requests satisfaga el check, lo que anula el propósito de pinear la fuente del status.
• No configurar reset on new changes: sin esa condición, un push nuevo mantiene vigente una aprobación sobre código viejo que el reviewer nunca vio.
• Asumir que Copilot code review bloquea como en otros forges: en Azure Repos agrega un reviewer, nada más. El gate sigue siendo la política de status check o la de revisores mínimos.

Preguntas Frecuentes

¿Cómo puede un revisor de IA bloquear un merge en Azure Repos?

Solo si postea un status a través de la PR Status API y existe una política de rama requerida que coincida en genre y name con ese status. Los comentarios o votos propios del reviewer no afectan el botón Complete.

¿Qué diferencia hay entre una política opcional y una requerida en Azure DevOps?

La política requerida bloquea el merge mientras el status no sea succeeded; la opcional muestra el mismo status en la sección de Policies del PR, pero nunca impide completarlo. La opcional sirve para correr un reviewer en modo observación antes de confiarle el gate. Relacionado: comparativa completa entre Microsoft y GitHub.

¿Copilot code review bloquea el merge en Azure Repos?

No. La política “Automatically request Copilot code review” solo agrega a Copilot como reviewer del pull request. Microsoft no documenta ninguna ruta para que postee un status check, así que el gate sigue siendo una política de status check o de revisores mínimos.

¿Qué significa el estado notSet en una política de status check?

notSet aparece cuando la política existe pero el servicio todavía no posteó ningún status, y Azure DevOps lo trata igual que pending. Con una política requerida, eso bloquea el merge sin generar ningún error visible.

¿Cómo evito que una política de status check deje el PR bloqueado para siempre?

Confirmando antes de activar la política que el servicio efectivamente postea un status contra la PR Status API, con el genre y name exactos que vas a usar en la política. Si el servicio nunca llega a postear, cualquier PR afectado queda en notSet, tratado como pending, de forma indefinida.

Conclusión

El punto central es simple de enunciar y fácil de pasar por alto en la práctica: en Azure Repos, un revisor de IA es advisory o es gate según exista o no una política de status check requerida que coincida con lo que ese servicio postea. Ni CodeRabbit, ni Qodo, ni Kodus, ni Copilot code review cambian esa regla por sí solos; todos dependen de la misma política de rama para convertirse en un bloqueo real. Si tu equipo está evaluando un reviewer de IA para Azure Repos, el trabajo de verificación no es opcional: hay que confirmar qué postea, con qué nombre, y probar que un commit nuevo resetea el estado antes de asumir que el gate funciona. Y si todavía no sabés si tu política está en optional o required, probablemente esa sea la primera cosa para revisar hoy, no después del próximo incidente.

Fuentes

• Azure Repos merge gating for AI reviewers: the status check policy – análisis de Emil Reiter
• Set and manage branch policies – documentación oficial de Azure Repos
• Statuses – REST API de Azure DevOps Git