Skip to main content

Estrategia de Repositorios y Branching

1. Estrategia de Branching (GitFlow Adaptado)​

La organización adopta un modelo de GitFlow modificado para sincronizarse de manera eficiente con los entornos de ejecución (DEV, UAT, PROD).

  • main: Contiene el código de producción. Solo recibe fusiones de ramas release/* o hotfix/*.
  • release/v*.*.*: Ramas de congelamiento de código destinadas a pruebas en el entorno de UAT.
  • develop: Rama principal de integración para el entorno de desarrollo.
  • feature/*: Desarrollo de nuevas capacidades. Nace de develop y se reintegra a develop.
  • hotfix/*: Corrección de errores críticos en producción. Nace de main y se integra de inmediato a main y develop.
  • bugfix/*: Parche de bugs detectados durante el ciclo de pruebas en UAT. Nace de release/* y se reintegra a la misma.

Flujo de trabajo​

Desarrollo (DEV) → Certificación (UAT) → Producción (PROD)

feature/*
      │
      ▼
 develop (DEV)
      │
      ▼
release/v1.0.0 (UAT)
      │
      ├── bugfix/*
      │        │
      │        ▼
      └────────┘
           │
           ▼
      release/v1.0.0
           │
           ▼
      main (PROD)
           │
           └── hotfix/*
                 │
                 ├──► main
                 ├──► develop
                 └──► release (si existe)

Flujo operativo

1. Desarrollo​

  • Cada nueva funcionalidad se desarrolla en una rama feature/*.
  • La rama feature/* siempre se crea a partir de develop.
  • Una vez concluido el desarrollo y aprobada la revisión de código, se fusiona nuevamente en develop.

2. Integración (DEV)​

  • La rama develop representa el ambiente de Desarrollo (DEV).
  • Aquí se integran todas las funcionalidades aprobadas.
  • Se ejecutan validaciones automáticas mediante los pipelines de CI/CD.

3. Certificación (UAT)​

  • Cuando la versión está lista para certificación se crea una rama:
release/vX.Y.Z
  • Semántica de Versionado (Semantic Versioning)
vX.Y.Z
│ │ │
│ │ └── Z = Patch (Corrección de errores o ajustes menores)
│ └──── Y = Minor (Nuevas funcionalidades compatibles)
└────── X = Major (Cambios mayores o incompatibles)
ElementoNombreDescripción
vPrefijo de versiónIndica que el identificador corresponde a una versión del software.
XMajorSe incrementa cuando existen cambios importantes o incompatibles con versiones anteriores (breaking changes).
YMinorSe incrementa cuando se agregan nuevas funcionalidades sin afectar la compatibilidad con versiones anteriores.
ZPatchSe incrementa cuando únicamente se corrigen errores, vulnerabilidades o se realizan ajustes menores sin agregar nuevas funcionalidades.

Ejemplo:

release/v1.4.0

Durante esta etapa:

  • No se agregan nuevas funcionalidades.
  • Solo se permiten correcciones de errores detectados durante UAT.
  • Todas las correcciones se realizan mediante ramas bugfix/*.

Ejemplo:

bugfix/error-calculo-impuestos

Estas ramas:

  • nacen desde release/*
  • regresan únicamente a release/*

4. Liberación a Producción​

Una vez obtenidas todas las aprobaciones funcionales y técnicas:

  • La rama release/* se fusiona hacia main.
  • Se genera el tag correspondiente de versión.
  • Se despliega al ambiente de Producción.

Ejemplo:

release/v1.4.0
        │
        ▼
main

5. Correcciones urgentes (Hotfix)​

Cuando se presenta un incidente crítico en Producción:

  1. Se crea una rama hotfix/* desde main.

Ejemplo:

hotfix/error-facturacion

  1. Se desarrolla y valida la corrección.

  2. Una vez aprobada, el cambio debe fusionarse en:

  • main
  • develop
  • release/* (si existe una versión abierta en UAT)

Esto garantiza que todos los ambientes permanezcan sincronizados y evita que una corrección de Producción se pierda en futuras liberaciones.

Reglas generales

  • Todo cambio debe realizarse mediante Merge Request (MR).
  • No se permiten cambios directos sobre las ramas protegidas.
  • Todo Merge Request debe contar con las aprobaciones definidas por la organización.
  • Todos los Merge Request deben ejecutar exitosamente el pipeline de CI/CD antes de ser aprobados.
  • Las ramas main, develop y release/* deben permanecer protegidas.
  • Las ramas feature/*, bugfix/* y hotfix/* son temporales y deberán eliminarse una vez completada su integración.

Beneficios del modelo

  • Separación clara entre Desarrollo, Certificación y Producción.
  • Mayor estabilidad durante las pruebas de UAT.
  • Reducción del riesgo de liberar funcionalidades no certificadas.
  • Correcciones controladas durante la fase de certificación.
  • Sincronización entre todos los ambientes mediante el flujo de hotfix.
  • Mejor trazabilidad de cambios y versiones.
  • Facilita auditorías y control de versiones.
  • Compatible con estrategias de CI/CD, GitOps y despliegues automatizados.

Resumen del flujo

                    +----------------+
                    |   feature/*    |
                    +-------+--------+
                            |
                            ▼
                    +----------------+
                    |    develop      |
                    |      DEV        |
                    +-------+--------+
                            |
                            ▼
                  +--------------------+
                  | release/vX.Y.Z     |
                  |       UAT          |
                  +---------+----------+
                            ▲
                            │
                    +-------+--------+
                    |    bugfix/*    |
                    +----------------+
                            |
                            ▼
                    +----------------+
                    |      main      |
                    |      PROD      |
                    +-------+--------+
                            ▲
                            │
                    +-------+--------+
                    |    hotfix/*    |
                    +----------------+
                            │
             ┌──────────────┼──────────────┐
             ▼              ▼              ▼
          main          develop      release/*