Lanzamientos

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 se está ejecutando dónde y fue seguro colocarla ahí?

Un lanzamiento fija un commit específico de Git y lo sigue a través de sus entornos, como Staging y luego Producción. El commit ya puede estar en su rama de despliegue, o Coroid puede primero agrupar los pull requests abiertos en un pull request de lanzamiento cuyo commit de fusión se convierta en el lanzamiento. En cada parada, Coroid verifica el commit, recopila las aprobaciones que solicite y registra el despliegue que informe su CI/CD. Coroid nunca marca un lanzamiento como desplegado solo por su propia palabra. Su pipeline o una persona que registre un despliegue externo debe confirmarlo.

La idea en un minuto#

• Lanzamiento: un commit, un nombre y una versión opcional. Una versión como 2.4.0 es 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: qué entornos ha alcanzado el lanzamiento hasta ahora.
• Trabajo: las tareas planificadas para el lanzamiento y los cambios fusionados que contiene, mostrados como realizados de total.
• Cuatro pasos por entorno: comprobaciones, aprobación, desplegar y estado. La página de lanzamiento siempre abre el paso que necesita 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 agrupado tiene un quinto paso, Agrupación, antes de las comprobaciones.

Leer un lanzamiento de un vistazo#

Abrir Lanzamientos en la barra lateral principal para cada proyecto, o la pestaña Lanzamientos de ese proyecto específico. En ejecución ahora, en la parte superior, muestra la versión que ejecuta cada entorno, desde su último despliegue confirmado, y quién lo inició. La lista muestra el progreso del trabajo del lanzamiento, su despliegue progresivo entre entornos y su estado. Use las pestañas para cambiar entre lanzamientos en curso, enviados o cerrados.

Seleccione un lanzamiento para abrir su página.

La pista de despliegue progresivo también funciona como conmutador. Seleccione un entorno en ella para ver los cuatro pasos de ese entorno. 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 a la vista.

Los cuatro pasos en cada entorno#

Comprobaciones. Elija Ejecutar comprobaciones. Coroid ejecuta el Gráfico de Calidad de validación de lanzamiento del proyecto contra el commit exacto y confirma que cada cambio vinculado esté dentro de ese commit. Los elementos de lista de verificación requeridos para el entorno también deben marcarse como completados. Si algo bloquea el lanzamiento, el paso indicará qué es. Cambiar el commit o los cambios vinculados hace que las comprobaciones anteriores queden obsoletas, y el paso le pedirá que las ejecute de nuevo.

Aprobación. Una vez que las comprobaciones se superan, las personas permitidas por sus reglas pueden aprobar. El paso muestra cuántas aprobaciones se necesitan y de qué roles. Si sus reglas requieren notas de lanzamiento aprobadas, las notas también se aprueban aquí.

Desplegar. Cuando las comprobaciones y la aprobación se completan, el lanzamiento está listo para el entorno. Si Coroid está conectado a las Acciones de GitHub o a GitLab CI/CD para ese entorno, un Propietario o Administrador selecciona Desplegar en… y Coroid inicia el pipeline para ese commit exacto. De lo contrario, su pipeline se desplegará por sí solo e informará de vuelta. En cualquier caso, el paso solo se volverá verde cuando se confirme un éxito.

Estado. Después de un despliegue exitoso, Coroid ejecuta el Gráfico de Calidad canario del proyecto si lo tiene. Un canario aprobado marca el entorno como saludable. Uno que falle muestra Requiere atención y ofrece recuperación. Sin un canario, el estado permanece desconocido en lugar de asumirse como saludable.

Qué significan los estados#

Listo Nunca significa que ya se haya desplegado. Solo un despliegue confirmado hace avanzar el lanzamiento en la ruta de distribución.

Flujos de trabajo#

Configurar lanzamientos para un proyecto#

Hazlo una vez por proyecto. Abre Lanzamientos, selecciona Configuración de lanzamiento, y elige el proyecto.

1. En Entornos, añade tus etapas y ordénalas, por ejemplo Staging antes que Producción.

2. En Reglas de aprobación, publica reglas para cada entorno: cuántas aprobaciones se necesitan, de qué roles y qué elementos de lista de verificación aplican. Un entorno no puede pasar sus comprobaciones hasta que se publiquen las reglas.

3. En Canal de despliegue, decide si Coroid inicia los despliegues o lo hace tu canal. Luego crea un token de informes para que tu CI/CD pueda indicar a Coroid qué se ha desplegado.

4. En Control de versiones, elige de dónde proviene la versión de cada lanzamiento y da a cada entorno una URL de versión para que Coroid pueda confirmar qué se ejecuta allí.

Configuración de lanzamiento te guía por cada pantalla, y Incluye la versión en tu compilación muestra cómo la versión llega a tu aplicación.

Lanzar trabajo planificado#

Úsalo cuando sepas de antemano qué debe salir junto.

1. Crea el lanzamiento con antelación, antes de que se fije un commit. Comienza como borrador.
2. Define el lanzamiento objetivo para las tareas que quieras incluir. Aparecen bajo Tareas planificadas, y la barra de trabajo se llenará a medida que se completen.
3. Cuando el trabajo se fusione, selecciona Editar detalles y elige el commit que lanzarás. Coroid confirma qué cambios fusionados contiene ese commit.
4. Sigue los cuatro pasos para tu primer entorno y luego para el siguiente.

Agrupar pull requests abiertos#

Úsalo cuando haya muchos pull requests pendientes, tanto de Coroid como de tu equipo, y deban lanzarse juntos.

1. Selecciona Nuevo lanzamiento, elige el proyecto y selecciona Pull requests abiertos. Esta opción requiere un repositorio GitHub o GitLab, por lo que los proyectos alojados en Coroid lanzan un commit en su lugar.
2. Coroid ordena 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 su propia revisión: comprobaciones, revisiones, tamaño, conflictos y archivos que afectan a varios pull requests. Excluye los borradores, las comprobaciones fallidas, los cambios solicitados y los pull requests de forks, y explica el motivo.
3. Desmarca lo que debe esperar y usa las flechas para cambiar el orden. Un pull request que se basa en otro (un pull request anidado, o uno que indique "depende de #12") siempre vendrá después de este.
4. Selecciona Crear lanzamiento. Coroid crea release/<version> a partir de 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.
5. Si un pull request entra en conflicto con la rama de lanzamiento, el Agrupación paso se detiene ahí 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.
6. Revisa el pull request de lanzamiento y mézclalo con un commit de fusión. Tu proveedor marcará entonces todos los pull request agrupados como fusionados. Coroid fija el commit de fusión como commit de lanzamiento, registra los pull requests agrupados como lo que se lanza y cierra los que todavía estén abiertos con un enlace al pull request de lanzamiento.
7. Sigue los cuatro pasos para cada entorno como de costumbre.

Las fusiones tipo squash o rebase también funcionan, pero tu proveedor no marcará los pull requests originales como fusionados. Coroid los cerrará con un comentario en su lugar.

Lanzar lo que hay en la rama principal#

Úsalo para la entrega continua, cuando lances todo lo que se haya fusionado.

1. Selecciona Nuevo lanzamiento y elige el commit, normalmente el más reciente de la rama de despliegue.
2. Bajo Comparar con, selecciona el entorno que vas a reemplazar. Coroid enumera los pull requests y commits entre lo que se ejecuta allí y tu commit, y selecciona los que puede verificar.
3. Deja el nombre y la versión en blanco si lo prefieres. Coroid nombra el lanzamiento a partir de la fecha y del commit corto, y la fuente de versión del proyecto completa la versión. Cada lanzamiento también recibe el siguiente número de compilación.
4. Crea el lanzamiento y sigue los cuatro pasos.

Si tu canal de despliegue se activa con cada fusión o si alguien realiza un despliegue manual sin consultar a Coroid, este seguirá registrando cada despliegue. Cuando no exista un lanzamiento para una confirmación reportada, Coroid creará un lanzamiento observado para ella, marcado claramente como uno que no ha superado las comprobaciones de Coroid. Adoptará la versión que indique el canal de despliegue o, si Coroid asigna las versiones del proyecto, la siguiente (1.4.1 después de 1.4.0), y el siguiente número de compilación.

Enviar una corrección urgente#

Un Propietario o Administrador puede activar Se trata de una corrección rápida al crear un lanzamiento, se debe fijar la confirmación completa de la corrección y explicar por qué el plazo normal no es viable. Las correcciones rápidas siguen las reglas específicas 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 pueden aprobar las correcciones rápidas.

Recuperarse cuando algo falla#

Si el paso de salud muestra Requiere atención, abre Salud en el entorno afectado y selecciona una confirmación estable anterior para volver a desplegarla. Recuperación y trenes de lanzamiento cubre las opciones disponibles, incluidos los canales que no pueden enviar informes.

Desde el Chat o tu editor#

El asistente de Chat y el servidor MCP de Coroid disponen de las mismas herramientas de lanzamiento: listar e inspeccionar lanzamientos, elegir una confirmación, previsualizar lo que se desplegaría, preparar un lanzamiento, agrupar pull requests abiertos, ejecutar sus comprobaciones, aprobarlo, solicitar un despliegue y redactar notas. Agrupar, aprobar y desplegar siempre requieren la confirmación de una persona. Consulta Asistente de Chat y Coroid como servidor MCP.

Lanzar varios proyectos conjuntamente#

Un tren de lanzamiento agrupa los lanzamientos de varios proyectos que deben enviarse juntos y en orden, como API y la aplicación que depende de él. Consulta Recuperación y trenes de lanzamiento.

Qué hace y qué no hace Coroid#

• Coroid fija, 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 fusiona el pull request de lanzamiento por ti.
• Coroid inicia un canal de despliegue solo cuando lo conectas y un Propietario o Administrador solicita un despliegue.
• Una solicitud de despliegue no es prueba suficiente. La pista de implementación avanza solo cuando tu canal de despliegue 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 incluir trabajo de varios sprints.

Relacionado#

• Configuración de lanzamiento
• Eventos de despliegue y configuración de CI
• Incluye la versión en tu compilación
• Recuperación y trenes de lanzamiento
• Sprints
• Tareas, planes, sprints y columnas
• Calidad y pruebas de revisión