cas2010 gestion-agil-de-la-configuracion
TRANSCRIPT
Haciendo realidad la agilidadHaciendo realidad la agilidad
Gestión ágil de la configuración
Jose Luis Soria Teruel© flioukas Jose Luis Soria [email protected] Management Team LeadCSM
¿Qué es la gestión de la configuración?
• Gestión de cambios en los proyectos de software• 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…
¿Qué es el control de versiones?
• Gestión de cambios sobre el código fuente
• Funcionalidad:• 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 estrategiaestrategia
Manifiesto ágil vs. SCM
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
Principios ágiles vs. SCM
Software que funciona es la principal medida de progresoprogreso
La estrategia de SCM debe permitir mantener siempre una versión funcional del software
Principios ágiles vs. SCM
Entrega temprana, continua de software con valor
Entregamos software frecuentementeEntregamos software frecuentemente
La estrategia SCM debe permitir liberar versiones rápidamente, sin grandes esfuerzos
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
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
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
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
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
Conceptos de control de versiones
• Repositorio: almacén del código actual y del histórico• 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 incorporan al repositorio en una misma operación (checkin)
• Espacio de trabajo local (workspace): copia local del repositorio donde trabaja cada desarrollador
Conceptos de control de versiones
• Checkout: creación de una copia editable local, • 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
•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
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 • 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 hacer directamente sobre la línea principal
• Todo el que aporte código a esta línea, es responsable de que siga funcionando correctamente
Ramas• Inicialmente contienen lo mismo
que la línea padre, pero pasan a evolucionar independientementeevolucionar independientemente
• Aunque quedan vinculadas para facilitar combinaciones
• Usos:
• Protección de una línea de código
• Desarrollo en paralelo• Desarrollo en paralelo
• Archivado y salvaguarda
Estrategia SCM básica
DEVELOPMENTDEVELOPMENT
TRUNK
Bra
nch
RELEASE
Bra
nch
Desarrollo
versiones
Liberaciónde
versionesMer
geM
erge
RELEASE
Formalizando la estrategia
• Modelo de aislamiento
•• Promoción de código
• Políticas de rama, criterios de promoción
• Responsables de ramas
• Permisos• Permisos
Modelo de aislamiento
• Define la estructura de ramas
• La introducción de cambios correspondientes a • 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
Modelo de aislamiento
DEVELOPMENTDEVELOPMENT
TRUNKB
ranc
h
RELEASEB
ranc
hRELEASE
Modelo de aislamiento
Origen ↓↓↓↓ Destino →→→→ DEVELOPMENT TRUNK RELEASEOrigen ↓↓↓↓ Destino →→→→ DEVELOPMENT TRUNK RELEASE
DEVELOPMENT
TRUNK Al comenzar el desarrollo de una historia de usuario nueva
Cuando se va a liberar una versión en producción
RELEASE Para parches o hotfixes
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 • 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)
Promoción de código
DEVELOPMENTDEVELOPMENT
TRUNKB
ranc
h
RELEASE
Bra
nch
Mer
geM
erge
RELEASE
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
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)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
Políticas de ramas, criterios de promoción
Origen ↓↓↓↓ Destino →→→→ DEVELPOMENT TRUNK RELEASE
DEVELOPMENT CI, UT, IT, RT, SA, DEVELOPMENT CI, UT, IT, RT, SA, UAT-B
TRUNK CI, UT, IT, RT, SA, UAT-E
CI, UT, IT, RT, SA,UAT-E, LT, ST
RELEASE CI, UT, IT, RT, SA, UAT-E
CI, UT, IT, RT, SA, 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•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
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 • 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 rotasrotas
• 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!!!
Responsables de ramas
RAMA RESPONSABLERAMA RESPONSABLERAMA RESPONSABLERAMA RESPONSABLERAMA RESPONSABLERamas de desarrollo
Rama Principal
Ramas de versiones liberadas
RAMA RESPONSABLERamas de desarrollo EquipoRama Principal
Ramas de versiones liberadas
RAMA RESPONSABLERamas de desarrollo EquipoRama Principal Equipo, QA
Ramas de versiones liberadas
RAMA RESPONSABLERamas de desarrollo EquipoRama Principal Equipo, QA
Ramas de versiones liberadas Release manager
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 disponiblesdisponibles
Permisos
RAMA
Desarrollo Principal Versiones liberadas
RAMA
Desarrollo Principal Versiones liberadas
RAMA
Desarrollo Principal Versiones liberadas
RAMA
Desarrollo Principal Versiones liberadas
RAMA
Desarrollo Principal Versiones liberadasDesarrollo Principal Versiones liberadas
ROL
CI = commit / checkinCO = checkoutLBL = label, etiquetado
Desarrollo Principal Versiones liberadas
ROL
Equipo R, CI, CO, LBL, GP R R
Desarrollo Principal Versiones liberadas
ROL
Equipo R, CI, CO, LBL, GP R R
QA R R, CI, CO, LBL, GP R
Desarrollo Principal Versiones liberadas
ROL
Equipo R, CI, CO, LBL, GP R R
QA R R, CI, CO, LBL, GP R
Release managers R R R, CI, CO, LBL, GP
Desarrollo Principal Versiones liberadas
ROL
Equipo R, CI, CO, LBL, GP R R
QA R R, CI, CO, LBL, GP R
Release managers R R R, CI, CO, LBL, GP
Product owner, gallinas R R R
LBL = label, etiquetadoGP = gestión de permisos
Estrategia equipo Scrum
HISTORIA 3
HISTORIA 1
TRUNK
Bra
nch
HISTORIA 2B
ranc
h
Mer
ge
Mer
ge
Mer
ge
Mer
ge
Mer
ge
Mer
ge
Mer
ge
Mer
ge
Mer
ge
Bra
nch
RELEASE
Bra
nch
Mer
ge
Revisando el concepto de completado: equipo Scrum + QA
DEVELOPMENT
TRUNK
Bra
nch
Bra
nch
Mer
ge (
copi
a)
Mer
ge
Mer
ge
Mer
ge (
copi
a)
Mer
geM
erge
RELEASE
Bra
nch
Mer
ge
Liberando versionesDEVELOPMENT
Bra
nch
TRUNK
Bra
nch
v1
Bra
nch
Bra
nch
Bra
nch
Mer
ge(b
asel
ess)
RELEASE v2
v3
(bas
eles
s)
¡Antipatrones!
• Merge Paranoia – evitar las combinaciones por miedo a las consecuencias
• Merge Mania, Never-Ending Merge – pasar mucho tiempo combinando, en lugarde desarrollandode 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
¿Cumplimos los principios?
• Mantener siempre una versión funcional del software
• Liberar versiones rápidamente, sin grandes esfuerzos• 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 • 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
¿Cumplimos los principios?
Mantener siempre una versión funcional del software
Liberar versiones rápidamente, sin grandes esfuerzosLiberar versiones rápidamente, sin grandes esfuerzos
Mantenimiento de la línea principal, de los criterios de promoción, responsables y permisos
¿Cumplimos los principios?
Introducción de cambios en la base de código en cualquier momentoen cualquier momento
Mantenimiento de las líneas de desarrollo
¿Cumplimos los principios?
Adopción de buenas prácticas como la integración continua, las revisiones de código, la continua, las revisiones de código, la refactorización y test driven development
Criterios de promoción, ramas de desarrollo, construcciones automatizadas por rama
¿Cumplimos los principios?
Favorecer la reutilización de técnicas, prácticas y artefactos utilizados sobre la base de códigoartefactos utilizados sobre la base de código
Promoción de código entre ramas, construcciones automatizadas
¿Cumplimos los principios?
Ser una ayuda al equipo, y no suponer un problemaproblema
Diseño de una buena estrategia de scm. Atención a las herramientas
Demos: herramientas
• Control de versiones ágil centralizadoágil centralizado
• Control de versiones ágil distribuido
¿Preguntas?
¡¡¡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://branchingguidance.codeplex.com/
• http://tfsbranchingguideiii.codeplex.com/