Cas2010 gestion-agil-de-la-configuracion

957 views
787 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
957
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
47
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Cas2010 gestion-agil-de-la-configuracion

  1. 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. 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. 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. 4. Manifiesto ágil vs. SCM
  5. 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. 6. Principios ágiles vs. SCMSoftware que funciona es la principal medida de progreso La estrategia de SCM debe permitir mantener siempre una versión funcional del software
  7. 7. Principios ágiles vs. SCMEntrega temprana, continua de software con valor Entregamos software frecuentementeLa estrategia SCM debe permitir liberar versiones rápidamente, sin grandes esfuerzos
  8. 8. Principios ágiles vs. SCMAceptamos requisitos cambiantes, incluso en etapas avanzadas Desarrollo sostenible, ritmo constanteLa estrategia de SCM debe permitir la introducción de cambios en la base de código en cualquier momento
  9. 9. Principios ágiles vs. SCMAtención continua a la excelencia técnica, buenos diseñosLa 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. 10. Principios ágiles vs. SCMSimplicidad, maximizar la cantidad de trabajo no realizado La estrategia de SCM debe favorecer la reutilización de técnicas, prácticas y artefactos
  11. 11. Principios ágiles vs. SCM Profesionales motivados con entorno y soporte adecuadosLa estrategia de SCM (incluyendo las herramientas) debe ser una ayuda al equipo, y no suponer un problema
  12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. Estrategia SCM básicaDEVELOPMENT Desarrollo Merge Branch TRUNK Liberación Branch Merge de versiones RELEASE
  18. 18. Formalizando la estrategia• Modelo de aislamiento• Promoción de código• Políticas de rama, criterios de promoción• Responsables de ramas• Permisos
  19. 19. 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
  20. 20. Modelo de aislamientoDEVELOPMENT Branch TRUNK Branch RELEASE
  21. 21. Modelo de aislamientoOrigen ↓ Destino → DEVELOPMENT TRUNK RELEASEDEVELOPMENTTRUNK Al comenzar el desarrollo Cuando se va a liberar de una historia de una versión en producción usuario nuevaRELEASE Para parches o hotfixes
  22. 22. 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)
  23. 23. Promoción de códigoDEVELOPMENT Merge Branch TRUNK Branch Merge RELEASE
  24. 24. Promoción de códigoOrigen ↓ Destino → DEVELOPMENT TRUNK RELEASEDEVELOPMENT Al completar una historia de usuario. Al completar un sprintTRUNK 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
  25. 25. 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
  26. 26. 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
  27. 27. 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!!!
  28. 28. Responsables de ramasRAMA RESPONSABLERamas de desarrollo EquipoRama Principal Equipo, QARamas de versiones liberadas Release manager
  29. 29. 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
  30. 30. Permisos RAMA Desarrollo Principal Versiones liberadas Equipo R, CI, CO, LBL, GP R R QA R R, CI, CO, LBL, GP RROL 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
  31. 31. TRUNK HISTORIA 1 HISTORIA 2 Branch Branch Merge Merge Merge Merge Merge Merge MergeRELEASE Merge HISTORIA 3 Branch Branch Merge Merge Estrategia equipo Scrum
  32. 32. Revisando el concepto de completado: equipo Scrum + QADEVELOPMENT Merge (copia) Merge (copia) Branch Merge Merge Merge TRUNK Branch Merge RELEASE
  33. 33. Liberando versionesDEVELOPMENT Branch TRUNK Branch Branch Branch v1 (baseless) Merge RELEASE v2 v3
  34. 34. ¡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
  35. 35. ¿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
  36. 36. ¿Cumplimos los principios?Mantener siempre una versión funcional del softwareLiberar versiones rápidamente, sin grandes esfuerzosMantenimiento de la línea principal, de los criterios de promoción, responsables y permisos
  37. 37. ¿Cumplimos los principios?Introducción de cambios en la base de código en cualquier momentoMantenimiento de las líneas de desarrollo
  38. 38. ¿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 developmentCriterios de promoción, ramas de desarrollo, construcciones automatizadas por rama
  39. 39. ¿Cumplimos los principios?Favorecer la reutilización de técnicas, prácticas y artefactos utilizados sobre la base de códigoPromoción de código entre ramas, construcciones automatizadas
  40. 40. ¿Cumplimos los principios?Ser una ayuda al equipo, y no suponer un problemaDiseño de una buena estrategia de scm. Atención a las herramientas
  41. 41. Demos: herramientas• Control de versiones ágil centralizado• Control de versiones ágil distribuido
  42. 42. ¿Preguntas?
  43. 43. ¡¡¡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/

×