Azure DevOps es donde deben aterrizar los casos de prueba generados, y es también el sistema donde una escritura sin revisar hace más daño. La integración está construida en torno a eso: una ruta de lectura que corre libremente, una ruta de escritura que no puede ejecutarse sin que un humano apruebe un diff renderizado, y una credencial que el sandbox de ejecución nunca ve.
Esta es una guía de despliegue para conectar un sistema agéntico a Azure DevOps como sistema de registro del trabajo de verificación. Cubre la división de herramientas, la ruta de autenticación, la puerta de aprobación y las dos operaciones que requieren tratamiento especial.
Del estándar
“Verification and validation (V&V) processes are used to determine whether the development products of a given activity conform to the requirements of that activity and whether the product satisfies its intended use and user needs.”
Divida las herramientas por consecuencia, no por recurso
El instinto es modelar el conector según la superficie de la API: una herramienta por endpoint. La división útil es por lo que ocurre si la llamada está equivocada.
| Clase | Operaciones | Puerta |
|---|---|---|
| lectura | Consultar elementos de trabajo · obtener plan o conjunto de pruebas · listar campos y estados | Solo verificación de política |
| escritura | Crear elemento de trabajo · actualizar elemento · vincular requisito con prueba | Política y puerta humana. Se muestra el diff de impacto antes de confirmar. |
| disparo | Ejecutar canalización | Política y puerta humana, marcado como no idempotente. |
Las lecturas son la gran mayoría de las llamadas y acotarlas haría inutilizable el sistema sin reducir riesgo: una lectura dentro de los permisos que el usuario ya tiene no es aquello para lo que existe la puerta. Las escrituras y los disparos de pipeline son raros y consecuentes, que es justamente la forma que tolera un humano en la ruta.
Autenticación: el token queda fuera del sandbox
Credenciales de cliente OAuth 2.0, con alcance limitado al proyecto y a los tipos de elemento de trabajo que el agente puede tocar. Acótelo con precisión: un token que puede editar cualquier elemento de la organización no le deja nada que acotar al cálculo de radio de impacto.
La credencial nunca se coloca dentro del sandbox de ejecución. La petición saliente abandona el sandbox y el token se adjunta después. Esto importa más aquí que en una integración típica: el código generado por el agente es código que nadie revisó antes de ejecutarse, así que todo lo legible desde dentro de ese sandbox debe considerarse ya divulgado.
La cola de revisión es el producto
Los casos generados no van a Azure DevOps. Van a una cola, donde cada uno se muestra junto al requisito de origen del que proviene y las señales con las que se emparejó. Un revisor aprueba, edita o rechaza. Solo se escribe un caso aprobado.
Filtre antes de la cola, no después
Una verificación de fundamentación corre antes del revisor y rechaza cualquier caso generado que referencie una señal ausente del índice. No es redundante con la revisión humana: la protege. Un revisor al que se le muestra salida mayormente correcta aprende a leer por encima, y cada elemento infundado que llega a la cola degrada la calidad de revisión aplicada a todo lo demás. La atención del revisor es el recurso escaso de todo el sistema.
Dos operaciones que requieren tratamiento especial
Los disparos de pipeline no son idempotentes
La mayoría de operaciones de un conector pueden reintentarse con seguridad tras un timeout. Disparar un build no. Un reintento que asume que la primera llamada falló, cuando en realidad tuvo éxito y se perdió la respuesta, ejecuta el pipeline dos veces; y en un contexto de verificación una ejecución duplicada contra un entorno compartido no es un duplicado inofensivo.
Marque la operación como no idempotente en el manifiesto. El guardián de reintentos entonces bloquea en lugar de reintentar: una lectura que expira se reintenta, una escritura no idempotente que expira se eleva a un humano. Donde la API lo acepte, genere una clave de idempotencia en el momento de la aprobación para que un reintento genuino sea seguro.
Los proyectos de producción necesitan su propia puerta
El mismo conector apuntando a un proyecto de pruebas y a uno de producción no debería comportarse igual. Una anulación a nivel de entorno endurece la política para producción sin importar lo que digan las reglas a nivel de herramienta, de modo que relajar una regla durante el desarrollo no pueda relajarla en todas partes en silencio.
Las aprobaciones caducan frente a un elemento que cambia
Una aprobación se concede contra un estado específico. Entre la aprobación y la ejecución, otra persona puede editar el elemento, una definición de campo puede cambiar o el plan de pruebas puede reestructurarse. Ancle la aprobación a un token de versión y al esquema contra el que se concedió; si cualquiera cambia, rechace la escritura en lugar de aplicarla a un estado que nadie revisó.
Rechazada, no reintentada en silencio contra el nuevo estado. Los elementos de trabajo de Azure DevOps los editan muchas personas, lo que hace este fallo ordinario y no exótico.
Lo que esta forma sacrifica
Rendimiento. Un humano está en la ruta de cada escritura, y ese es un techo que ninguna mejora del modelo eleva. En un contexto de verificación regulado es el techo correcto: el número de escrituras sin revisar en el plan de pruebas es cero por construcción y no por política, porque la capacidad no existe.
Donde los elementos de trabajo son de bajo riesgo y el volumen importa más que la reversibilidad, esto está sobredimensionado y un radio de impacto más estrecho con ejecución desatendida es mejor compromiso. La pregunta a resolver primero no es cuánto confía en el paso de generación. Es qué podría hacer la peor escritura individual antes de que alguien lo notara.
Axionalytics
IA agéntica en producción para equipos empresariales de ingeniería, datos e ingresos.