1. Haciendo realidad la agilidad
Gestión ágil de la configuración
© flioukas Jose Luis Soria Teruel
jlsoria@plainconcepts.com
Project Management Team Lead
CSM

2. ¿Qué es la gestión de la
configuración?
• Gestión de cambios en los proyectos de software
• Procedimientos:
• Identificación
• Control de cambios
• Control de estado
• Auditorías
• No afecta sólo al código fuente: requerimientos, arquitectura y diseño,
pruebas, ejecutables…

3. ¿Qué es el control de versiones?
• Gestión de cambios sobre el código fuente
• Funcionalidad:
• Manejo de cambios efectuados por varias personas sobre la misma
base de código
• Gestión de las versiones: comparaciones, restaurar versiones
anteriores, combinación de versiones…
• Trazabilidad del momento y del origen del cambio
• No basta con elegir una herramienta, es necesario pensar en una
estrategia

4. Manifiesto ágil vs. SCM

5. Principios ágiles
• Entrega temprana y continua de software con valor
• Aceptamos requisitos cambiantes, incluso en etapas avanzadas
• Entregamos software frecuentemente
• Desarrolladores y responsables de negocio trabajan juntos diariamente
• Profesionales motivados con entorno y soporte adecuados
• Comunicación mediante conversación cara a cara
• Software que funciona es la principal medida de progreso
• Desarrollo sostenible, ritmo constante
• Atención continua a la excelencia técnica, buenos diseños
• Simplicidad, maximizar la cantidad de trabajo no realizado
• Equipos auto organizados
• Regularmente el equipo reflexiona y ajusta su comportamiento

6. Principios ágiles vs. SCM
Software que funciona es la principal medida de
progreso
La estrategia de SCM debe permitir mantener
siempre una versión funcional del software

7. Principios ágiles vs. SCM
Entrega temprana, continua de software con valor
Entregamos software frecuentemente
La estrategia SCM debe permitir liberar versiones
rápidamente, sin grandes esfuerzos

8. Principios ágiles vs. SCM
Aceptamos requisitos cambiantes, incluso en etapas
avanzadas
Desarrollo sostenible, ritmo constante
La estrategia de SCM debe permitir la introducción de
cambios en la base de código en cualquier
momento

9. Principios ágiles vs. SCM
Atención continua a la excelencia técnica, buenos diseños
La estrategia de SCM debe permitir la adopción de buenas
prácticas como la integración continua, las revisiones de
código, la refactorización y el test driven development

10. Principios ágiles vs. SCM
Simplicidad, maximizar la cantidad de trabajo no realizado
La estrategia de SCM debe favorecer la reutilización de
técnicas, prácticas y artefactos

11. Principios ágiles vs. SCM
Profesionales motivados con entorno y soporte
adecuados
La estrategia de SCM (incluyendo las herramientas)
debe ser una ayuda al equipo, y no suponer un
problema

12. Estrategia SCM ágil
• Debe permitir mantener siempre una versión funcional del
software
• Debe permitir liberar versiones rápidamente, sin grandes
esfuerzos
• Debe permitir la introducción de cambios en la base de código
en cualquier momento
• Debe permitir la adopción de buenas prácticas como la
integración continua, las revisiones de código, la refactorización
y test driven development
• Debe favorecer la reutilización de técnicas, prácticas y artefactos
utilizados sobre la base de código
• Debe ser una ayuda al equipo, y no suponer un problema

14. Conceptos de control de
versiones
• Repositorio: almacén del código actual y del histórico
• Línea base: conjunto versionado de ficheros de código
sobre los que vamos a hacer cambios
• Cambio: modificación específica sobre una línea de
código
• Lista o conjunto de cambios (changeset): los que se
incorporan al repositorio en una misma operación
(checkin)
• Espacio de trabajo local (workspace): copia local del
repositorio donde trabaja cada desarrollador

15. Conceptos de control de
versiones
• Checkout: creación de una copia editable local,
desde el repositorio al espacio de trabajo
• Commit / checkin: incorporación al repositorio
de cambios hechos en local
• Rama: copia de una línea de código que se
puede desarrollar de modo independiente
• Combinación o integración: incorporación de un
conjunto de cambios a un conjunto de ficheros,
usualmente de una rama a otra

16. Línea principal o Trunk
• Si sólo tuviésemos una línea de código,
sería ésta
• Es la única línea que no es una rama de
otra
• Las combinaciones o integraciones entre
ramas pasan por esta línea principal
• Por lo general, la línea principal contiene
el código correspondiente a
funcionalidades completadas (revisar el
concepto de completado)
• Las modificaciones correspondientes a
funcionalidades nuevas no se deben
hacer directamente sobre la línea
principal
• Todo el que aporte código a esta línea,
es responsable de que siga funcionando
correctamente

17. Ramas
• Inicialmente contienen lo mismo
que la línea padre, pero pasan a
evolucionar independientemente
• Aunque quedan vinculadas para
facilitar combinaciones
• Usos:
• Protección de una línea de código
• Desarrollo en paralelo
• Archivado y salvaguarda

18. Estrategia SCM básica
DEVELOPMENT
Desarrollo
Merge
Branch
TRUNK
Liberación
Branch
Merge
de
versiones
RELEASE

19. Formalizando la estrategia
• Modelo de aislamiento
• Promoción de código
• Políticas de rama, criterios de promoción
• Responsables de ramas
• Permisos

20. Modelo de aislamiento
• Define la estructura de ramas
• La introducción de cambios correspondientes a
funcionalidad nueva se hace en líneas distintas de
la principal (ramas)
• El concepto de completado puede condicionar el
modelo
• Toda rama tiene un dueño y una política
• Crear una rama nueva, cuando no se pueda
trabajar en una existente sin violar su política
• No combinar varias releases en una sola rama

21. Modelo de aislamiento
DEVELOPMENT
Branch
TRUNK
Branch
RELEASE

22. Modelo de aislamiento
Origen ↓ Destino → DEVELOPMENT TRUNK RELEASE
DEVELOPMENT
TRUNK Al comenzar el desarrollo Cuando se va a liberar
de una historia de una versión en producción
usuario nueva
RELEASE Para parches o hotfixes

23. Promoción de código
• Define las rutas que puede seguir el código para pasar de unas ramas a otras, y
en qué circunstancias
• Recomendable sincronizar el workspace con la rama correspondiente de forma
frecuente
• Recomendable integrar de forma frecuente los cambios introducidos en líneas de
desarrollo con la línea principal, y desde ahí a otras líneas de desarrollo
• Las combinaciones de desarrollo hacia trunk normalmente se hacen copiando el
contenido completo
• Al corregir bugs en release, siempre se debería hacer merge a trunk y desde ahí
al resto de ramas afectadas
• La forma de liberar versiones y el concepto de completado pueden condicionar la
promoción de código
• Por lo general es recomendable hacer combinaciones completas de todos los
cambios pendientes (no hacer cherry-picking)

24. Promoción de código
DEVELOPMENT
Merge
Branch
TRUNK
Branch
Merge
RELEASE

25. Promoción de código
Origen ↓ Destino → DEVELOPMENT TRUNK RELEASE
DEVELOPMENT Al completar una historia
de usuario.
Al completar un sprint
TRUNK Frecuentemente, para
integrar código procedente
de otras ramas de
desarrollo.
Resolución de errores
corregidos en Release.
RELEASE Resolución de errores Resolución de errores

26. Políticas de ramas, criterios de
promoción
• Definen qué condiciones se deben cumplir para que se puedan
aceptar cambios en una rama (procedentes de un checkin o de
una combinación)
• Por lo general, siempre aceptar desde otras ramas cambios que
aporten estabilidad (ej: bug fixes)
• No es recomendable imponer a otras ramas cambios que
introduzcan inestabilidad
• Las ramas de desarrollo sólo deben aportan cambios a su línea
base en puntos estables
• Las ramas de Release nunca deberían recibir combinaciones,
excepto de otras ramas de Release en casos muy especiales
• Recomendable utilizar mecanismos como políticas de checkin y
gated checkin o pre-tested commit

27. Políticas de ramas, criterios de
promoción
Origen ↓ Destino → DEVELPOMENT TRUNK RELEASE
DEVELOPMENT CI, UT, IT, RT, SA,
UAT-B
TRUNK CI, UT, IT, RT, SA, CI, UT, IT, RT, SA,
UAT-E UAT-E, LT, ST
RELEASE CI, UT, IT, RT, SA, CI, UT, IT, RT, SA,
UAT-E UAT-E, LT, ST, SMT,
ROL (1)
•CI = El código pasa la build de integración continua
•UT = tests unitarios
•IT = tests de integración
•RT = tests de regresión
•SA = el código pasa el análisis estático según las reglas acordadas
•UAT-B = conjunto básico de pruebas de aceptación
•UAT-E = conjunto exhaustivo de pruebas de aceptación
•LT = pruebas de carga
•ST = pruebas de seguridad
•SMT = pruebas de humo
•ROL = procedimiento documentado y probado de vuelta atrás
•(1) Referido al despliegue de los ensamblados en el entorno de producción

28. Responsables de ramas
• Aseguran el cumplimiento de la promoción de código
definida de forma regular
• Verifican que se cumplen los criterios de promoción
establecidos, antes de cada promoción de código, desde o
hacia la rama que custodian
• Coordinan y supervisan los procesos de combinación sobre
la rama
• Comprueban la buena salud de las construcciones
automatizadas (builds) de la rama, y velan por que sean
reparadas lo antes posible en el momento en que sean
rotas
• Establecen y mantienen los permisos concedidos a los
usuarios sobre la rama, según la política de permisos
definida
• ¡¡¡Toda rama debe tener un responsable!!!

29. Responsables de ramas
RAMA RESPONSABLE
Ramas de desarrollo Equipo
Rama Principal Equipo, QA
Ramas de versiones liberadas Release manager

30. Permisos
• Aseguran la integridad de cada rama
• Evitan “accidentes”
• Será necesario ajustarlos en situaciones
puntuales (por ejemplo, resolución de defectos)
• La herramienta puede condicionar los permisos
disponibles

31. Permisos
RAMA
Desarrollo Principal Versiones liberadas
Equipo R, CI, CO, LBL, GP R R
QA R R, CI, CO, LBL, GP R
ROL
Release managers R R R, CI, CO, LBL, GP
Product owner, gallinas R R R
CI = commit / checkin
CO = checkout
LBL = label, etiquetado
GP = gestión de permisos

32. TRUNK
HISTORIA 1
HISTORIA 2
Branch
Branch
Merge
Merge
Merge
Merge
Merge
Merge
Merge
RELEASE
Merge
HISTORIA 3
Branch
Branch
Merge
Merge
Estrategia equipo Scrum

33. Revisando el concepto de
completado: equipo Scrum + QA
DEVELOPMENT
Merge (copia)
Merge (copia)
Branch
Merge
Merge
Merge
TRUNK
Branch
Merge
RELEASE

34. Liberando versiones
DEVELOPMENT
Branch
TRUNK
Branch
Branch
Branch
v1
(baseless)
Merge
RELEASE v2
v3

35. ¡Antipatrones!
• Merge Paranoia – evitar las combinaciones por miedo a las consecuencias
• Merge Mania, Never-Ending Merge – pasar mucho tiempo combinando, en lugar
de desarrollando
• Big Bang Merge – dejar todas las combinaciones para el final de la iteración o del
ciclo de desarrollo
• Wrong-Way Merge – combinar una versión anterior sobre una más reciente (ojo a
las regresiones)
• Branch Mania – crear ramas sin razón aparente
• Branch en cascada – sin hacer merges posteriores hacia la línea principal
• Development freeze - congelar el desarrollo durante las actividades de
branch/merge
• Dividing Wall – usar una rama para aislar a cada miembro del equipo de
desarrollo, en lugar de ramificar por características o historias de usuario

36. ¿Cumplimos los principios?
• Mantener siempre una versión funcional del software
• Liberar versiones rápidamente, sin grandes esfuerzos
• Introducción de cambios en la base de código en
cualquier momento
• Adopción de buenas prácticas como la integración
continua, las revisiones de código, la refactorización y
test driven development
• Favorecer la reutilización de técnicas, prácticas y
artefactos utilizados sobre la base de código
• Ser una ayuda al equipo, y no suponer un problema

37. ¿Cumplimos los principios?
Mantener siempre una versión funcional del software
Liberar versiones rápidamente, sin grandes esfuerzos
Mantenimiento de la línea principal, de los criterios de
promoción, responsables y permisos

38. ¿Cumplimos los principios?
Introducción de cambios en la base de código
en cualquier momento
Mantenimiento de las líneas de desarrollo

39. ¿Cumplimos los principios?
Adopción de buenas prácticas como la integración
continua, las revisiones de código, la
refactorización y test driven development
Criterios de promoción, ramas de desarrollo,
construcciones automatizadas por rama

40. ¿Cumplimos los principios?
Favorecer la reutilización de técnicas, prácticas y
artefactos utilizados sobre la base de código
Promoción de código entre ramas, construcciones
automatizadas

41. ¿Cumplimos los principios?
Ser una ayuda al equipo, y no suponer un
problema
Diseño de una buena estrategia de scm.
Atención a las herramientas

42. Demos: herramientas
• Control de versiones
ágil centralizado
• Control de versiones
ágil distribuido

43. ¿Preguntas?

44. ¡¡¡Muchas gracias!!!
Recursos
• Version control for multiple agile teams:
http://www.infoq.com/articles/agile-version-
control
• TFS Branching Guide:
• http://branchingguidance.codeplex.com/
• http://tfsbranchingguideiii.codeplex.com/