Cuánto cuestan realmente los entornos de preview
El coste de los entornos de preview crece con los pull requests abiertos, no con el tamaño del equipo. Descubre dónde se oculta el gasto, qué partes se pueden compartir y cómo hacer que los previews caduquen para que cinco PRs abiertos no se conviertan en cinco stacks.
Los entornos de preview son una de las mejoras con mayor impacto que un equipo puede activar. Un reviewer hace clic en un enlace y prueba el cambio en lugar de leer un diff e imaginar cómo funciona. El diseño detecta problemas antes del merge. QA deja de ser una fase.
También son la partida con más probabilidades de triplicar silenciosamente tu factura, y la razón es una cuestión de aritmética que nadie calcula en el momento de activar esta funcionalidad.
La aritmética
El coste del entorno de preview crece con el número de pull requests abiertos, no con el número de personas del equipo ni con el número de merges.
Un equipo de cuatro personas con una cultura saludable de revisión puede tener entre cinco y ocho PRs abiertos en cualquier momento. Si cada uno aprovisiona una copia completa de tu stack, estás ejecutando entre cinco y ocho copias de producción además de producción. Un stack cuyo funcionamiento cuesta 30 $ al mes pasa a costar entre 180 y 270 $, y nada de eso aparecía en las estimaciones de nadie, porque la estimación correspondía a un solo entorno.
Y lo que es peor: los PRs abiertos suelen coincidir con los momentos en los que menos te puedes permitir sorpresas: antes de un release, durante un refactor, cuando alguien está de vacaciones y su branch permanece abierto durante tres semanas.
Dónde se va realmente el dinero
No todas las partes de un preview cuestan lo mismo, y saber cuál es cuál es lo que permite controlar el coste.
Contenedores de aplicación — moderados y justifican la inversión. Esta es la parte que realmente necesitas. También es la que mejor escala hacia abajo, porque un preview no necesita la memoria de producción.
Bases de datos — la parte cara. Tener una base de datos dedicada por preview es el mayor contribuyente al coste y, normalmente, lo menos necesario. La mayoría de las revisiones no necesitan una base de datos aislada; necesitan una base de datos con datos plausibles.
Minutos de build — invisibles y acumulativos. Cada push a un PR abierto vuelve a lanzar el build. Una branch con cuarenta commits en dos semanas genera cuarenta builds. Es un gasto real que nunca aparece como un recurso en ejecución, así que queda completamente fuera de la revisión mental.
Egress — pequeño por preview, grande en conjunto. Las URLs de preview se descubren y se rastrean. Un crawler que descarga tus assets desde ocho entornos de preview hace ocho veces el trabajo que haría en producción, y pagas por todo ello.
Cuatro medidas para reducir el coste sin perder el valor
Comparte la base de datos
Para la mayoría de los cambios, los previews pueden compartir una base de datos con datos representativos precargados. Reserva las bases de datos aisladas para los PRs que realmente las necesiten: migraciones, cambios de esquema o cualquier operación destructiva.
La regla que funciona en la práctica: base de datos aislada solo cuando el PR modifica el esquema. Todo lo demás se comparte.
Reduce el tamaño del preview
Un preview que utiliza un solo reviewer no necesita los recursos de producción. La mitad de memoria y una fracción de la CPU suelen ser imperceptibles para quien revisa el cambio y resultan bastante más baratas.
dockup resources my-project/my-api --memory 512 --cpu 0.5
Haz que caduquen
Es el cambio con mayor impacto. Un preview no debería sobrevivir a su pull request.
El teardown automático al hacer merge o cerrar el PR es básico. Lo que suele pasar por alto a los equipos es el PR abandonado: la branch que alguien abrió, dejó de atender y nunca cerró. Esos entornos siguen ejecutándose durante meses.
Conviene establecer una antigüedad máxima como medida de respaldo: cualquier preview con más de, por ejemplo, catorce días se elimina independientemente del estado del PR. Si alguien lo necesita de nuevo, puede recuperarlo con un solo comando.
Evita que aparezcan en las búsquedas
Las URLs de preview se indexan. Esto es malo por dos motivos: contenido duplicado que compite con tu sitio de producción y tráfico de crawlers que pagas en entornos que nadie está utilizando.
dockup noindex my-project/my-api --on
En Dockup, los previews de PR se configuran por servicio y se pueden activar o desactivar explícitamente, en lugar de ser una configuración global que heredas:
dockup pr-preview my-project/my-api --on
dockup preview list my-project/my-api --json
dockup preview delete 128 my-project/my-api
Enumerarlos es la parte que los equipos se saltan y luego lamentan. Los entornos que no puedes enumerar son entornos por los que estás pagando sin saberlo.
La auditoría que conviene hacer una vez al mes
Tres preguntas, cinco minutos:
- ¿Cuántos previews están ejecutándose? Compáralo con el número real de PRs abiertos.
- ¿Qué antigüedad tiene el más antiguo? Cualquier entorno con más de dos semanas seguramente está abandonado.
- ¿Cuáles tienen su propia base de datos? Todo lo que no sea un cambio de esquema probablemente no la necesita.
La mayoría de los equipos encuentra al menos un entorno de un PR que se fusionó hace meses, que sigue ejecutándose y que sigue generando costes.
Cómo obtener el valor sin sorpresas
Nada de esto es un argumento contra los entornos de preview. Es un argumento a favor de tratarlos como infraestructura con un ciclo de vida, no como una casilla de verificación.
Los equipos que lo hacen bien aplican tres medidas: reducen el tamaño de los previews, hacen que caduquen y comparten todo lo que se pueda compartir de forma segura. Esto suele mantener toda la infraestructura de previews por debajo del coste de un único servicio de producción, que es el precio a partir del cual su utilidad resulta evidente.
Los equipos que se llevan una sorpresa son los que lo activaron una vez, correctamente, y nunca volvieron a consultar la lista.
Preguntas frecuentes
¿Los entornos de preview cuestan tanto como producción? Por entorno, pueden costar lo mismo si se aprovisionan de forma idéntica. Con un tamaño reducido y compartiendo la base de datos, un preview suele costar una fracción de producción.
¿Cada preview debería tener su propia base de datos? Solo cuando el cambio modifica el esquema. Compartir una base de datos con datos precargados cubre la mayoría de las revisiones y elimina el mayor coste.
¿Qué ocurre con un preview cuando se cierra el PR? Debería destruirse automáticamente. Si no, acumularás entornos de PRs que nadie recuerda.
¿Los entornos de preview perjudican al SEO?
Pueden hacerlo si se indexan: contenido duplicado que compite con tus páginas de producción. Márcalos como noindex, lo que además evita que los crawlers generen tráfico por el que tienes que pagar.