Ingeniería de Software II

Transcripción

1 Ingeniería de Software II Primer Cuatrimestre de 2009 Clase 17 - Patrones y Líneas de Cambio en SCM Buenos Aires, 1 de Junio de 2009

2 Línea de Cambio y sus Componentes Definición: Un codeline es la progresión del conjunto de archivos de código y otros artefactos que comprenden un producto de software a medida que este cambia a lo largo del tiempo. Cada vez que cambie un archivo, se crea una revisión en el sistema de control de versiones. Un codeline contiene todas las versiones de cada artefacto en un camino evolutivo.

3 Workspace poblado desde multiples líneas de cambio

4 Branching de un archivo y merge con el Trunk

5 Branching de una nueva linea de código

6 Diagramas de Línea de Código y Branching Start of Codeline Version Change task Branch / Merge Policy Label

7 Diagrama de Notación de Líneas de Código

8 PATRONES

9 Relación entre los Patrones Workspace-related patterns Codeline-related patterns

10 Workspace-related patterns PRIVATE WORKSPACE (6) REPOSITORY (7) PRIVATE SYSTEM BUILD (8) INTEGRATION BUILD (9) TASK LEVEL COMMIT (11) SMOKE TEST (13) UNIT TEST (14) REGRESSION TEST (15) THIRD PARTY CODELINE (10)

11 Codeline-related patterns MAINLINE (4) ACTIVE DEVELOPMENT LINE (5) CODELINE POLICY (12) PRIVATE VERSIONS (16) RELEASE LINE (17) RELEASE-PREP CODE LINE (18) TASK BRANCH (19)

12 WORKSPACE RELATED PATTERNS

13 Pattern language for Workspace-related patterns Private Worspace (6) Repository (7) Integration Build (8) Private System Build (8) Task Level Commit (11) Smoke Test (13) Unit Test (14) Regression Test (13)

14 Private Worspace (6) Propósito: poder modificar el código sin afectar el trabajo de otros, y poder gestionar la frecuencia en la cual el cambio de otros nos afecta a nosotros. El desarrollo en un entorno colaborativo implica: Escribir y probar mis modificaciones al código. Integrar mi código con el trabajo hecho por otros miembros del equipo. Integración continua vs integración deferida

15 Private Worspace (6) propuesta Utilizar un área privada (workspace) para controlar las versiones que son vinculadas con tu trabajo. De este modo uno tiene control sobre cuándo y cómo cambia el entorno. Actualizar el workspace Hacer cambios vinculados con mi actividad Hacer un Private System Build (8) Probar los cambios con Unit Test (14) Actualizar el workspace a la última versión de los componentes que uno no ha cambiado. Rebuild. Ejecutar un Smoke Test (13)

16 Repository (7) Propósito: tener un único punto de acceso para nuestros artefactos y hacer simple para el desarrollador poblar su Workspace a partir de los componentes correctos. El mecanismo para crear el private workspace debe ser repetible. Debe ser posible poblar el private workspace desde cualquier revisión.

17 Poblado del WS desde el repositorio Debemos poder reproducir cualquier revision Tener un único punto de acceso, o un repositorio, para el código y los artefactos relacionados. Hacer de la creación del workspace por parte del desarrollador, tan simple y transparente como sea posible.

18 Task Level Commit (11) Propósito: conservar consistencia entre revision history y las tareas de los desarrolladores. Identificar el nivel de tarea que queremos seguir (transacción). Tradeoff entre rollback tarea y overhead checkin. Una tarea puede ser: Problem report. Changing calls sobre un método deprecado. Refactoring. Un requerimiento de nueva funcionalidad.

19 CODELINE RELATED PATTERNS

20 Mainline (4) Propósito: mantener la cantidad de codelines activo en un numero manejable e impedir que el árbol de versiones se vuelva excesivamente ancho y muy denso. Un branch es una configuración del sistema que es derivado desde, y desarrollado independientemente de la configuración base Deseo aislar mis cambios del resto del equipo Tradeoff con el costo de integración (merge)

21 Merge desde multiples fuentes

22 Branching en cascada Derivative model Promotional model

23 Mainline (4) - Consejos Balancear la libertad de hacer un branch con el costo que encontraremos al resincronizar. El mainline es el home codeline. Solo en situaciones excepcionales no lo usamos para nuestro desarrollo. Reducimos así los sub-branches y controlamos que el árbol no se haga demasiado ancho. Todo branch es un dead codeline o termina en un merge contra el mainline. Cuando llegue el momento de crear un nuevo release, armar el branch desde el mainline haciendo los merge que correspondan para permitir esto.

24 Mainline development

25 Mainline (4) - Resumen Ventajas Reducimos costos de merge y re-sincornización. El mainline provee clausura al traer todos los cambios que deben persistir hacia el conjunto global de trabajo en lugar de dejar los cambios esparcidos a lo largo del árbol de branching. Limitar branching a: Customer releases. Long-lived parallel efforts Integration

26 Active Development Line (5) Propósito: balancear estabilidad y progreso. Para contar con progreso como equipo, requerimos identificar puntos de sincronización. Cada sincronización produce demoras al conjunto del equipo. Cada sincronización es plausible de romper la estabilidad del codeline. El aislamiento y el cambio concurrente hacen que sea posible que aunque mi espacio sea estable, no lo sean mis cambios combinados con el que fue introducido un momento antes al codeline.

27 Tests de larga duración hechos de manera aislada Estable pero poco flexible codeline Activa pero inestable codeline

28 Active dev line (5) Aspectos a considerar sobre el balance de la línea activa: Quién usa el codeline? Cuál es el ciclo de release? Qué mecanismos de test tenemos? Cuál es la evolución esperada de la misma? Cuál es el costo de romper el codeline?

29 Active dev line (5) - resumen Comprenda el ritmo del proyecto. Recurring, predictable, exchange of work products Cuanto mas exhaustivo el test, mayor el tiempo pre check-in. Identificar la estabilidad real requerida Existe una gran diferencia entre un codeline cercano al release que uno con gran actividad de cambio

30 Codeline Policy (12) Propósito: establecer el propósito del codeline de modo de entender sobre qué codeline y cuándo se debe hacer el check-in, y qué actividades de test previas son requeridas. Cada codeline tiene un propósito y una estabilidad asociada. Los desarrolladores deben entender sobre cuál de ellas trabajar, Es requerido crear una nueva cuando aparecen actividades no contempladas que ponen en riesgo los codelines existentes.

31 Posibles políticas de codeline Mantenimiento Código que debe persistir en futuras versiones No tenemos control de cambio pero si de check-in

32 Codeline Policy (12) Definir reglas de juego: El tipo de trabajo encapsulado por el codeline: desarrollo, mantenimiento, clean-up Cómo y cuándo los elementos deberían ser incorporados (check-in), extraídos (check-out), branched y merged Restricciones de acceso para individuos, roles y grupos. Relaciones esperadas de Import/export: codelines desde las cuales se espera recibir cambios, y aquellas hacia las cuales debemos propagarlos. Duración o condiciones para retirar la línea de cambio. La carga esperada de actividades y frecuencia de integración.

33 Codeline Policy (12) Ejemplos Development line: cambios intermedios deben incorporarse (check-in); componentes afectados deben ser buildables Release codeline: el build debe pasar el test de regresion antes del check-in; check-in limitado a bug fixes; luego del check-in el branch es congelado hasta pasar QA activities Mainline: todos los componentes deben compilar, vincularse y pasar test regresivos; nuevas funciones completadas y testeadas deben incorporarse

34 Release line (17) Propósito: realizar mantenimiento sobre released versions sin interferir con la actividad de desarrollo. Una vez liberado el producto, este debe evolucionar independientemente del desarrollo del mismo. Es una necesidad corregir un bug sobre un producto liberado. Los tiempos de corrección de bug no son compatibles con los tiempos de desarrollo. La calidad de código de mantenimiento no es la misma que la calidad de las futuras versiones (mainline). Los bug fixes deben ser incorporados (merge) al mainline.

35 Realizar un branch antes del release Haciendo todo el trabajo sobre el mainline Creando un branch cuando liberamos

36 Release line (17) Separar mantenimiento/release y desarrollo activo en codelines independientes. Mantener un codeline de release por versión liberada que este bajo contrato de mantenimiento. Propague bug-fixes sobre el codeline padre en cascada hacia el mainline.

37 Considerar usar un release principal sobre el cual gestiono diferentes clientes Merge todo bug-fix sobre el mainline.

38 Release-Prep Code Line (18) Propósito: estabilizar el codeline de un inminente release mientras que permitimos que comience el desarrollo sobre el nuevo release. Antes que el release esté listo para ser entregado hay una gran cantidad de trabajo por hacer de último momento. Bug-fixes de último momento. Packaging Clean-up work Considerar el momento de hacer esto puesto que el trabajo de bux-fixing debe ser acotado debido al merge posterior requerido contra el mainline.

39 Release-Prep Code Line (18) En lugar de hacer el branch inmediatamente despues de release, branch antes del release. Esto evita el freeze sobre el active dev line Crear una linea separada para integracion y clean-up del release y permitir que la actividad de cambio continúe sobre la active dev line. Balancear el momento de hacer el release-prep codeline. Recordar que deberemos hacer merge sobre la mainline si son bug-fixes.

40 Previo al Release Line debemos preparar el active dev line para la entrega

41 Task Branch (19) Propósito: permitir que una parte del equipo realice múltiples cambios de largo plazo al codeline sin comprometer la integridad y consistencia del mainline. Algunos de los cambios no deben ser integrados al trabajo del resto del equipo hasta que no estén completos. Tareas de gran impacto global (refactoring) Tareas que deben ser compartidas solo por parte del equipo. Tareas de largo plazo.

42 Task Branch (19) Utilizar task branch para promover aislación: Reducir el riesgo de inestabilidad en tareas de larga data. Utilizar policy codeline para asegurar incorporar cambios del active dev line Utilizar policy para especificar los momentos de merge-back. Utilizar task branch para actividades de integración que preveemos serán complicadas

43 Task Branch Update from active dev line

44 Gracias