Planes

Un plan es un conjunto ordenado de tareas agrupadas en fases. Lo apruebas antes de que se escriba código.

Úsalo cuando el trabajo requiera varios cambios en un orden específico, o cuando quieras ver todo el enfoque antes de comprometerte con alguna parte.

El ciclo de vida#

La planificación es una etapa en sí misma, no una transformación instantánea.

1. Comienza la planificación. Una vez que la solicitud supera la calificación, el arquitecto explora el código fuente y redacta las fases y tareas. La planificación comienza por sí sola, a menos que la solicitud tenga archivos adjuntos o haya utilizado el flujo de trabajo SDLC; en ese caso, comienza al crear el plan o finalizar la preparación.
2. Revisas el borrador. Este es el punto de intervención más económico de todo el sistema.
3. Aprobar, revisar o reiniciar. Al aprobarlo, se libera para ejecución; al revisarlo, se envía de vuelta con tus comentarios; al reiniciarlo, se vuelve a comenzar la planificación.
4. Ejecución. Las tareas se ejecutan en orden, respetando los límites de fase.

Puedes aprobar y ejecutar en un solo paso, o aprobarlo y comenzar más tarde.

Revisar en lugar de reiniciar#

Cuando un plan está casi listo, revisarlo conserva lo que el arquitecto aprendió sobre tu código fuente y aplica tus comentarios. Reiniciarlo descarta esa información y comienza de nuevo.

Reinicia cuando todo el enfoque sea incorrecto. Revisa cuando el enfoque sea correcto pero los detalles no. La revisión es mucho más económica, y el contenido de un plan rechazado no se pierde: sirve como base para el siguiente intento.

Controlar un plan en ejecución#

Un plan en curso puede pausarse, reanudarse o cancelarse, y puedes observar su progreso a través de las fases. Los planes también pueden clonarse, lo que es la forma práctica de repetir una estructura que funcionó: por ejemplo, una migración aplicada a un segundo servicio.

Los planes completados se pueden archivar para mantener la vista activa organizada.

Un único pull request, no uno por tarea#

Las tareas de un plan no abren cada una un pull request. Trabajan en sus propias ramas y se fusionan en una rama de canal; esa rama se promueve como un único pull request contra tu rama base cuando el trabajo cumple los requisitos.

Por lo tanto, revises la funcionalidad completa una sola vez, con todos los cambios visibles, en lugar de aprobar fases incompletas una por una.

Los planes entre proyectos son la excepción: una tarea perteneciente a un proyecto distinto al del canal se promueve por separado, por lo que obtienes un pull request por repositorio. Un pull request no puede abarcar dos repositorios.

Cuando la rama base cambia#

Un plan puede ejecutarse durante horas, y tu equipo sigue fusionando cambios en la rama base mientras tanto. El plan se creó, probó y revisó contra la rama base tal como estaba cuando comenzó. Para cuando su pull request esté listo, es posible que ya no sea la rama en la que se fusione.

Cuando un plan comienza a ejecutarse, Coroid registra la última confirmación de la rama base como línea de base. Antes de que el pull request del plan pueda fusionarse, Coroid vuelve a comprobar la rama base. Cualquier cambio en el contenido de los archivos cuenta, incluidos los archivos que el plan nunca tocó. Un nuevo esquema de autenticación o regla de seguridad puede hacer que el código correcto sea incorrecto sin causar un conflicto de fusión; por eso Coroid no espera a que haya uno.

Si la rama base ha cambiado, Aprobar y fusionar permanece deshabilitado y la revisión de promoción muestra las nuevas confirmaciones y los archivos que modificaron. Tú eliges qué hacer:

• Aceptar nueva rama principal (denominada según tu rama base): los cambios no afectan este trabajo. Coroid registra quién aceptó qué confirmación y por qué, y esa confirmación se convierte en la nueva línea de base. Si la rama cambió de nuevo mientras la estabas revisando, Coroid lo rechazará y te mostrará primero las confirmaciones más recientes. Nada se acepta sin antes mostrarse.
• Fusionar y volver a verificar — Coroid fusiona la rama base en la rama de canal, resolviendo conflictos si los hubiere. Luego hace pasar la rama por las etapas de desarrollador, control de calidad y revisor, comprobando que cumpla los criterios de aceptación del plan y las confirmaciones del código ascendente. La aprobación se mantiene en espera hasta que finalice ese proceso. Solo entonces la nueva confirmación se convierte en la línea de base. Si la fusión o la re-verificación fallan, la decisión vuelve a ti.

La pausa es la opción predeterminada. Un proyecto puede elegir fusionar y volver a verificar en su lugar, para que Coroid lo inicie sin esperarte; consulta Configuraciones de repositorio y rama. La revalidación consume horas de agente.

Si se reinicia un plan desde el principio, se registra una nueva línea base y se ejecuta en relación con la rama base tal como está en ese momento. Las pruebas del intento anterior permanecen en el historial, pero no determinan el resultado del nuevo intento.

Fusión forzada también omite esta comprobación y registra el motivo indicado por el usuario. Consulta Fusión.

Fases y paralelismo#

Las fases indican orden, no concurrencia. Las tareas dentro de una fase pueden ejecutarse en paralelo si la capacidad lo permite; la siguiente fase espera a que la actual finalice.

Un plan con diez tareas seguras para paralelismo y un único slot de agente aún las ejecutará una por una. La estructura no genera capacidad: consulta Capacidad y slots de agente.

¿Plan o tarea?#

En el formulario de Nuevo trabajo, selecciona Plan o Tarea en Crear como, o déjalo en Automático y deja que la calificación decida. El trabajo que abarca más de un proyecto siempre se convierte en un plan. Si eliges una opción y la calificación recomienda la otra, verás la recomendación antes de crear nada.

La prueba es la posibilidad de revisión: un pull request que un compañero pueda leer de una sola vez es una tarea; cualquier cosa que requiera varios cambios ordenados es un plan.

Adivinar que algo es una tarea cuando en realidad es un trabajo muy grande es el error más arriesgado: la tarea puede quedarse sin espacio a mitad de camino y desperdiciar la ejecución. Adivinar que es un plan solo te cuesta un paso de aprobación que no necesitabas estrictamente.

Puntos de entrega#

Un plan puede incluir un punto de entrega que determine qué debe cumplirse antes de que su resultado avance. Consulta Puntos de calidad.

Relacionado#

• Tareas, planes, Sprints y canales
• Sprints
• Especificaciones
• Procedencia