Documentación

Cómo Coroid verifica su propio trabajo

Por qué un pull request de Coroid llega ya verificado y qué demuestra cada capa de validación.

Un pull request de Coroid ya ha pasado por la validación antes de que lo veas. Esta sección explica qué significa y cómo configurarlo.

Las capas

La validación no es un único proceso. Se ejecutan cuatro capas, cada una respondiendo a una pregunta distinta.

Tu suite de pruebas. Es la señal más fiable disponible, ya que incorpora lo que tu equipo considera importante. Coroid la ejecuta en un entorno limpio para cada tarea.

Puentes de calidad. Comprobaciones definidas por políticas: cobertura, linting, análisis de seguridad y pruebas en navegador. Los puentes bloqueantes detienen la tarea; los puentes consultivos registran el hallazgo y permiten continuar. Consulta Políticas y puentes de calidad.

Revisión. Un agente revisor analiza el diff finalizado y genera hallazgos. Los hallazgos solucionables se devuelven al desarrollador como trabajo adicional; el resto se adjuntan al pull request.

Evidencia. Despliegues de vista previa, resultados de análisis y variaciones de cobertura se adjuntan directamente al propio pull request, de modo que la validación llega junto con el código. Consulta Evidencia de revisión.

Qué demuestra y qué no demuestra esta validación

La validación confirma que el cambio cumple su función, no rompe lo existente y satisface los estándares que tú has definido.

Sí lo hace no demuestra que el cambio sea lo correcto para desarrollar. Eso es lo que sirven los criterios de aceptación en la especificación y para lo que sirve tu proceso de revisión.

Un cambio puede superar todas las capas y, aun así, ser incorrecto. Mantener esta distinción clara es lo que hace que el resto sea fiable: en cuanto la validación se presente como juicio, la gente dejará de revisar.

El objetivo de ejecutarlo primero

Cada capa se ejecuta antes de que exista el pull request, de modo que los fallos se devuelvan como trabajo adicional dentro del proceso en lugar de como un pull request que simplemente rechazarías.

Es más económico fallar en el entorno de trabajo que en tu pantalla. Tu revisión debe ser la primera persona que lo revise, no la primera vista.

Por dónde empezar

Si estás configurando esto por primera vez:

  1. Asegúrate de que tu suite de pruebas se ejecute: consulta Configuración de compilación y pruebas. Nada más importa si esto no está correcto.
  2. Establece una política predeterminada para la organización en tu nivel estándar , no en el más estricto.
  3. Conecta los proveedores de evidencia que ya utilizas.
  4. Añade los puentes uno por uno, empezando por los consultivos.

En esta sección