Un pull request de Coroid pasa por verificación antes de que lo veas. Esta sección explica qué significa y cómo configurarlo.
Las capas
La verificación no es un único proceso: existen cuatro capas que responden a preguntas distintas.
Tu suite de pruebas. Es la señal más fiable disponible, ya que refleja lo que tu equipo considera importante. Coroid la ejecuta en un entorno limpio para cada tarea.
Puestos de control de calidad. Comprobaciones definidas por políticas: cobertura, corrección de estilo, análisis de seguridad, pruebas de navegador y las Comprobación de Globalización para proyectos multilingües. Los puestos de control bloqueantes detienen la tarea; los puestos consultivos registran el hallazgo y permiten continuar. Consulta Políticas y puestos de control 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 al propio pull request, de modo que la verificación llegue junto con el código. Consulta Evidencia de revisión.
- Su conjunto de pruebas¿Rompe el cambio lo que ya funciona?
- Puertas de calidad¿Cumple con los estándares que establece tu política?
- Revisión¿Lo aceptaría un lector cuidadoso del diff?
- Evidencia¿Está la prueba adjunta al código?
- Su revisión¿Es este el cambio adecuado?
Todas las capas automatizadas se ejecutan antes de que exista el pull request, por lo que los fallos se devuelven como trabajo pendiente dentro de la ejecución.
Qué demuestra y qué no demuestra esta verificación
La verificación confirma que el cambio cumple su función, no rompe lo existente y cumple con los estándares que has definido.
Sí no demuestra que el cambio sea lo correcto para desarrollar. Eso es lo que sirven los criterios de aceptación de la especificación y para lo que sirve tu revisión.
Un cambio puede superar todas las capas y, aun así, ser incorrecto. Mantener esa distinción clara es lo que hace que el resto sea confiable: en cuanto la verificació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 solo 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:
- Asegúrate de que tu suite de pruebas funcione: consulta Configuración de compilación y pruebas. Nada más importa si esto no está bien.
- Establece una política predeterminada para la organización en tu nivel estándar , no en el más estricto.
- Conecta los proveedores de evidencia que ya uses.
- Añade los puestos de control uno por uno, empezando por los consultivos.