Curso de DevOps con GitLab

Review apps: ambientes efímeros por branch para feedback rápido

Curso de DevOps con GitLab

Contenido del curso

Planificación

Verificación

Seguridad

Review apps: ambientes efímeros por branch para feedback rápido

Platzi DayPlatzi Day

Todos los cursos GRATIS

Se acaba en:
:::

Resumen

Las review apps transforman la forma de validar cambios en equipos de desarrollo. Con ambientes efímeros por cada branch, permiten feedback rápido, colaboración real entre QA, diseño y producto, y una ruta clara hacia staging y producción. Aquí verás cómo operan en GitLab, los jobs imprescindibles y buenas prácticas para un pipeline confiable.

¿Qué problema resuelven las review apps en DevOps?

Las review apps eliminan el micromanagement de ambientes y los conflictos en el ambiente de dev compartido. En vez de preguntar en Slack “¿alguien usa dev?”, cada branch genera su ambiente idéntico a producción. Así, el equipo revisa cambios en vivo, comenta y decide si el código está listo.

  • Evitan sobrescribir cambios en dev compartido.
  • Aíslan trabajo paralelo: interfaz y API por separado.
  • Dan visibilidad a diseñadores y product managers.
  • Preparan el camino a continuous deployment con seguridad.

Claves del flujo colaborativo: se trabaja como equipo, no en silos; se comentan cambios, se crean nuevos merge requests y, al aprobar, se hace merge a master y se destruye el ambiente temporal.

¿Cómo operan las review apps con GitLab y environments dinámicos?

El proceso se apoya en dos jobs y en environments dinámicos. Cada commit al branch dispara un deployment a su review app; al hacer merge, se detiene y limpia el ambiente.

  • Un job crea el ambiente: puede hacer deploy a GitLab Pages, Kubernetes, Firebase o lo que uses.
  • El environment es dinámico: usa la variable de GitLab «ci build ref name» para nombrar el ambiente según el branch.
  • La URL también es dinámica: cada review app tiene su enlace.
  • Se define onStop: al borrar el branch o al hacer merge, se ejecuta el job de cierre.

¿Qué incluyen los jobs review y stop review?

  • Crear ambiente: script de deploy al proveedor que elijas.
  • Detener ambiente: limpieza con «git strategy none» para evitar intentar checkout de un branch que ya no existe.
  • Referencia del environment: indicar cuál detener y la acción de «stop».

Ejemplo orientativo en YAML, alineado a lo explicado:

deploy_review: stage: deploy script: - ./scripts/deploy_review.sh # Crear ambiente y hacer deploy. environment: name: review/$CI_BUILD_REF_NAME url: https://$CI_BUILD_REF_NAME.example.com on_stop: stop_review stop_review: stage: cleanup script: - ./scripts/destroy_review.sh # Borrar ambiente. when: manual variables: GIT_STRATEGY: none # git strategy none. environment: name: review/$CI_BUILD_REF_NAME action: stop

Nota: si generar ambientes te parece complejo, considera automatizar infraestructura con herramientas como Terraform, Chef o Puppet.

¿Cómo se integran con staging y producción?

Tras aprobar el merge request, se detiene la review app y el pipeline continúa a staging. Luego, la entrega a producción puede ser gradual: 10 %, 25 %, 50 % o 100 %. Al terminar, el historial de deployments muestra los lanzamientos previos.

¿Cómo validar cambios y desplegar gradualmente a producción?

La revisión ocurre en el propio merge request, punto central de decisión. Con el botón “View app”, cualquiera valida el cambio en la review app y comenta. Al aprobar, se marca “Delete source branch”, se hace merge y se ejecuta el pipeline.

¿Quién prueba y qué visibilidad aporta el merge request?

  • QA testers validan funcionalidad y regresiones.
  • En equipos pequeños, también el product manager o el CEO.
  • El merge request concentra código, conversaciones y el acceso a la app.

¿Qué pasa después del merge?

  • La review app se destruye automáticamente. No quedan residuos.
  • Staging refleja los cambios listos para verificación final.
  • En producción, puedes hacer rollout al 100 % cuando estés listo.

Beneficios directos:

  • Feedback rápido y decisiones informadas.
  • Ambientes efímeros por branch sin colisiones.
  • Historial de deployments claro entre staging y producción.
  • Base sólida para continuous deployment.

¿Usas review apps u otra estrategia similar en tu compañía? Comparte tu experiencia y recomendaciones en los comentarios.