Esta es la página a la que hacen referencia el resto de la documentación. Nombra cada etapa 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 ambos modos de ejecución de una tarea. En modo estándar, la plataforma mueve la tarea de una etapa a la siguiente. En modo Coordinator, el agente de planificación actúa como coordinador, asigna cada etapa al agente adecuado y decide qué hacer después de cada resultado, incluido enviar trabajo de vuelta. En cualquier caso, una etapa se cierra mediante sus propias comprobaciones. Consulta Roles de agente para saber cómo difieren los dos modos.
Especificación
Coroid no parte de tu frase. Primero convierte tu descripción en una especificación: lo que se va a construir, lo que está explícitamente fuera de 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 produce trabajos difíciles de evaluar.
Puedes leer y editar la especificación en la pestaña de Especificación de la tarea antes de que comience la ejecución.
La guía de desarrollo impulsado por 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 cosa más grande que un cambio pequeño, la especificación se convierte en un plan: un conjunto ordenado de pasos agrupados en fases. Aprobas el plan antes de que se escriba 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 es costoso. Esta es la etapa en la que tu juicio tiene mayor influencia.
Construir
Un agente clona el repositorio en un espacio de trabajo aislado y trabaja allí. Lee el código, escribe el cambio y redacta o actualiza las pruebas.
El espacio de trabajo es desechable y específico para cada tarea. Nada de lo que haga un agente afecta tu rama predeterminada, y dos tareas que se ejecuten al mismo tiempo no pueden ver el trabajo en curso del otro.
Verificar
Primero se ejecuta tu propia suite de pruebas: esa es la señal más fiable disponible, ya que codifica lo que tu equipo ya considera importante.
Además de eso, puertas de calidad ejecutan lo que tu organización haya configurado: umbrales de cobertura, herramientas de linting, pruebas de navegador contra una implementación de vista previa y las Seguridad protecciones. Una puerta bloqueante detiene la tarea; una puerta informativa registra un hallazgo y permite que continúe.
Revisión
Un agente revisor lee el diff como lo haría un colega y genera hallazgos. Los hallazgos que se pueden corregir se envían de vuelta para reelaboración; el resto se adjuntan a pull request para que los veas.
Por eso un Coroid pull request llega ya revisado: no para reemplazar tu revisión, sino para que tu revisión no sea la primera.
Solicitud de extracción
La rama se envía y se abre un pull request contra tu rama base, con el cambio, las pruebas, los resultados de verificación y los hallazgos de revisión. Si el código ya cumple con lo que pide la tarea, no hay nada que enviar: la QA verifica el código sin cambios y la tarea finaliza sin un pull request.
Aquí termina la automatización de tareas de Coroid. La fusión es responsabilidad tuya.
Después de la fusión
Abre Lanzamientos para preparar el commit exacto que pretendes lanzar. Una versión puede incluir varias solicitudes de extracción fusionadas, un commit directo o trabajo fusionado fuera de Coroid. La puerta de versión 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 certificación explícita antes de marcarlo como lanzado. Una tarea marcada COMPLETED o un pull request fusionado por sí solo no demuestran el despliegue.
Estados de tarea
El estado de una tarea te indica en qué punto se encuentra en el proceso descrito arriba:
| Estado | Significado |
|---|---|
PENDING | Aceptada, en espera de un slot de agente disponible |
IN_PROGRESS | En proceso de trabajo activo |
PENDING_REVIEW | El trabajo está listo y revisado, en espera de integración o aprobación |
COMPLETED | El trabajo de la tarea se completó; el despliegue se controla por separado |
NEEDS_HUMAN_REVIEW | Coroid no puede continuar por sí solo y te está haciendo una pregunta |
PAUSED | Detenida temporalmente, reanudable |
FAILED | La ejecución no pudo completarse |
CANCELLED | Detenida por ti |
WONT_FIX | Cerrada deliberadamente sin realizar el trabajo |
¿Qué determina el rendimiento?
Un slot de agente Ejecuta una tarea a la vez. Las ranuras determinan cuánto trabajo se realiza en paralelo; no aceleran la finalización de ninguna tarea concreta. La duración de cada tarea depende del tamaño de los cambios y del tiempo que tarde tu suite de pruebas en ejecutarse.
Siguiente
Roles de los agentes — qué agente gestiona cada fase del trabajo. Luego, consulta Lanzamientos para el flujo posterior a la fusión a través de tus entornos.