Sobes.tech
Junior

¿Qué rama utilizas para aplicar cambios en el entorno de prueba de desarrollo?

sobes.tech AI

Respuesta de la IA

develop o una rama especializada de características/bugs, que luego se fusiona en develop.

Opciones:

  • develop: Rama principal de desarrollo, donde se integran todas las nuevas funciones y correcciones. Ideal para integración continua y pruebas de los últimos cambios.
  • Ramas de Feature/Bugfix: Para funciones grandes o correcciones urgentes, se pueden usar ramas separadas. Después de completar el trabajo, se fusionan en develop. Las pruebas en el entorno de prueba pueden realizarse tanto después de la fusión en develop como desde la propia rama, dependiendo del proceso.

La elección de la estrategia específica depende de la estrategia de ramificación adoptada por el equipo (Gitflow, Trunk-Based Development, etc.) y la configuración de los pipelines CI/CD. En la mayoría de los casos, el entorno de prueba despliega automáticamente los cambios desde la rama develop en cada commit.

Ejemplo de configuración CI/CD (Jenkins Groovy Script):

// Pipeline que se activa en cada commit en la rama develop
pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        stage('Build') {
            steps {
                sh './build.sh' // Construcción de la aplicación
            }
        }
        stage('Deploy to Dev Test') {
            when {
                branch 'develop' // Solo desplegar desde develop
            }
            steps {
                sh './deploy_to_dev_test.sh' // Despliegue en entorno de prueba
            }
        }
        stage('Run Automated Tests') {
            steps {
                // Ejecución de pruebas UI/API en entorno de prueba
                sh './run_automated_tests.sh'
            }
        }
    }
}

Ejemplo de configuración CI/CD (GitLab CI/CD):

# gitlab-ci.yml
stages:
  - build
  - deploy
  - test

build:
  stage: build
  script:
    - ./build.sh # Construcción de la aplicación

deploy_dev_test:
  stage: deploy
  only:
    - develop # Solo desplegar desde develop
  script:
    - ./deploy_to_dev_test.sh # Despliegue en entorno de prueba

run_automated_tests:
  stage: test
  script:
    - ./run_automated_tests.sh # Ejecución de pruebas UI/API
  needs: ["deploy_dev_test"] # Ejecutar después del despliegue exitoso

En caso de usar ramas de feature, el pipeline puede configurarse para desplegar entornos temporales para pruebas de esas ramas:

Ejemplo de GitLab CI/CD con entornos dinámicos:

# gitlab-ci.yml
stages:
  - build
  - deploy
  - test
  - cleanup

build:
  stage: build
  script:
    - ./build.sh

deploy_feature_env:
  stage: deploy
  except:
    - develop
    - main
  script:
    - ./deploy_dynamic_env.sh $CI_COMMIT_REF_SLUG # Despliegue de entorno temporal
  environment:
    name: review/$CI_COMMIT_REF_SLUG # Nombre dinámico del entorno
    url: http://$CI_COMMIT_REF_SLUG.test.example.com # URL del entorno
    on_stop: cleanup_feature_env

run_feature_tests:
  stage: test
  except:
    - develop
    - main
  script:
    - ./run_tests_on_dynamic_env.sh http://$CI_COMMIT_REF_SLUG.test.example.com

cleanup_feature_env:
  stage: cleanup
  variables:
    GIT_STRATEGY: none
  script:
    - ./cleanup_dynamic_env.sh $CI_COMMIT_REF_SLUG
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop

De esta forma, para el entorno de desarrollo, generalmente se usa la rama develop, que garantiza la prueba continua de los últimos cambios. Dependiendo del proceso, también se pueden usar ramas de feature o bugfix para pruebas específicas.