Historia de revisiones

Herbert Game Informe Final de SCM Versión 1.1 Historia de revisiones Fecha Versión Descripción Autor 17/11/2011 1.0 Creación del documento Agu

1 downloads 80 Views 373KB Size

Story Transcript

Herbert Game Informe Final de SCM Versión 1.1

Historia de revisiones Fecha

Versión

Descripción

Autor

17/11/2011

1.0

Creación del documento

Agustín Castro

20/11/2011

1.1

Revisión del documento

Federico Dadalt

Informe Final de SCM

Página 1 de 8

Contenido HERBERT GAME ..................................................................................................................................... 1 INFORME FINAL DE SCM ..................................................................................................................... 1 VERSIÓN 1.1 .............................................................................................................................................. 1 HISTORIA DE REVISIONES .................................................................................................................. 1 CONTENIDO ............................................................................................................................................. 2 1.

RESULTADOS FINALES DE SCM ................................................................................................ 3 1.1. 1.2. 1.3. 1.4.

2.

PLANIFICADO VS. REALIZADO ....................................................................................................... 3 CANTIDAD DE ERRORES ENCONTRADOS: ....................................................................................... 3 ACTIVIDADES DE CONTROL DE CONFIGURACIÓN .......................................................................... 4 ACTIVIDADES DE REVISIÓN DEL ESTADO DE LA CONFIGURACIÓN Y AUDITORÍAS ......................... 6

EVALUACIÓN FINAL ..................................................................................................................... 6 2.1. FASE INICIAL ................................................................................................................................. 7 2.1.1. Primera Iteración ................................................................................................................. 7 2.1.2. Segunda Iteración ................................................................................................................. 7 2.1.3. Tercera Iteración .................................................................................................................. 7 2.2. FASE DE ELABORACIÓN ................................................................................................................. 7 2.2.1. Primera Iteración ................................................................................................................. 7 2.3. FASE DE CONSTRUCCIÓN ............................................................................................................... 8 2.3.1. Primera Iteración ................................................................................................................. 8 2.3.2. Segunda Iteración ................................................................................................................. 8 2.4. FASE DE TRANSICIÓN .................................................................................................................... 8 2.4.1. Primera Iteración ................................................................................................................. 8

Informe Final de SCM

Página 2 de 8

1.

Resultados Finales de SCM El contenido del documento comentará sobre las mediciones de las actividades realizadas por el SCM a lo largo del proyecto. Se muestran gráficas que cuantifican lo planificado vs lo realizado así como también los errores encontrados durante el proceso. A continuación se presenta una gráfica con la dedicación horaria a la Gestión de la Configuración y Control de Cambios del proyecto Herbert Game.

1.1.

Planificado vs. Realizado Las actividades de control de cambios se desarrollaron según el plan de configuración destacando el hecho de que el proceso formal de solicitud de cambios nunca fue realizado en contraste con el proceso ágil definido en el plan que se fue dando muy seguido durante el proyecto. Esto quizás pueda ser atribuible a la elección de la arquitectura y un buen prototipo inicial los cuales provocaron que el producto no sufriera grandes cambios. En cuanto a las auditorías realizadas sobre los elementos de la línea base, las mismas fueron de carácter informal ya que el SCM participaba de cada solicitud de cambio y todas se realizaron conforme indica el plan, antes de cada liberación. Los errores encontrados fueron menores, como por ejemplo errores en el versionado de documentos, por lo que podemos decir que el plan de configuración en líneas generales fue respetado en todos sus aspectos.

1.2.

Cantidad de errores encontrados: Los errores encontrados fueron todos menores. Gracias a una buena comunicación con todo el equipo y documentos informativos no hubo problemas con la nomenclatura. Ésta fue definida al comienzo del proceso y fue respetada por los todos los integrantes. Así como también la estructura de directorios utilizada en el SVN para los distintos cometidos especificados en el Plan de Configuración. La metodología seguida para la distribución de documentos fue correctamente seguida por el Administrador, SQA y el SCM, lo que provocó que todos los

Informe Final de SCM

Página 3 de 8

integrantes pudiesen encontrar los documentos de forma rápida y efectiva (ya que los mismos siempre se encontraban donde debían estar). Luego de cada entrega el Administrador colocaba en la carpeta correcta los documentos y el SCM se encargaba de chequear que todo estuviera consistente en la línea base. Con respecto al código fuente, como fue especificado en el Plan, se utilizó VisualSVN más cierta estructura definida en el SVN (/src , /lib2 , /lib3 , /beta) la cual facilitó considerablemente la distribución/modificación y desarrollo de los fuentes. Tuvimos un solo inconveniente que fue por la mala utilización de la herramienta, uno de los integrantes realizó un commit sin hacer un previo update, lo cual provocó que se perdiera código. Se solucionó rápidamente haciendo un rollback de ese commit y luego incorporando los cambios de ese commit sobre la versión actualizada (haciendo update previamente). La línea base de fuentes siempre fue definida como la de verificación (en el SVN) en la cual no se introducían cambios. Una vez realizada una liberación el SCM realizaba un nuevo branch para continuar el desarrollo de la liberación siguiente congelando el directorio actual para verificación (no permitiendo commits via hooks de SVN). 1.3.

Actividades de Control de Configuración Como fue comentado en el punto 1.1, el proceso de control de cambios formal no se utilizó en el proceso de desarrollo por los motivos mencionados allí. Pero sí fue utilizado con mucha frecuencia el método ágil también definido en el plan de configuración. El procedimiento fue el siguiente: - El solicitante envía por medio de un email el pedido involucrando a los demás integrantes que considere necesarios (por medio de etiquetas en el asunto) - El SCM siempre era incluido en cada solicitud - Se discutía brevemente por email entre los integrantes involucrados si se aprobaba o no el cambio - El SCM aplicaba los cambios sobre la LB de documentos en el SVN. Dado que el SCM participaba de cada cambio de LB de documentos no se hicieron auditorías formales de la LB de documentos, aunque sí se revisaba antes de cada entrega que los documentos estuvieran consistentes y coherentes. A su vez el mecanismo utilizado para el control de cambios sobre la línea base del código fuente como se comentó en 1.2 fue el siguiente: - Cada vez que se obtenía una versión de la liberación ésta se congelaba, esto es que no se permitían commits, y pasaba a formar parte del branch de verificación. Cuando se realizaban todas las verificaciones, se preparaba una nueva versión de desarrollo (generando un branch nuevo) para comenzar a partir de la última versión estable. Así que cada branch de verificación suponía una versión del código fuente en la línea base. Esto era comunicado via email a todos los integrantes que en todo momento sabían en donde se estaba trabajando.

Informe Final de SCM

Página 4 de 8

Durante todo el proyecto se solicitaron 12 pedidos de cambios sobre los documentos de la Línea Base. Detallamos a continuación el número de cambio, el documento afectado junto con su línea de trabajo y el cambio de versión.

Numero cambio 1 2 3 4 5 6 7 8 9 10 11 12

Documento RQPIU RQMOD RQDRQ RQDRQ RQALS GPPLA DSOOMDA DSMID DSMID DSMID DSARQ DSARQ

Línea de trabajo Requerimientos Requerimientos Requerimientos Requerimientos Requerimientos Gestión de Proyecto Diseño Diseño Diseño Diseño Diseño Diseño

Version ant 3.0 1.8 2.1 2.4 1.2 1.6 1.1 1.1 1.6 1.8 1.4 1.8

Version sig 3.1 2.0 2.4 2.7 1.3 1.8 1.3 1.6 1.8 2.0 1.8 2.0

Vale aclarar que algunos cambios menores no fueron documentados, cómo correcciones de ortografía, redacción o similares.

A lo largo del proyecto se crearon, y por lo tanto se modificó, 4 veces la línea base del código fuente: - Versión inicial/prototipo del producto (/src) - Versión liberación 2 del producto (/lib2) - Versión liberación 3 del producto (/lib3) - Versión beta/final del producto (/beta)

Informe Final de SCM

Página 5 de 8

1.4.

Actividades de Revisión del estado de la Configuración y Auditorías No hubo mayores problemas de inconsistencias y/o errores en la línea base, igualmente los pocos que se detectaron fueron reportados en el Informe del estado de la línea base. No se realizaron auditorías de la configuración como se mencionó y argumentó en 1.3 No se realizaron revisiones técnicas formales con el SQA sobre el estado de la configuración.

2.

Evaluación Final La Gestión de la Configuración se ajustó bastante a lo planificado y plasmado en el Plan de la Configuración originalmente creado, hubo modificaciones naturales que eran necesarias y que fueron surgiendo a medida que se avanzaba en el proyecto. Creemos que es justo decir que se cumplió correctamente lo planificado y la elección de las herramientas a utilizar fueron acertadas. Por ejemplo, para el repositorio tanto de documentos como de los códigos fuente, se estuvieron evaluando distintas alternativas como Mercurial, git y codeplex. El repositorio SVN selfhosted funcionó correctamente 100% del tiempo, no hubo caídas del servicio, ni del servidor y por lo tanto tampoco hubo que recuperar datos de los backups ni del SVN secundario del cual se disponía. De las ideas y herramientas utilizadas para el desarrollo quizás la menos acertada fue la maquina virtual Windows 7 que se creó utilizando VirtualBox y que a posteriori fue distribuida entre los miembros del equipo. La idea original era tener un entorno de desarrollo idéntico para todo el equipo y que no surgieran incompatibilidades de versiones del software utilizado. Ya que fue una lista enorme de software que se instaló sumados a los altos requerimientos del software utilizado se terminó generando una máquina virtual que muy pocos integrantes podían correr debido a los altos requerimientos para correrla en el equipo host. Para tener una idea la imagen del disco duro virtual fue distribuida en 8 DVDs (30G) y el equipo virtual debía de disponer al menos de 3G de RAM asignados solamente a la máquina virtual. El resultado fue que solamente 3 personas utilizaron el entorno sobre la máquina virtual, el cual, comparado con el tiempo de dedicación para crear/instalar/configurar la máquina, sumado al tiempo de distribución, a nuestro entender no justificó la inversión. Destacamos también el esfuerzo del equipo completo a la hora de utilizar las distintas herramientas ya que, en líneas generales, se realizó correctamente y cuando no se sabía con seguridad se preguntaba antes de actuar. A continuación se detalla las actividades de SCM llevadas a cabo a lo largo del proyecto:

Informe Final de SCM

Página 6 de 8

2.1.

Fase Inicial

2.1.1.

Primera Iteración

Se comenzó la primera versión del Plan de Configuración. Se comenzaron a investigar y probar las tecnologías disponibles para el manejo del ambiente controlado. Se instaló, configuró y puso en marcha el servidor jabber a utilizar para la comunicación interna de mensajería instantánea. Se configuraron las salas para los desarrolladores y responsables con accesos restringidos. Se instaló, configuró y puso en marcha el servidor de SVN expuesto a través de mod_dav y con HTTP Digest auth para cada integrante del equipo. 2.1.2.

Segunda Iteración

Se crearon guías de uso del SVN y documentos. Se creó la maquina virtual con todo el entorno de desarrollo instalado y listo para usar. Se definió el mecanismo de manejo del ambiente controlado. Se terminó de elaborar el Plan de Configuración. 2.1.3.

Tercera Iteración

Se definieron los mecanismos de contingencia para el repositorio SVN (svnsync + respaldos) Se generaron las distintas estructuras de directorios necesarias en el repositorio y los permisos adecuados. Se ajustó el mecanismo de manejo del ambiente controlado. Se realizó la liberación del prototipo del producto.

2.2.

Fase de Elaboración

2.2.1.

Primera Iteración

Se definió la línea base de documentos. Se modifica el plan de configuración para ajustar el procedimiento de solicitud de cambios, para hacerlo más ágil. Se mantiene el método más formal para cambios de alto impacto. Se configura e instala el Redmine a utilizar para issue tracking y wikis de comunicación interna (breves manuales y piques de uso de herramientas) Se hacen pruebas de branching y merging de ramas de desarrollo. Informe de línea base. Se definieron los mecanismos para realizar las liberaciones. Se realizó la liberación número 2 del producto.

Informe Final de SCM

Página 7 de 8

2.3.

Fase de Construcción

2.3.1.

Primera Iteración

Ajustes al plan de la configuración. Nuevo branch de código fuente definido en la línea base. (/lib2) Se realizan controles de cambio e informes sobre la línea base. También se realizó un registro de versiones. Se realizó la liberación número 3 del producto. 2.3.2.

Segunda Iteración

Nuevos controles de cambio, e informes de la línea base y gestión de cambios. Registro de versiones Se definen hooks de SVN para evitar commits en branches incorrectos (verificación). Liberación beta del producto de forma interna. 2.4.

Fase de Transición

2.4.1.

Primera Iteración

Se realiza el Informe final de configuración. Se realiza la Descripción de la Liberación. Se realizó la liberación final del producto.

Informe Final de SCM

Página 8 de 8

Get in touch

Social

© Copyright 2013 - 2024 MYDOKUMENT.COM - All rights reserved.