¿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 endevelopcomo 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.