Ciclo de Trabajo de Codice Software VI: Últimos pasos

Ciclo de Trabajo de Codice Software VI: Últimos pasos

0:05 noticias 0 Comments

Y llegamos al final de la serie. He intentado cubrir con una visión general todo el ciclo de trabajo que realiza el equipo de Plastic SCM, para sacar adelante el producto: herramientas, test, documentación.
¿Qué me falta por contar? Pues cómo sacamos una nueva versión de nuestro producto.

Nueva Release

Una vez que hay un número de tareas terminadas, probadas por Bamboo, revisadas y validadas… se crea una nueva release. Durante años se hacía una release nueva a la semana, muchas veces interna, otras veces la publicaban en la web. Con esto se pretendía tener:

• Visibilidad de todo el proceso de trabajo (medible en releases) 
• Solución de respaldo (frente a imprevistos) 

 Desde hace más de medio año dejaron de hacer releases semanales y pasaron a realizar una nueva release cada 24 horas. Sí, una cada día y no, no están locos al final de cada sprint. Cada día integran las tareas que se han sido revisadas, validadas y han pasado los tests.
Uno de los desarrolladores es el encargado de las releases o “integrador”.("The IntegraTHOR") En muchos equipos “top-agile” esto parece que no encaja, pero se trata de la base del proceso de integración controlada por el que primas versiones estables ante todo.

Test de Release

Es una de la tareas del integrador y tiene su sitio de honor porque es donde se dispara toda la artillería de testing.
Se pasan todos los tests automáticos en todas las combinaciones soportadas.

• Smoke tests: en todas las plataformas y backends (bases de datos) soportados. 
• Windows: desde W2k (que todavía soportan porque son unos nostálgicos), XP, W2003 server, 2008, Vista, 7 y ahora W8. 
• Mac OS X 
• Un montón de “sabores” de Linux: openSuSE, ReadHat, Ubuntu.

Combinando arquitecturas 32 y 64 bits (y en ocasiones SPARC 64 aunque hace tiempo que no están incluyendo este juego de pruebas).

Se usan los mismos juegos que usamos para “Bamboo” más otros como tests de instalación en línea de comandos, tests de “restart”, es decir , reinician el servidor a mitad de cada test para comprobar que no hay problemas de cachés y juegos especiales de merge y localización. 

• GUI tests: ahora lanzamos el mismo juego que usamos durante las pruebas de “Bamboo” sobre todas las plataformas soportadas (no sólo una) para asegurar la compatibilidad. Han lanzado juegos especiales para la Shell Extension, plugins para Eclipse, Visual Studio, etc.
• Performance tests: usan Amazon EC2 para esto, tests especialmente diseñados para asegurar que no se rompe el rendimiento de ciertas operaciones básicas con gran carga de datos. Miden también memoria y uso de CPU. 

En total los Tests de Release necesitan más de 24h para ejecutarse, pero con 7 servidores y un buen número de máquinas virtuales se pueden reducir a aproximadamente 6 horas.
El siguiente objetivo es usar mucho más las máquinas en cloud y reducir el tiempo a menos de 1h antes de que acabe el año, lo que les dará mucha más flexibilidad en la creación de las releases. Utilizan herramientas como FxCop para mantener la limpieza del código. NCover para medir la cobertura de sus tests y medir la complejidad ciclomática del código.

Tareas del Integrador

Las ventajas son muchas, pero la más importante es que tienen un responsable encargado de avisar de lo bien (o menos bien) que ha ido la release.

El trabajo del integrador es, en esencia es como un guardia de tráfico:

• Coger cada tarea, integrar su rama. Sólo coge ramas que hayan pasado todo el proceso de test, revisión y validación. Vigila que las tareas pasen por cada uno de sus estados: de Open a Resolved, Reviewed y Validated. Y además que estén correctamente introducidas en el control de tareas para posteriormente obtener estadísticas útiles.
• Encargarse de que los conflictos de merge se resuelvan bien y hacer saltar las alarmas ante cualquier problema (es una fase más de revisión). 
• Pasar un juego inicial de tests: todos los unitarios y smoke lo más rápido posible (usa unas 6 máquinas para esto, reduciendo el tiempo de “smoke” a menos de 20 minutos). 
• Pasar y monitorizar todos los Tests de Release. 
• Crear las Release Notes. 
• Generar los binarios de release. 
• Actualizar los servidores internos. 
• Lanzar la subida de la nueva release a la web.
• Dirigir el test manual, supervisión y control de bugs detectados

El integrador es el último responsable de que la release vaya bien, de que se cumplan los criterios de calidad, de hacer saltar las alarmas si algo no va bien, de mantener siempre funcionando el juego de tests de release (ya sea haciendo el tareas de mantenimiento o asignando a miembros del equipo dichas tareas). Dada la posición privilegiada del integrador, tiene unan visión global del proyecto, por lo que es capaz de detectar puntos de mejora en el proceso y de sugerir nuevas funcionalidades, mayor cobertura en los tests, etc.

Conclusión

Como habeis podido leer, en el proceso de trabajo tiene un peso muy importante toda la parte de pruebas, con un número bastante alto de tests automáticos que completan con tests exploratorios. Soportamos muchas plataformas y cómo ya hemos dicho la calidad es una constante en nuestro trabajo. Nuestro proceso tiene que seguir mejorando mucho porque Plastic SCM compite codo con codo con productos como Perforce, ClearCase, TFS, Subversion o Git.
El equipo de desarrollo es el más pequeño que el de ninguno de ellos, pero Plastic SCM cuenta con una lista de características de control de versiones más amplia.
No es un trabajo sencillo, pero se ve que les encanta su trabajo y se esfuerzan  cada día por ser los mejores.
 ¿Te gustaría venir a conocernos?