Esta es la página a la que se refiere el resto de la documentación. En ella se nombran todas las etapas de ejecución para que los demás artículos puedan ser precisos sobre dónde ocurre algo.
La ruta
- 1
EspecificaciónQué se construirá y cómo sabrás que funcionó
ArquitectoPuedes editar - 2Planificación
Pasos ordenados, revisados antes de escribir cualquier código
ArquitectoTú apruebas - 3
DesarrolloCódigo y pruebas escritos en un espacio de trabajo aislado
Desarrollador - 4
VerificaciónTu suite de pruebas, además de comprobaciones y controles de calidad
Control de calidad - 5
RevisiónUna revisión automatizada del diff
Revisor - 6Solicitud de incorporación de cambios
En una rama de tu repositorio, esperando tu aprobación
Tú fusionas
Los resultados de verificación fallidos y las observaciones de revisión corregibles vuelven al desarrollador como reelaboración, antes de que se abra cualquier pull request.
Estas etapas son las mismas en los dos modos de ejecución de una tarea. En el modo estándar, la plataforma mueve la tarea de una etapa a la siguiente. En el modo Coordinador, el agente de planificación actúa como coordinador y se encarga de la tarea, asignando cada etapa al agente correspondiente y decidiendo qué hacer tras cada resultado, incluido enviar el trabajo de vuelta para re trabajo. En ambos casos, una etapa se cierra tras completar sus propias comprobaciones. Consulta Roles de los agentes para saber cómo difieren los dos modos.
Especificación
Coroid no comienza a partir de tu texto. Primero convierte tu descripción en una especificación: qué se va a construir, qué queda explícitamente fuera del alcance y los criterios de aceptación que determinan si el trabajo tuvo éxito.
Esto es importante porque los criterios de aceptación son lo que la etapa de verificación comprueba más tarde. Una especificación vaga genera trabajos difíciles de evaluar.
Puedes leer y editar la especificación en la pestaña de la tarea Especificación antes de que comience la ejecución.
La guía de desarrollo basado en especificaciones explica cómo redactar criterios verificables, establecer límites de alcance y mantener la misma definición de éxito durante la planificación, implementación y revisión.
Planificar
Para cualquier cambio que supere lo básico, la especificación se convierte en un plan: un conjunto ordenado de pasos agrupados en fases. Aprobas el plan antes de que se escriba el código.
Rechazar un plan es económico y es la decisión correcta cuando el enfoque es erróneo. Rechazarlo después de escribir el código resulta costoso. Esta es la etapa en la que tu juicio tiene mayor influencia.
Desarrollar
Un agente clona el repositorio en un espacio de trabajo aislado y trabaja allí. Lee el código, escribe el cambio y crea o actualiza las pruebas.
El espacio de trabajo es desechable y específico por tarea. Nada de lo que haga un agente afecta a tu rama predeterminada, y dos tareas que se ejecuten simultáneamente no podrán ver el trabajo en curso de la otra.
Verificar
Primero se ejecuta tu propia suite de pruebas: esa es la señal más fiable disponible, ya que refleja lo que tu equipo ya considera importante.
Además de eso, puertas de calidad Ejecuta lo que tu organización haya configurado: umbrales de cobertura, herramientas de linting, análisis de seguridad y pruebas en navegador sobre una implementación de vista previa. Una puerta bloqueante detiene la tarea; una puerta informativa registra un hallazgo y permite que continúe.
Revisión
Un agente revisor analiza el diff del mismo modo que lo haría un compañero y genera hallazgos. Los hallazgos que se pueden corregir se devuelven para su reelaboración; los demás se adjuntan al pull request para que puedas verlos.
Por eso un Coroid pull request llega ya revisado: no para sustituir tu revisión, sino para que tu revisión no sea la primera.
Solicitud de extracción
Se envía el branch y se abre un pull request contra tu branch base, incluyendo el cambio, las pruebas, los resultados de verificación y los hallazgos de la revisión. Si el código ya cumple con lo solicitado en la tarea, no hay necesidad de enviar nada: el equipo de QA verifica el código sin modificar y la tarea se finaliza sin crear un pull request.
Aquí termina la automatización de tareas de Coroid. La fusión es responsabilidad tuya.
Después de la fusión
Abrir Lanzamientos para preparar el commit exacto que pretendes entregar. Un lanzamiento puede incluir varias solicitudes de extracción fusionadas, un commit directo o trabajo fusionado fuera de Coroid. La puerta de lanzamiento y las aprobaciones se refieren a ese commit y a un entorno específico. Tu pipeline lo despliega; Coroid registra un éxito observado o una atestación explícita antes de marcarlo como entregado. Una tarea marcada COMPLETED o un pull request fusionado por sí solo no demuestran que el despliegue se haya producido.
Estados de la tarea
El estado de una tarea te indica en qué fase se encuentra del proceso descrito anteriormente:
| Estado | Significado |
|---|---|
PENDING | Aceptada, en espera de un slot de agente disponible |
IN_PROGRESS | En proceso de ejecución activa |
PENDING_REVIEW | El trabajo está listo y revisado, a la espera de integración o aprobación |
COMPLETED | El trabajo de la tarea se ha completado; el despliegue se gestiona por separado |
NEEDS_HUMAN_REVIEW | Coroid no puede continuar por sí solo y necesita tu intervención. |
PAUSED | Detenido temporalmente, reanudable |
FAILED | La ejecución no pudo completarse |
CANCELLED | Detenido por ti |
WONT_FIX | Cerrada deliberadamente sin realizar el trabajo |
¿Qué determina el rendimiento?
Un slot de agente ejecuta una tarea a la vez. Los slots definen cuánto trabajo se realiza en paralelo; no aceleran la finalización de ninguna tarea concreta. La duración de una tarea depende del tamaño del cambio y del tiempo que tarde tu suite de pruebas.
Siguiente
Roles de agente — qué agente gestiona cada etapa del trabajo. Luego consulta Lanzamientos para conocer la ruta posterior a la fusión a través de tus entornos.