La plataforma convierte tareas y planes en pull requests revisados. Una vez que se fusionan, un lanzamiento responde a la siguiente pregunta: ¿qué parte de ese trabajo está ejecutándose en cada entorno y fue seguro colocarla allí?
Un lanzamiento vincula un commit específico de Git y lo sigue por sus entornos, como Staging y luego Producción. El commit ya puede encontrarse en la rama de despliegue, o Coroid puede primero agrupar los pull requests abiertos en un pull request de lanzamiento cuya confirmación de fusión se convierta en el lanzamiento. En cada etapa, Coroid verifica el commit, recopila las aprobaciones solicitadas y registra el despliegue que informa CI/CD. Coroid nunca marca un lanzamiento como desplegado por sí solo; su pipeline o una persona que registre un despliegue externo debe confirmarlo.
Fábrica de Coroid
Tarea o plan
Los agentes planifican, construyen y prueban
Solicitud de incorporación (pull request)
Revisado con evidencia
Incorporado
Por ti o por una regla del repositorio
Versión
Lanzamiento
Un commit fijado
Entorno de pruebas (staging)
Comprobaciones · aprobación · despliegue
Producción
Comprobaciones · aprobación · despliegue
Resumen en un minuto
- Lanzamiento: un commit, un nombre y una versión opcional. Una versión como
2.4.0es opcional, por lo que la entrega continua funciona sin etiquetas. - Entorno: una parada en el camino hacia sus usuarios, como Staging o Producción. Cada proyecto define sus propias paradas y su orden.
- Despliegue progresivo: los entornos a los que ha llegado el lanzamiento hasta ahora.
- Trabajo: las tareas planificadas para el lanzamiento y los cambios fusionados que contiene, mostrados como completados de un total.
- Cuatro pasos por entorno: comprobaciones, aprobación, despliegue y estado de salud. La página de lanzamientos siempre abre el paso que requiere su intervención.
- Agrupación: un lanzamiento creado a partir de pull requests abiertos. Coroid los fusiona en una rama de lanzamiento, en un orden que puede modificar, y abre un pull request de lanzamiento. Un lanzamiento de paquete tiene un quinto paso, Agrupación, antes de las comprobaciones.
Consulta un lanzamiento de un vistazo
Abrir Lanzamientos en el menú lateral principal de cada proyecto, o la pestaña Lanzamientos de ese proyecto. La lista muestra el progreso del trabajo de cada lanzamiento, su despliegue por entornos y su estado. Usa las pestañas para cambiar entre lanzamientos en curso, ya desplegados o cerrados.
Selecciona un lanzamiento para abrir su página.
- 1Estado. Dónde se encuentra la versión en general.
- 2Despliegue y trabajo. Entornos alcanzados hasta ahora y tareas planificadas ya realizadas. Seleccione una etapa para ver sus pasos.
- 3Pasos. Los cuatro pasos para el entorno seleccionado. El que requiere tu intervención está abierto.
- 4Lo que se está entregando. Cambios fusionados confirmados en el commit, tareas planificadas y los commits desde el último despliegue.
El seguimiento del despliegue también sirve como selector. Selecciona un entorno para ver sus cuatro pasos. La página se abre en el primer entorno al que el lanzamiento aún no ha llegado, por lo que lo siguiente a hacer suele estar ya visible.
Los cuatro pasos en cada entorno
- 1Comprobaciones
Coroid
Las comprobaciones de calidad se ejecutan sobre el commit exacto; los elementos de la lista de verificación requeridos se confirman.
- 2Aprobación
Tu equipo
Las personas que tus reglas designen aprueban este commit para este entorno.
- 3Implementar
Tu CI/CD
Tu pipeline despliega, iniciado por Coroid o por sí mismo, y reporta el resultado.
- 4Estado de funcionamiento
Coroid
Una comprobación canaria monitoriza el entorno tras un despliegue confirmado.
Comprobaciones. Elige Ejecutar comprobaciones. Coroid ejecuta el Quality Graph de validación de lanzamientos del proyecto sobre el commit exacto y confirma que cada cambio vinculado está dentro de ese commit. Los elementos de lista de verificación necesarios para el entorno también deben marcarse como completados. Si algo bloquea el lanzamiento, el paso indicará qué es. Modificar el commit o los cambios vinculados hace que las comprobaciones anteriores queden obsoletas, y el paso te pedirá que las ejecutes de nuevo.
Aprobación. Una vez superadas las comprobaciones, las personas autorizadas según tus reglas pueden aprobar. El paso muestra cuántas aprobaciones se necesitan y de qué roles. Si tus reglas exigen notas de lanzamiento aprobadas, estas también se aprueban aquí.
Despliegue. Cuando las comprobaciones y la aprobación estén listas, el lanzamiento estará preparado para el entorno. Si Coroid está conectado a las Acciones de GitHub o a GitLab CI/CD para ese entorno, un Propietario o Administrador seleccionará Desplegar en… y Coroid iniciará el pipeline para ese commit exacto. De lo contrario, tu pipeline se encargará del despliegue y reportará el resultado. En cualquier caso, el paso solo se volverá verde cuando se confirme el éxito.
Estado de salud. Tras un despliegue exitoso, Coroid ejecutará el Quality Graph canario del proyecto si lo tienes configurado. Un canario aprobado indica que el entorno está en buen estado. Un canario fallido muestra Requiere atención y ofrece opciones de recuperación. Sin un canario, el estado de salud permanece desconocido en lugar de asumirse como correcto.
Qué significan los estados
| Estado | Significado |
|---|---|
| Borrador | Aún no se ha fijado ningún commit. Un lanzamiento de paquete permanece como borrador hasta que se fusione su pull request de lanzamiento. |
| Preparando | Se ha seleccionado un commit; todavía faltan comprobaciones o aprobaciones en algún punto. |
| Bloqueado | Las comprobaciones se ejecutaron y algo impide el lanzamiento. |
| Listo | Las comprobaciones y aprobaciones están completas al menos para un entorno. Aún no se ha desplegado nada. |
| En proceso de envío | Se está realizando un despliegue. |
| Parcialmente enviado | El lanzamiento llegó a algunos entornos pero no a todos. |
| Enviado | El lanzamiento llegó a todos los entornos. |
| Fallido o cancelado | El lanzamiento se detuvo y no continuará. |
| Registro histórico | Creado antes de que existieran pruebas de despliegue; no se considera como prueba de un despliegue. |
Listo Nunca significa que se haya desplegado. Solo un despliegue confirmado permite avanzar al siguiente paso del proceso de lanzamiento.
Flujos de trabajo
Configurar lanzamientos para un proyecto
Hágalo una vez por proyecto. Abra Lanzamientos, seleccione Configuración de lanzamientos, y elija el proyecto.
-
En Entornos, agregue sus paradas y ordénelas, por ejemplo Staging antes de Producción.
-
En Reglas de aprobación, publique reglas para cada entorno: cuántas aprobaciones, desde qué roles y qué elementos de lista de verificación. Un entorno no podrá superar sus comprobaciones hasta que se publiquen las reglas.
-
En Canal de despliegue, decida si Coroid inicia los despliegues o lo hace su canal. Luego cree un token de informe para que su CI/CD pueda indicarle a Coroid qué ha desplegado.
-
En Control de versiones, elija de dónde proviene la versión de cada lanzamiento y asigne a cada entorno una URL de versión para que Coroid pueda confirmar qué se ejecuta allí.
Configuración de lanzamientos Le guiará por cada pantalla, y Incluya la versión en su compilación Muestra cómo la versión llega a su aplicación.
Enviar el trabajo planificado
Úselo cuando sepa de antemano qué debe salir junto.
- Cree el lanzamiento con antelación, antes de asignar un commit. Comenzará como borrador.
- Establezca el lanzamiento objetivo en las tareas que desee incluir. Aparecerán bajo Tareas planificadas, y la barra de trabajo se llenará a medida que se completen.
- Cuando el trabajo se fusione, seleccione Editar detalles y elija el commit a enviar. Coroid confirmará qué cambios fusionados contiene ese commit.
- Siga los cuatro pasos para su primer entorno y luego para el siguiente.
Agrupar pull requests abiertos
Úselo cuando haya muchos pull requests pendientes, ya sea de Coroid o de su equipo, y deban enviarse juntos.
- Corregir el total del carrito de compra#12Las comprobaciones se superan
- Añadir exportación de pedidos#15Tarea de CoroidAprobado
- Reestructurar el índice de búsqueda#18Borrador
- El orden de Coroid prioriza lo más seguro primero. Usted puede marcar y reordenar.
- Una rama de versión donde se fusionan las pull requests en orden.
- Un único pull request de lanzamiento. Al fusionarse, su commit se publica.
Fusione el pull request de lanzamiento mediante un commit de fusión para que su proveedor identifique cada pull request agrupado como fusionado.
- Seleccione Nuevo lanzamiento, elija el proyecto y seleccione Pull requests abiertos. Esta opción requiere un repositorio GitHub o GitLab, por lo que los proyectos alojados en Coroid generan un commit.
- Coroid lista los pull requests abiertos en la rama de despliegue, empezando por los más seguros. Un pull request abierto por Coroid aparece como su tarea o plan. Coroid evalúa lo que ya saben el proveedor y sus propias revisiones: comprobaciones, revisiones, tamaño, conflictos y archivos que tocan varios pull requests. Excluye los borradores, las comprobaciones fallidas, los cambios solicitados y los pull requests de forks, e indica el motivo.
- Desmarque lo que debe esperar y use las flechas para cambiar el orden. Un pull request que depende de otro (un pull request anidado, o uno que diga «depende de #12») siempre viene después.
- Seleccione Crear lanzamiento. Coroid crea
release/<version>desde la rama de despliegue, fusiona los pull requests en orden y abre un pull request de lanzamiento que enumera y enlaza cada uno de ellos. - Si pull request entra en conflicto con la rama de lanzamiento, el Agrupación paso se detiene y muestra los archivos. Selecciona Resolver con Coroid para permitir que el agente desarrollador lo fusione y resuelva el conflicto en una tarea, o Dejarlo fuera para continuar sin él.
- Revisa el pull request de lanzamiento y fusiona con un commit de fusión. A continuación, tu proveedor marca como fusionados todos los pull request incluidos en el paquete. Coroid fija el commit de fusión como commit de lanzamiento, registra los pull requests del paquete como parte del producto que se entrega y cierra los que todavía estén abiertos con un enlace al pull request de lanzamiento.
- Sigue los cuatro pasos para cada entorno como de costumbre.
Las fusiones tipo squash o rebase también funcionan, pero tu proveedor no marca las solicitudes de extracción originales como fusionadas. Coroid las cierra con un comentario en su lugar.
Enviar lo que está en la rama principal
Úselo para la entrega continua, cuando envíe todo lo que se haya fusionado.
- Seleccione Nuevo lanzamiento y elija el commit, generalmente el más reciente de la rama de despliegue.
- Bajo Comparar con, seleccione el entorno que va a reemplazar. Coroid muestra las solicitudes de extracción y commits entre lo que se ejecuta allí y su commit, y selecciona los que puede verificar.
- Deje el nombre y la versión en blanco si lo prefiere. Coroid nombrará el lanzamiento según la fecha y el commit abreviado, y el origen de la versión del proyecto completará la versión. Cada lanzamiento también recibirá el siguiente número de compilación.
- Cree el lanzamiento y siga los cuatro pasos.
Si su canal despliega en cada fusión sin consultar a Coroid, igual puede informar cada despliegue. Cuando no exista un lanzamiento para un commit reportado, Coroid creará un lanzamiento observado para él, marcado claramente como uno que no superó las comprobaciones de Coroid.
Enviar una corrección urgente
Un Propietario o Administrador puede activar Esta es una corrección rápida al crear un lanzamiento, fije el commit completo de la corrección y explique por qué el plazo normal no sirve. Las correcciones rápidas siguen las reglas de corrección rápida de cada entorno, que pueden requerir menos aprobaciones. Las comprobaciones de calidad y los elementos de lista de verificación obligatorios siguen aplicándose, y solo los Propietarios y Administradores aprueban las correcciones rápidas.
Recuperarse cuando algo falla
Si el paso de estado muestra Requiere atención, abra Estado en el entorno afectado y seleccionar un commit estable anterior para volver a desplegarlo. Recuperación y trenes de lanzamiento abarca las opciones, incluidas las pipelines que no pueden enviar informes.
Desde el Chat o tu editor
El asistente de chat y el servidor MCP de Coroid tienen las mismas herramientas de lanzamiento: listar e inspeccionar lanzamientos, elegir un commit, previsualizar lo que se enviaría, preparar un lanzamiento, agrupar solicitudes de extracción abiertas, ejecutar sus comprobaciones, aprobarlo, solicitar un despliegue y redactar notas. Agrupar, aprobar y desplegar siempre necesitan la confirmación de una persona. Consulta Asistente de chat y Coroid como servidor MCP.
Lanzar varios proyectos simultáneamente
Un tren de lanzamiento agrupa los lanzamientos de varios proyectos que deben publicarse juntos y en orden, como API y la aplicación que depende de él. Ver Recuperación y trenes de lanzamiento.
Qué hace y qué no hace Coroid
- Coroid establece, comprueba y registra. Tu repositorio y CI/CD compilan y despliegan.
- Al agrupar pull requests, Coroid crea la rama de lanzamiento y el pull request de lanzamiento. Nunca fusionará el pull request de lanzamiento por ti.
- Coroid inicia un pipeline solo cuando conectas uno y un Propietario o Administrador solicita un despliegue.
- Una solicitud de despliegue no es prueba. La pista de lanzamiento avanza solo cuando tu pipeline confirma el éxito o alguien registra un despliegue externo verificado.
- Las notas de lanzamiento son borradores que tú editas y apruebas. Coroid no las publica en ningún sitio.
- Un Sprint es un período de planificación, no un límite de despliegue. Un Sprint puede alimentar varios lanzamientos, y un lanzamiento puede contener trabajo de varios Sprints.