1.
Manual de Gestión de Código para el Proyecto ROVIS en Azure
DevOps
Objetivo:
Establecer una estrategia clara y profesional para la gestión del código fuente en el proyecto
ROVIS utilizando Git dentro de Azure DevOps, alineado con la estructura de entregables por
Work Packages (WP).
1. Estructura de Ramas Git
Tipo de Rama Nombre Ejemplo Descripción
Principal main Rama estable de producción
Desarrollo develop Rama de integración
continua (pre-producción)
Releases release/WP1 Una por cada bloque
funcional entregable
Features feature/r1-formulario Por funcionalidad específica
Hotfix hotfix/correcion-R1 Correcciones urgentes
Comandos iniciales:
git checkout -b develop
git push -u origin develop
# Crear una rama de funcionalidad
git checkout develop
git checkout -b feature/r1-formulario
git push -u origin feature/r1-formulario
2. Políticas de Pull Requests (PR)
En Azure DevOps > Repos > Branches:
- Habilitar revisiones obligatorias para develop y main
- Requerir validación de QA o funcional si aplica
- Integrar con pipelines de CI/CD si existen
- Bloquear push directo a main
3. Integración con Azure Boards
Vincula commits con tareas funcionales:
git commit -m "feat: validación tasas formulario R4 #AB123"
4. Cierre de Work Package (WP)
# Crear rama de release
git checkout develop
git pull
git checkout -b release/WP1
git merge develop
git push -u origin release/WP1
# Finalizar entrega y pasar a main
git checkout main
git merge release/WP1
git tag v1.0-WP1
git push origin main --tags
5. Convenciones de Commits
- feat: Nueva funcionalidad
- fix: Corrección de bug
- chore: Cambio menor (actualización de librerías, refactor)
- docs: Documentación
6. Plantilla de Pull Request (PR)
- Qué se ha hecho: Breve descripción
- Cómo se prueba: Pasos de validación
- Relación con el WP: Ej. WP1 - Formularios R1 y R4
- Evidencias: Capturas, enlaces, etc.
7. Buenas Prácticas
- No trabajar directamente en main
- Las ramas release/WPx deben estar protegidas
- Toda funcionalidad debe pasar por revisión técnica y/o funcional antes de merge
– Documentar en el Wiki del proyecto las decisiones y cambios importantes
Presentación: Gestión del Código y Estructura de Ramas en Azure DevOps - Proyecto
ROVIS
? Objetivo
Establecer una metodología clara, colaborativa y trazable para la gestión del código en el
proyecto ROVIS, utilizando Git en Azure DevOps como repositorio central.
? Estrategia de Ramas Git (GitFlow Adaptado)
Rama Uso Principal
main Código estable desplegado en producción
develop Rama de integración funcional continua
release/WPx Consolidación de cada Work Package para entrega
feature/... Ramas individuales por funcionalidad o formulario
hotfix/... Correcciones urgentes sobre producción
? Ciclo de Trabajo por Work Package
1. Partimos de develop
2. Creamos ramas feature/... para cada nueva funcionalidad
3. PR hacia develop una vez finalizada (con revisión técnica y funcional)
4. Se agrupa todo en release/WP1, release/WP2, etc.
5. Una vez validado por QA, se fusiona en main
6. Se etiqueta el hito: v1.0-WP1, v2.0-WP2, etc.
? Políticas de Repositorio
• Protección de main (no push directo)
• PRs obligatorios en develop y release/*
• Revisión por al menos 1 persona (técnica o funcional)
• Asociación obligatoria a Work Item de Azure Boards
• Posibilidad de automatizar validaciones con pipelines
? Vinculación con Azure Boards
• Todos los commits deben referenciar la tarea:
git commit -m "feat: Integración tasas en R1 #AB103"
• Las PRs deben enlazarse a Features o Tasks de WP correspondientes.
• Esto permite trazabilidad completa y seguimiento funcional.
? Plantilla de Pull Request (PR)
### ✅ Qué se ha hecho
- Implementación del formulario R4
### ? Cómo se prueba
- Introducir datos, validar tasas, firmar y guardar
### ⚖️ Relación con WP
- WP1: Altas y validación básica
### ? Evidencias
- Captura o enlace a entorno de pruebas
? Convenciones de Commit
• feat: Nueva funcionalidad
• fix: Corrección
• chore: Refactor o limpieza
• docs: Cambios de documentación
? Propuesta de Acción
1. Validar esta estrategia como modelo oficial de trabajo
2. Crear ramas base (main, develop, release/WP1)
3. Publicar el manual en el Wiki o repo compartido
4. Lanzar sesión de onboarding técnico (si procede)
5. Monitorizar uso correcto de ramas y PRs
Responsable: Enric Jiménez
Analista Funcional .NET - Proyecto ROVIS