Coroid cuenta con cuatro unidades de trabajo. Estas se anidan entre sí, y elegir la adecuada depende principalmente del tamaño de la tarea y de cuánto de ella debe ejecutarse simultáneamente.
| Unidad | Tamaño | Finaliza en |
|---|---|---|
| Tarea | Un cambio | Una pull request |
| Plan | Una funcionalidad en fases | Una pull request para todo el plan |
| Sprint | Un bloque de trabajo a lo largo del tiempo | Lo que produzcan sus tareas |
| Línea | Un flujo de trabajo paralelo | La rama en la que se integra el trabajo de un plan |
Tarea
El elemento básico. Una tarea es una unidad de trabajo que produce una pull request, y es lo que realmente se ejecuta; los planes, sprints y líneas son todas formas de organizar tareas.
Si puede describir el resultado en un párrafo y un revisor pudiera leerlo de una sola vez, se trata de una tarea.
Plan
Cuando el trabajo requiere varios cambios en un orden específico, se convierte en un plan: un conjunto ordenado de tareas agrupadas en fases, que aprueba antes de escribir cualquier código.
Utilice un plan cuando:
- los pasos posteriores dependen de los anteriores
- desea ver todo el enfoque antes de comprometerse con él
- el trabajo es una funcionalidad y no un simple cambio
Aprobar el plan es el punto de intervención más económico del sistema. Rechazar un enfoque aquí cuesta un minuto; rechazarlo después de que se hayan ejecutado tres tareas cuesta tres ejecuciones.
Cómo llega un plan a su repositorio
Las tareas de un plan no abren cada una una pull request. Trabajan en sus propias ramas y se fusionan en una rama de línea, y esa rama se promueve como una única pull request contra su rama base.
task branch ─┐
task branch ─┼─► lane branch ─► one pull request ─► main
task branch ─┘Así revisa la funcionalidad ensamblada de una sola vez, con todo el cambio frente a usted, en lugar de aprobar fases incompletas de forma individual.
La excepción es el trabajo que abarca varios proyectos: una tarea perteneciente a un proyecto diferente a la línea se promueve por separado, por lo que los planes entre proyectos generan una pull request por repositorio. Eso es inevitable: una pull request no puede abarcar dos repositorios.
Sprint
Un contenedor de tiempo limitado para el trabajo, con sus propias métricas y cronograma. Los sprints responden a «¿qué estamos haciendo en este período y cómo ha ido?» en lugar de «¿cómo se construye esta funcionalidad?».
Utilice un sprint cuando coordine el trabajo de un equipo durante un período. Utilice un plan cuando descomponga una funcionalidad. No son alternativas: un sprint puede contener tareas que pertenezcan a varios planes.
Línea
Una línea es donde se integra el trabajo paralelo de un plan. Las tareas apuntan a la rama de la línea en lugar de a su rama base, de modo que varios agentes pueden avanzar simultáneamente sin colisionar, y el resultado ensamblado se promueve como una única pull request una vez que cumpla los requisitos.
Mientras que un plan trata sobre orden, una línea trata sobre concurrencia y integración. Si tiene capacidad para varios agentes y trabajo que no se serializa estrictamente, la línea permite que se ejecuten juntos y aún así lleguen como un único cambio susceptible de revisión.
Elección
La pregunta no es cuántas pull requests desea: tanto una tarea como un plan llegan como una sola. Se trata de cuánto trabajo debe realizarse antes de que el resultado merezca ser revisado.
- ¿Es este un cambio que un revisor podría leer de una sola vez? Sí → tarea.
- ¿Necesita varios cambios ordenados antes de que tenga sentido como conjunto? Sí → plan. Su línea gestiona la ejecución de las partes en paralelo cuando es posible.
Los sprints se sitúan junto a todo esto como capa de planificación y generación de informes.
Qué limita cuánto se ejecuta simultáneamente
No la estructura, sino la capacidad. Un plan con diez tareas seguras para ejecución paralela y un único slot de agente las ejecuta una tras otra. Consulte Capacidad y slots de agente.