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?
