Entornos

Qué aísla un entorno#

Todos los proyectos empiezan con production. Si añades staging, tienes un segundo conjunto, totalmente separado, de:

• apps, cada una con su propio escalado y sus propios dominios,
• variables de entorno y variables compartidas,
• bases de datos, buckets, volúmenes y jobs.

No se comparte nada de forma implícita. Una app de staging no puede acceder a una base de datos de producción, y ninguna de las dos ve las variables de la otra.

Crear un entorno#

En la consola, abre el proyecto y añade un entorno. Los slugs de entorno tienen hasta 32 caracteres y son únicos dentro de su proyecto, así que dos proyectos pueden tener cada uno su propio staging.

Promover una release#

La promoción es la razón de ser de los entornos. Toma un deploy que ya ha demostrado funcionar en un entorno y publica esa misma imagen en otro. No hay un build nuevo, así que no hay ninguna posibilidad de que entre pruebas y producción cambie la versión de una dependencia o la imagen base.

$ codaracloud deploys list my-api --env staging

$ codaracloud promote my-api \    --from-deploy <deploy-id> \    --from-env staging \    --to-env production

$ codaracloud deploys list my-api --env production

El entorno de destino conserva todo lo que lo distingue: sus propias variables, sus propias conexiones a bases de datos, sus propios dominios y su número de réplicas. Solo cambia la imagen.

Un esquema de ramas que funciona#

Dos esquemas habituales, y Codara admite los dos directamente:

Una rama por entorno#

Apunta staging a la rama develop y production a main. Cada entorno hace el build de su propia rama al hacer push. Es sencillo, y el nombre de la rama te dice qué está desplegado en cada sitio; pero producción hace el build de un código que nunca ha pasado por un build, así que las dos imágenes nunca son idénticas bit a bit.

Un solo build y promoción#

Conecta solo staging a una rama. En producción no se hace ningún build; las releases llegan por promoción. Es el esquema más seguro: lo que has probado es, literalmente, lo que se publica. Desactiva los deploys automáticos de la app de producción para que solo pueda cambiar por promoción.

$ codaracloud apps update my-api --env production --manual-deploys

Entornos de preview#

Un proyecto puede activar la creación automática de un entorno por cada pull request, para que quien revisa tenga una copia del cambio en marcha. Se activa por proyecto:

$ codaracloud projects update website \    --client my-workspace \    --automatic-previews \    --preview-source production

El entorno de origen de las previews es el entorno persistente cuya configuración se copia en cada preview nueva. Las previews van marcadas como tales y están pensadas para ser desechables.

Pausar un entorno#

Un entorno se puede pausar entero. Las apps y las bases de datos dedicadas dejan de consumir cómputo, los jobs programados se suspenden y los jobs puntuales nuevos esperan a que se reanude. Los volúmenes persistentes y los pools compartidos de bases de datos se mantienen, así que pausar reduce el coste de cómputo pero no hace que el entorno salga gratis. Quien usa una base de datos compartida no puede detener por su cuenta el servidor del pool. Al reanudar, vuelven las cargas de trabajo del entorno. Pausar el entorno de producción por defecto de un proyecto exige una segunda confirmación que incluya su slug exacto.

Eliminar un entorno#

Un entorno persistente tiene que estar vacío para poder eliminarlo: quita antes sus apps, bases de datos, jobs y buckets. Con una preview de pull request es distinto: al eliminarla se limpian sus apps, bases de datos y jobs, de forma segura ante reintentos, después de una confirmación explícita del borrado en cascada. Los buckets nunca se borran en cascada, porque pueden contener datos de tus clientes, así que hay que quitarlos antes de forma explícita. El entorno por defecto de un proyecto no se puede eliminar hasta que otro entorno se marque como entorno por defecto.