Mergear de staging a producción sin errores

Pasar tus cambios de un development branch a producción sin romper la experiencia del usuario final exige un flujo claro: desarrollo, staging, QA y merge a main. Aquí aprenderás cómo estructurar ese proceso usando GitHub, Lovable, Linear y Vercel para deployar de forma segura y ordenada.

Este flujo es ideal para desarrolladores solo o equipos pequeños que trabajan con low-code y quieren evitar bugs en producción siguiendo buenas prácticas de control de versiones.

¿Por qué necesitas un flujo development, staging y production?

La idea central es que tus usuarios finales nunca deberían recibir código sin probar. Por eso el trabajo se divide en tres entornos: una rama de desarrollo donde haces cambios, un staging donde se prueban features integradas, y producción donde vive la versión estable que ven tus usuarios.

¿Qué es un staging environment? Es un entorno intermedio donde mergeas tus features para hacer QA antes de enviarlas a producción. Sirve para detectar bugs sin afectar a usuarios reales.

Este flujo evita que un cambio mal probado llegue directo al end user y te da espacio para revisar el trabajo propio o de tu equipo [01:05].

¿Cómo organizar tickets y branches con Linear?

Linear es una herramienta de project management con integración fuerte a GitHub. Cuando abres un ticket, puedes generar automáticamente el nombre de la rama desde el botón superior derecho y la tarea se mueve a In Progress sin esfuerzo manual [01:35].

La recomendación es elegir cualquier herramienta con buena integración a GitHub. Eso simplifica el tracking de tareas y te ahorra fricción al cambiar entre la planificación y el código.

¿Cómo crear una feature branch desde el ID de Linear?

Una vez tienes el nombre que Linear sugiere, creas la rama en GitHub y luego la conectas dentro de Lovable yendo a Project Settings y cambiando la rama activa [02:30]. También puedes crear ramas directamente desde Lovable si lo prefieres.

Trabajar en esa feature branch aislada te permite experimentar sin tocar lo que ya está en producción.

¿Qué cambios conviene hacer en una sola feature branch?

La regla de oro es mantener los pull requests pequeños. Un PR con demasiados cambios complica el merge, dificulta el QA y aumenta el riesgo de conflictos.

• Enfócate en una sola mejora granular por rama.
• Evita combinar login, dashboard y otras features en el mismo PR.
• Piensa en pasos secuenciales, no en entregas masivas.

En el ejemplo de la clase, se aplicó un prompt para rediseñar el dashboard usando los principios de Dieter Rams, que priorizan función sobre forma y simplifican la UI [04:15]. Es un cambio acotado, perfecto para una sola rama.

¿Cómo crear un pull request hacia staging en GitHub?

Después de terminar el feature, abres GitHub, te aseguras de estar en tu rama (que aparecerá como one commit ahead of main) y haces clic en Contribute y luego en Open pull request [06:20].

El detalle clave: el base o target del PR debe ser staging, no main. Así el código pasa primero por revisión antes de tocar producción.

¿Qué es un pull request? Es una solicitud para integrar los cambios de una rama en otra. Permite revisar el código, comentar y aprobar antes de mergear.

Escribe descripciones detalladas. La frase guía es overwriting instead of underwriting: deja un rastro claro de qué cambiaste y por qué, para que tú o cualquier compañero entienda la historia del proyecto sin abrir el código [07:40].

¿Cómo ayudan Vercel y Linear en el pull request?

Si tienes ambas integraciones activas, ocurre lo siguiente:

• Linear detecta el ID del ticket en el nombre de la rama y enlaza la tarea automáticamente.
• Vercel genera un preview deployment con un link de prueba para revisar el cambio sin mergear.
• GitHub verifica conflictos en la rama base antes de permitir el merge.

Eso te permite revisar visualmente el cambio y confirmar que nada se rompió [08:50].

¿Cómo hacer QA y mergear staging a producción?

Una vez aprobado el PR a staging, vuelves a Lovable, cambias la rama activa a staging y revisas todo el entorno. Este paso es el QA check o quality assurance: verificar que todas las features integradas funcionan juntas [10:30].

Si tu equipo aprueba el estado de staging, abres un nuevo pull request desde staging hacia main. Vercel volverá a desplegar un preview y GitHub correrá sus checks automáticos.

• Confirma que no haya conflictos.
• Escribe una descripción listando los cambios incluidos.
• Haz clic en Merge pull request y luego en Confirm merge.

¿Debo borrar la rama staging después del merge? No. Staging se mantiene siempre activa porque seguirás integrando nuevas features ahí antes de cada release a producción.

Las feature branches sí conviene eliminarlas tras el merge para mantener limpio el repositorio y evitar confusiones [09:50].

¿Cómo se ve el flujo completo paso a paso?

Este es el resumen del workflow recomendado para mantener tu app estable:

1. Crea una feature branch desde un ticket con cambios pequeños y específicos.
2. Mergeala a staging con un PR descriptivo y revisa el preview de Vercel.
3. Haz QA en staging para confirmar que todo funciona junto.
4. Abre un PR de staging a main y confirma el merge para deployar a producción.

Vercel se encarga del auto deploy a producción, así que en cuanto confirmas el merge, los usuarios reciben la versión nueva. Si seguiste el flujo, llegará sin sorpresas.

¿Ya estás aplicando este flujo en tus proyectos? Cuéntame en los comentarios qué herramientas usas para tu project management y cómo organizas tus ramas.