Cómo una tarea se convierte en un pull request

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#

your description
   │
   ▼
   specification   what will be built, and how you will know it worked
   │
   ▼
   plan            the ordered steps, reviewed before any code is written
   │
   ▼
   build           code and tests written in an isolated workspace
   │
   ▼
   verify          your test suite, plus checks and quality gates
   │
   ▼
   review          an automated review pass over the diff
   │
   ▼
   pull request    on a branch, in your repository, waiting for you

Especificación#

Coroid no comienza con tu frase. 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 produce trabajos difíciles de evaluar.

Puedes leer y editar la especificación en la pestaña de 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 cosa más compleja que un cambio menor, 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 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 actualiza o crea las pruebas.

El espacio de trabajo es desechable y específico por tarea. Nada de lo que haga el agente afecta a tu rama predeterminada, y dos tareas que se ejecuten simultáneamente no pueden ver el trabajo en progreso de la otra.

Verificar#

Tu propia suite de pruebas se ejecuta primero: esa es la señal más fiable disponible, ya que refleja lo que tu equipo ya consideró importante.

Además de eso, puertas de calidad aplican lo que tu organización haya configurado: umbrales de cobertura, herramientas de linting, análisis de seguridad y pruebas en navegador contra un despliegue de vista previa. Una puerta bloqueante detiene la tarea; una puerta informativa registra un hallazgo y permite continuar.

Revisión#

Un agente revisor lee la diferencia del código como lo haría un compañero y genera hallazgos. Los hallazgos que se pueden corregir se envían de vuelta para reelaboración; los demás se adjuntan a la pull request para que tú los veas.

Por eso una Coroid pull request llega ya revisada: 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 una pull request contra tu rama base, incorporando el cambio, las pruebas, los resultados de verificación y los hallazgos de revisión.

Coroid termina aquí. La fusión depende de ti.

Estados de la tarea#

El estado de una tarea te indica en qué punto se encuentra en la ruta descrita anteriormente:

Qué determina el rendimiento#

Un espacio de agente ejecuta una tarea a la vez. Los espacios determinan cuánto trabajo ocurre en paralelo; no aceleran la finalización de una tarea individual. La duración de una tarea depende del tamaño del cambio y del tiempo que tarde tu suite de pruebas.

Siguiente#

Roles de los agentes — qué agente gestiona cada etapa y qué está permitido hacer.