Configuración de lanzamientos

La configuración de versiones es específica para cada proyecto. Abra Lanzamientos, seleccione Configuración de lanzamientos, y elija el proyecto. Hay cuatro pantallas y cada una responde a una pregunta distinta.

Solo los Propietarios y Administradores pueden modificar la configuración de versiones. El resto solo puede leerla. Conecte primero un repositorio, ya que cada versión apunta a un commit dentro de él.

Entornos#

¿A dónde va una versión y en qué orden?

Cada proyecto comienza con Producción. Agregue los demás destinos de despliegue, como Staging o QA, mediante Agregar un entorno. Asigne un nombre a cada uno. CoRoid sugiere una clave a partir del nombre, por ejemplo staging. Su CI/CD utiliza esa clave al registrar un despliegue, por lo que manténgala estable una vez que las pipelines la usen.

Establezca el orden mediante Viene después de. Un entorno Staging que viene después de nada y Producción que viene después de Staging definen la ruta Staging › Producción. La página de la versión muestra su trayectoria de despliegue en este orden, y las reglas de aprobación pueden exigir que el paso anterior tenga éxito primero.

Reglas de aprobación#

¿Qué debe cumplirse antes de que una versión se despliegue aquí?

Seleccione el entorno en la parte superior. Las reglas son específicas para cada entorno, por lo que Staging puede ser menos estricto y Producción más riguroso.

• Aprobaciones requeridas: cuántas personas diferentes deben aprobar. Si es cero, la versión se despliega en cuanto pasen sus comprobaciones.
• Quién puede aprobar: los roles de la organización autorizados para aprobar.
• Separar al solicitante de los aprobadores: la persona que inicia el despliegue no puede aprobarlo, y quien edita las notas de la versión tampoco puede aprobarlas.
• Las comprobaciones de calidad se cumplen: siempre activado. El Gráfico de Calidad del proyecto con un release_validation disparador se ejecuta sobre el commit exacto. Publique ese gráfico desde la configuración de calidad del proyecto.
• El entorno anterior primero: la versión debe estar ya desplegada en el entorno del cual esta depende.
• Notas de la versión aprobadas: las notas actuales necesitan aprobación, y cualquier edición posterior requiere una nueva aprobación.
• Lista de verificación: pasos manuales que alguien confirma en la página de la versión, como "Migración de base de datos revisada". Marque un ítem como obligatorio u opcional. Un ítem obligatorio puede permitir una excepción temporal. Un Propietario o Administrador registra un motivo y una fecha de caducidad de hasta 24 horas; la excepción solo aplica a ese commit y entorno.
• Reglas de correcciones urgentes: reglas más flexibles para correcciones urgentes: el número de aprobaciones y si siguen aplicándose la aprobación del entorno anterior y de las notas. Las comprobaciones de calidad y los ítems de lista de verificación obligatorios siempre se aplican, y solo los Propietarios y Administradores pueden aprobar correcciones urgentes.

Seleccione Publicar reglas para guardar. Al publicar se crea una nueva versión de las reglas. Las aprobaciones otorgadas bajo la versión anterior quedan obsoletas, por lo que una versión en curso solicitará nuevamente aprobación. Un entorno sin reglas publicadas no podrá superar sus comprobaciones, y la pantalla lo indicará.

Pipeline de despliegue#

¿Quién inicia una implementación y cómo aprende CoRoid qué ocurrió?

Seleccione el entorno en la parte superior y luego elija cómo se inician los despliegues:

• Mi pipeline se despliega por sí solo: mantenga su proceso actual. CoRoid registra las implementaciones cuando su CI/CD las notifica, o cuando un Propietario o Administrador registra una implementación externa en la página de lanzamientos.
• CoRoid inicia un flujo de trabajo de GitHub Actions o CoRoid inicia una canalización de GitLab CI/CD: se muestra cuando el repositorio del proyecto está en ese proveedor. Introduzca la rama o etiqueta que apunta al commit de lanzamiento, el archivo de flujo de trabajo para GitHub, y el nombre exacto del trabajo que realiza la implementación. CoRoid verifica la referencia antes de iniciar la ejecución y comprueba el trabajo indicado antes de aceptar el éxito.

Bajo Informes de despliegue, cree un token de informes para el entorno y guárdelo como secreto en su CI/CD. CoRoid muestra el token una vez y solo conserva un hash del mismo. Al reemplazar el token, el anterior deja de funcionar de inmediato. En la misma pantalla se muestran el punto de conexión, el ID del proyecto y la clave del entorno que necesita su canalización, además de si los informes están llegando. Eventos de despliegue y configuración de CI Contiene el formato de evento y ejemplos.

Control de versiones#

¿Qué versión tiene este lanzamiento y cómo la obtiene la compilación?

Elija de dónde proviene la versión de cada lanzamiento: CoRoid sugiere la siguiente, CoRoid la lee de un archivo en el repositorio o su canalización la informa. Cada lanzamiento también recibe un número de compilación que siempre aumenta. La pantalla muestra los valores que CoRoid pasa a su canalización, puede abrir Nuevo trabajo con una solicitud para agregarlos a su compilación y toma una URL de versión por entorno para que CoRoid pueda confirmar qué se ejecuta en cada uno. Incluir la versión en su compilación contiene los detalles y las instrucciones para compilaciones web, de servidor, Docker, iOS y Android.

Transferir configuraciones entre organizaciones#

La exportación e importación de configuraciones incluyen los entornos, su orden, la configuración de la canalización, el control de versiones, las URLs de versión y las reglas publicadas, incluidas las reglas de correcciones urgentes. Los tokens de informe y los números de compilación nunca se exportan. Cree nuevos tokens después de una importación; cada proyecto mantiene sus propios números de compilación.

Relacionado#

• Lanzamientos
• Eventos de despliegue y configuración de CI
• Incluir la versión en su compilación
• Evidencia de calidad y revisión
• Portabilidad de configuraciones