Coroid modela un ciclo de vida de software completo, no solo la fase de compilación. La mayor parte se ejecuta automáticamente; una parte es un punto de control opcional que se activa cuando el trabajo es lo suficientemente relevante como para justificarlo.
El flujo de trabajo SDLC opcional
En la Nuevo trabajo formulario, bajo configuraciones avanzadas, hay una casilla de verificación:
Utilizar el flujo de trabajo SDLC (opcional) — revisa la intención y las especificaciones antes de comenzar la planificación. Deja esta opción desactivada para iniciar un plan directamente a partir de tu resumen.
Está desactivado por defecto. Si está desactivado, la planificación comienza a partir de tu resumen una vez que este se apruebe. CalificaciónAl activarlo, primero se generan y aprueban dos artefactos:
- Intención — el propósito real del trabajo, con las decisiones y supuestos que lo sustentan registrados.
- Especificación — alcance, exclusiones y criterios de aceptación.
Solo después de que estos se aprueben comienza la planificación.
Cuándo activarlo
Actívalo cuando el coste de construir algo incorrecto sea elevado, cuando la solicitud provenga de alguien que no va a revisar el plan personalmente, o cuando el resumen contenga un supuesto que prefieras ver plasmado por escrito y acordado.
Déjalo desactivado cuando el resumen ya sea inequívoco. Una puerta de aprobación adicional en el trabajo rutinario supone fricción sin beneficio alguno, y el paso de aprobación del plan sigue aplicándose de todos modos.
Las cinco etapas
El ciclo de vida completo se desarrolla en cinco etapas, cada una de las cuales genera evidencias que utiliza la siguiente.
| Etapa | Qué ocurre | Estado |
|---|---|---|
| Definir | Una solicitud ambigua se convierte en una intención aprobada, decisiones, supuestos y medidas de éxito. | Versión beta |
| Visualizar | Conceptos opcionales de interfaz de usuario, refinados y aprobados como guía de diseño. | Versión beta |
| Entregar | El plan se descompone y los agentes lo ejecutan. | Disponible |
| Comprobar | Los requisitos se mapean a tareas, comprobaciones, resultados de revisiones y cambios en las solicitudes de extracción. | Disponible |
| Mejorar | La monitorización, la corrección y las evaluaciones convierten las regresiones en el siguiente ciclo de trabajo. | Disponible |
- DefinirIntención, decisiones, supuestos y medidas de éxito aprobadosBeta
- VisualizarConceptos de interfaz opcionales, aprobados como guía de diseñoBeta
- EntregarEl plan se descompone y los agentes lo ejecutanDisponible
- ComprobarLos requisitos se mapean a tareas, comprobaciones, incidencias y cambiosDisponible
- MejorarLas regresiones pasan a ser parte del siguiente cicloDisponible
OpcionalActiva el flujo de trabajo SDLC para aprobar la intención y la especificación antes de comenzar la planificación.
Mejorar alimenta el siguiente ciclo: los monitores, la remediación y las evaluaciones convierten las regresiones en nuevo trabajo.
Definir y Visualizar son las dos funcionalidades en desarrollo activo. Entregar, Comprobar y Mejorar son los procesos que se ejecutan en cada tarea actualmente, independientemente de si se activa o no el punto de control.
Por qué los artefactos tienen versión
Las Aprobaciones se vinculan a una versión concreta de un artefacto. Editar un artefacto aprobado crea un borrador nuevo en lugar de modificar silenciosamente lo que se había acordado.
Esto es lo que hace que una aprobación tenga sentido. Una aprobación que sea flotante —vinculada a la «especificación» en lugar de a una versión específica de ella— valida cualquier contenido que el documento tenga posteriormente, lo cual en realidad no constituye una aprobación.
Roles de aprobación
Se pueden asignar de forma independiente las responsabilidades de producto, diseño, técnica, seguridad y lanzamiento, de modo que la persona que aprueba las implicaciones de seguridad no sea necesariamente la misma que aprueba el alcance.
Línea de origen de las pruebas
El objetivo de generar pruebas en cada etapa es poder rastrear hacia atrás un pull request final: este cambio implementa esta tarea, que proviene de este requisito, que a su vez deriva de esta intención aprobada.
Esa cadena es lo que permite auditar la entrega autónoma. Sin ella, tendrías código funcional pero sin constancia de por qué es el código que solicitaste.
Desde el código revisado hasta un lanzamiento
pull request es el resultado del ciclo de trabajo. Una vez que las reglas de tu repositorio permiten la fusión, un Lanzamiento fija un SHA de confirmación completo y registra qué cambios contiene esa confirmación. Su puerta de preparación evalúa esa confirmación exacta para un entorno seleccionado. Las Aprobaciones se vinculan a la instantánea de la puerta; editar el candidato o la política invalida las decisiones anteriores.
Solicitar el despliegue inicia un intento en tu canalización conectada. Una devolución de llamada del proveedor o una certificación manual registran lo que llegó al entorno, y un canario posterior al despliegue registra la salud por separado. Por tanto, la tarea, pull request y el Lanzamiento tienen significados distintos: el trabajo completado no es prueba de que el código haya llegado a producción.
Cómo se relaciona esto con los planes
El flujo de trabajo SDLC y los planes son puntos de control diferentes:
- El flujo de trabajo SDLC aprueba qué se debe construir, antes de que exista un enfoque.
- El plan aprueba cómo se va a construir, antes de que exista el código.
Puedes utilizar uno, ambos o ninguno. Ambos son más económicos que revisar un pull request final con el que no estés de acuerdo.