Saltar al contenido principal

Documentación de Ambientes de Desarrollo

Este documento establece la organización, definición y flujo de trabajo de los ambientes de desarrollo que utilizamos para gestionar y mantener el código fuente de nuestros proyectos. El objetivo principal es asegurar la calidad del código, minimizar conflictos y facilitar despliegues seguros y organizados.

1. Uso de Forks Personales​

Para mantener el repositorio principal limpio y evitar modificaciones accidentales, cada desarrollador deberá trabajar utilizando forks personales del repositorio principal. Esto facilita una gestión ordenada del código y minimiza riesgos en el proyecto base.

2. Ambientes y Recursos Compartidos​

Cada ambiente tiene sus propios recursos específicos (por ejemplo: bucket S3, base de datos, pools de usuarios), pero sus objetivos son claramente diferenciados:

2.1 Ambiente de Producción​

  • Rama: production
  • Objetivo: Mantener el código final en operación, utilizado directamente por los usuarios finales.
  • Uso: Solo recibe cambios desde la rama stage, que ya han sido revisados, probados y aprobados exhaustivamente.

2.2 Ambiente de Stage​

  • Rama: stage
  • Objetivo: Servir como réplica exacta del ambiente de producción para realizar validaciones y pruebas finales antes del despliegue definitivo.
  • Uso: Se actualiza al cierre de cada sprint o cuando se requiera una validación adicional antes de producción.

2.3 Ambiente de Desarrollo (Compartido)​

  • Ramas: develop, ramas específicas para Features o US y forks personales.
  • Objetivo: Ambiente colaborativo donde se desarrollan nuevas funcionalidades y correcciones, se realizan pruebas iniciales y revisiones frecuentes.
  • Uso: Desarrollo iterativo, integración continua y validaciones preliminares.

3. Flujo de Integración del Código​

3.1 De Fork Personal a Rama US​

  • Pull Request: Fork personal → Rama de Feature (US)
  • Objetivo: Realizar una revisión profunda del código, asegurar su calidad y prevenir conflictos con otras tareas en desarrollo.

3.2 De Rama US a Desarrollo​

  • Pull Request: Rama de Feature (US) → develop (cuando la historia esté marcada como lista para desplegar)
  • Objetivo: Integrar funcionalidades validadas y probadas en la rama compartida develop, asegurando que estén listas para integraciones posteriores.

3.3 De Desarrollo a Stage​

  • Integración: develop → stage (al cierre de cada sprint)
  • Objetivo: Consolidar y validar intensamente el código antes del despliegue a producción, realizando pruebas exhaustivas y finales en un ambiente estable y representativo.

3.4 De Stage a Producción​

  • Integración: stage → production (dos semanas posteriores al cierre del sprint)
  • Objetivo: Realizar el despliegue seguro y definitivo del código, habiendo asegurado previamente todas las validaciones en el ambiente stage.

4. Alternativa Simplificada (Opcional)​

  • Ambientes: Producción y Ambiente de Desarrollo Compartido
  • Objetivo: Simplificar la gestión de recursos utilizando un ambiente compartido para desarrollo, pruebas iniciales y validaciones preliminares.
  • Inicialmente esta versión simplificada es la que se usará en la mayoría de los proyectos

5. Gestión Avanzada de Defectos y Funcionalidades Críticas​

Para asegurar estabilidad y consistencia en todos los ambientes, la gestión de defectos y funcionalidades críticas debe seguir un proceso riguroso:

  • Corrección Inicial:
    • Las correcciones iniciales de defectos o funcionalidades críticas se integran primero en la rama develop.
  • Validación Exhaustiva:
    • Realizar pruebas detalladas y exhaustivas en el ambiente compartido para asegurar que los cambios no generan conflictos ni efectos secundarios inesperados.
  • Transferencia Controlada:
    • Luego de ser validadas, estas correcciones se trasladan mediante cherry-picks y Pull Requests específicos desde develop hacia los ambientes de stage y, finalmente, production.
    • Cada transferencia debe documentarse detalladamente para facilitar su rastreabilidad y auditoría.
  • Consistencia en Ambientes:
    • Mantener un registro riguroso y constante de los cambios aplicados en cada ambiente para evitar divergencias funcionales y garantizar uniformidad en la experiencia final del usuario.