La mayoría de los setups de staging replican producción: una base de datos separada, almacenamiento de objetos separado, todo separado. Es el enfoque seguro. También es caro y tedioso de mantener sincronizado.
Este sitio toma un enfoque diferente: staging corre un Worker separado en una URL diferente, pero comparte el mismo namespace de KV, bucket de R2, y base de datos D1 que producción. Una sola infraestructura, dos destinos de despliegue.
Aquí está cómo se ve, por qué funciona para este caso de uso, y dónde se rompería.
El Setup
Dos workflows de GitHub Actions:
deploy.yml— se dispara en push amain, despliega adwsa-mm.comdeploy-staging.yml— se dispara en push adev, despliega adwsa-staging.4f4p42vhzf.workers.dev
Ambos workflows ejecutan wrangler deploy con el mismo wrangler.toml. Mismos bindings, mismas variables de entorno, ruta diferente. El worker de staging lee desde el mismo namespace de KV que producción.
toml[[kv_namespaces]]
binding = "POSTS_KV"
id = "af2bcae978ce4fb4bec7f9ae325b11bf"
No hay override de id_staging. Ambos entornos usan el namespace de producción.
Por Qué Funciona para un Blog
Los datos en este sistema son mayormente append-only. Los posts se crean, raramente se actualizan, nunca se eliminan. Las claves KV como post:mi-slug no cambian una vez que se publica un post. Los conteos de reacciones se incrementan pero no necesitan estar aislados de producción.
Leer datos de producción en staging es una feature, no un bug. Staging prueba contra contenido real: títulos de posts reales, imágenes hero reales, conteos de vistas reales. Si el worker de staging renderiza un post incorrectamente, veo el post actual que vería en producción, no un placeholder.
Esto es especialmente útil para pruebas de layout. Un post con un título muy largo rompe layouts de manera diferente que uno corto. Staging con datos reales detecta esto inmediatamente.
El Riesgo: Las Mutaciones de Staging Afectan Producción
Este es el tradeoff real. Cualquier operación de escritura que realice staging va a datos de producción.
Las operaciones que escriben:
- Incrementos del contador de vistas (upsert en D1)
- Generación de resúmenes IA (put en KV)
- Actualizaciones de reacciones (put en KV)
- Puntos de datos de Analytics (escritura en Analytics Engine)
Cada vez que visito un post en staging para probar un cambio, el contador de vistas se incrementa en producción. La base de datos D1 no sabe qué worker hizo la petición.
Para los conteos de vistas, esto es aceptable — unos pocos incrementos extra de pruebas no afectan significativamente los números. Para las reacciones, sería más visible si accidentalmente hiciera clic en botones de reacción durante las pruebas.
La mitigación que uso: ser deliberado con las interacciones en staging. No hacer load testing en staging (inflaría los conteos de vistas de producción). Probar layout y comportamiento, no operaciones de base de datos.
Cuándo Importaría el Aislamiento
Si este sitio tuviera:
- Cuentas de usuario — crear usuarios de prueba en staging contaminaría la tabla de usuarios de producción
- Datos transaccionales — compras o pedidos de prueba apareciendo en reportes de producción
- Envío de emails — emails de prueba llegando a usuarios reales
- Rate limiting — tráfico de prueba consumiendo cuotas de rate limit de producción
...necesitaría infraestructura separada. El enfoque compartido solo funciona porque las mutaciones de datos aquí son de bajo riesgo.
Los Beneficios Prácticos
Sin problema de sincronización. Un namespace de KV separado para staging necesitaría ser poblado con datos de producción para probar significativamente. Eso es un script que escribir y mantener. Compartir el namespace elimina el problema.
Costo. Un segundo namespace de KV para staging no costaría nada (el tier gratuito de Cloudflare es generoso). Pero una segunda base de datos D1, un segundo bucket de R2, y costos duplicados de worker se acumulan para funciones de pago. La infraestructura compartida mantiene los costos lineales con el uso, no con el número de entornos.
Sin fallas "funciona en staging" por datos obsoletos. Si staging tiene datos de producción, una feature que funciona en staging funcionará en producción.
El Workflow de la Rama Dev
El flujo en práctica:
- Hacer cambios en la rama
dev - Push a
dev→ staging se auto-despliega en ~1 minuto - Probar en la URL de staging
- Abrir un PR de
devamain→ merge → producción se despliega en ~30 segundos
La brecha entre el despliegue de staging y el de producción es lo suficientemente corta como para que la deriva de datos entre los dos entornos sea despreciable.
Para la mayoría de cambios — ajustes de CSS, nuevas rutas, lógica del worker — el modelo de datos compartido es una ventaja. Pruebo contra contenido real y despliego con confianza.