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 |
Sprint · dos semanas
Fase 1
TareaFormulario de pagoTareaValidación de tarjetaFase 2
TareaResumen del pedidoUna tarea independiente
TareaCorregir el análisis de fechasTarea
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.
Rama de rama
Donde se integra el trabajo del plan
Una pull request
La funcionalidad ensamblada, revisada una vez
main
Tu rama base
Una tarea para un proyecto distinto al de la rama se promueve de forma independiente, por lo que un plan entre proyectos abre una pull request por repositorio.
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.
Dónde encaja el Lanzamiento
Un Lanzamiento es el registro de entrega tras la integración, no otra tarea, plan, sprint o canal. Vincula una confirmación del repositorio, verifica que el trabajo planificado esté incluido en dicha confirmación y realiza el seguimiento de los intentos de despliegue en cada entorno. Un lanzamiento puede contener trabajo de varios sprints; un sprint puede generar varios lanzamientos. La promoción de un canal abre un pull request pero por sí sola no crea un envío verificado.
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 por una. Consulta Capacidad y slots de agente.