Sergio Luis Para es ingeniero de software en Unity Technologies, donde se dedica a crear una plataforma para desarrollar y operar contenido en 3D en tiempo real. Trabaja en Valladolid, en una empresa del grupo llamada Códice Software.
Códice Software, dentro del Unity, aporta tres productos: un software de control de versiones (Plastic SCM), una herramienta para unir diferentes versiones del código (SemanticMerge) y, por último, un cliente para Git con capacidades semánticas. Internamente desarrollan varios productos internos de los que hablaremos más adelante.
Una historia de mejora
En su charla dentro del Software Development Summit, Sergio nos guiará en la historia de cómo la integración continúa y algunas prácticas, pero podemos avanzar ya, para generar expectación, que en los últimos 6 meses de la empresa han sacado más versiones de los productos al mercado que en los 9 primeros años de la misma.
Pero siempre hay un inicio. Todo empieza sobre 2007 con la figura del Build Master o chamán, la persona que se encargaba de integrar los cambios de los equipos para llevarlos a una release. Cada desarrollo en una tarea y éste en una rama. Entonces, el chamán elaboraba un listado de tareas/ramas candidatas a ser integradas cada 15 días y luego integraba estas tareas a mano con gran dolor a la rama principal.
El entorno de pruebas
Como a veces suele pasar, los entornos donde probar todos los desarrollos son complejos y este caso no es una excepción. Con un gran abanico de pruebas, como por ejemplo: los unitarios, de interfaz gráfica, de integración (smoke), de instaladores. Todos estos deben poder ejecutarse en diferentes sistemas operativos.
Para lanzar estas pruebas, requerían scripts complejos que hacían de todo, desde lanzar las propias pruebas hasta encender máquinas virtuales. Todo esto ocurría en unas 8 horas de las cuales sólo el chamán tenía información. Si fallaba el proceso, los equipos paraban el desarrollo para centrarse en arreglar el problema, si lo había.
Mejora la vida al chamán
El objetivo a partir de entonces era intentar eliminar esos procesos manuales para pasar las pruebas. Para ello, crean su propio software de integración continua, que se encarga ahora de compilar el producto: arrancar las máquinas virtuales, distribuir los artefactos para las pruebas y ejecutar las pruebas guardando los resultados en el lugar adecuado.
Para que el desarrollador obtenga información del estado de las pruebas, han creado un Issue Tracker que a partir de una tarea/rama puede visualizar qué pruebas han fallado.
Y, por último, definieron un Domain Specific Languages (DSL) para definir cómo tienen que pasar las pruebas, para así eliminar de una vez esos scripts tan doloroso.
La muerte del chamán
Todo el trabajo que hacía el chamán pasará a los equipos de desarrollo y para ello trabajan en 3 puntos:
- Llevar los merge a servidor
- SemanticMerge en el lado del servidor
- MergeBots
El esfuerzo colaborativo, una gran solución.
Ahora observamos unos equipos empoderados que tienen las herramientas y la información para empezar una tarea, pasar las pruebas necesarias y llevarlo a producción.
Así es como Códice Software ha roto una dependencia en su proceso productivo con un rol muy importante distribuido a los equipos de manera colaborativa.
Puedes volver a ver la charla aquí
Sobre el autor:
