Staging y producción en Lovable con GitHub

Cuando trabajas en una app conectada a GitHub y Vercel, mezclar cambios sin probar con la versión que usan tus usuarios es la receta perfecta para romper algo en vivo. Por eso necesitas separar tu flujo en entornos: staging y producción te permiten desarrollar y probar sin afectar a quienes ya están usando tu producto.

Aquí te explico cómo funcionan estos entornos, por qué importan y cómo configurarlos paso a paso dentro de Lovable usando ramas de GitHub.

¿Qué son los entornos de staging, producción y desarrollo?

En cualquier ciclo de desarrollo de software tienes un front end desplegado que tus usuarios consumen. La idea es nunca empujar cambios sin testear directamente a esa versión pública.

¿Qué es un entorno de staging? Es una copia paralela de tu app donde pruebas nuevas funcionalidades antes de liberarlas. Sirve como filtro de calidad antes de que el código llegue al usuario final.

La separación clásica funciona así:

• Producción: la versión estable que tus usuarios están usando ahora mismo.
• Staging: el entorno donde pruebas features nuevas y haces QA (quality assurance).
• Desarrollo: la rama donde construyes el código de cada feature antes de moverlo a staging.

Cuando termino una feature en mi rama de desarrollo, hago un merge hacia staging [01:45]. Ahí alguien (tú mismo si trabajas solo, o tu equipo) revisa que todo funcione. Si está en verde, recién entonces se mueve a producción y se libera al usuario.

¿Por qué necesitas separar staging de producción?

La razón es simple: proteger la experiencia de tu usuario final. Si subes un cambio que rompe la app directo a producción, todos tus usuarios lo van a sufrir al mismo tiempo.

Con staging tienes una compuerta antes de que cualquier cambio llegue al público. Los bugs siempre se cuelan, sí, pero este proceso reduce drásticamente la probabilidad de que algo crítico explote en vivo.

¿Qué significa hacer QA en staging? Significa probar manualmente la nueva feature y el resto de la app para confirmar que nada se rompió. Recién después se autoriza el paso a producción.

¿Cómo configurar staging y producción en Lovable con GitHub?

Lovable se integra con GitHub, y sobre esa integración construyes tu flujo de ramas. Si todavía no has conectado tu proyecto, puedes hacerlo desde el botón de GitHub arriba a la derecha o desde la configuración del proyecto [04:25].

¿Cómo crear una rama de staging?

Dentro del repo en GitHub, tu rama main es la que está conectada a Vercel y se despliega como producción. Para crear staging:

1. Abre el selector de ramas en GitHub.
2. Escribe el nombre staging.
3. Haz clic en Create new branch.

Esa rama nace sincronizada con producción, así que parten desde el mismo punto. Desde aquí, cualquier cambio nuevo lo trabajas sobre staging, no sobre main.

¿Cómo crear una rama de feature desde staging?

Con staging seleccionada, creas otra rama encima para trabajar una funcionalidad específica. En el ejemplo la llamamos feature A, pero puedes usar nombres alineados a tu herramienta de gestión de proyectos.

El flujo queda así:

• main → producción, lo que ven tus usuarios.
• staging → entorno de pruebas integradas.
• feature A → desarrollo aislado de una funcionalidad puntual.

¿Cómo cambiar de rama dentro de Lovable?

Abre la configuración del proyecto y entra a la integración de GitHub abajo a la izquierda [06:30]. Si no ves la opción de ramas, actívala desde Labs con un slider que dice GitHub branches.

Una vez activa, selecciona la rama en la que quieres trabajar, en este caso feature A. Lovable se conecta a esa rama y todos los cambios que hagas se commitean ahí, sin tocar producción.

¿Cómo verificar que tus entornos están separados?

Después de hacer un cambio en feature A desde Lovable, vuelves a GitHub y revisas el estado de cada rama.

En el ejemplo, la rama de feature aparece one commit ahead porque registró el cambio reciente de idioma. La rama de producción, en cambio, muestra que su último commit fue hace tres días, lo que confirma que tus usuarios siguen viendo la versión estable mientras tú experimentas en otra rama.

Esa separación visible entre commits es la prueba de que el flujo está funcionando: lo que tocas en desarrollo no contamina lo que está en vivo.

En la siguiente clase vemos cómo abrir un PR (pull request) y mover los cambios entre ramas de forma controlada. ¿Ya tienes tu rama de staging creada? Cuéntame en los comentarios cómo organizas tus entornos.