cas2010 gestion-agil-de-la-configuracion

Haciendo realidad la agilidadHaciendo realidad la agilidad

Gestión ágil de la configuración

Jose Luis Soria Teruel© flioukas Jose Luis Soria Terueljlsoria@plainconcepts.comProject 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/