[English version]

Antecedentes

Hace no tanto tiempo, nuestro proceso de desarrollo se basaba en ant, manteníamos nuestras dependencias de una forma no muy ortodoxa y utilizábamos una serie de scripts manuales para la construcción y entrega de los paquetes de proyectos y productos. Los procesos de merge eran una auténtica pesadilla y perdíamos una gran cantidad de tiempo realizando tareas manuales y formando a nuevos colegas en "nuestra forma de hacer las cosas". La verdad es que, a medida que pasa el tiempo, me pregunto una y otra vez como podíamos trabajar así.

vuelta-al-bloque-cubo-madera-icono-bombilla-simbolo-humano-cabeza-no-tiene-idea

Sea como sea, tomamos la decisión de cambiar, cambiando todo de arriba-abajo. Esto supuso cambiar nuestro sistema de versionando y, fundamentalmente, los procesos de construcción y desarrollo. Cambiamos muchísimas cosas y, he de reconocer, que no fue fácil, para nada. Nos supuso sopesar las cosas importantes y las no tan importantes y como podíamos mejorar el proceso de entrada de nuevos compañeros de viaje.

¿De qué voy a hablar?

En los siguientes puntos me voy a enfocar en los diferentes problemas que tuvimos que abordar

• Cambiar el sistema de versionado, de Subversion a Git.
• Modificar nuestros procesos de CI y CD, mejorando nuestra solución de gestión de dependencias.
• Modificar nuestro proceso de desarrollo, ocultando ciertas complejidades.

El cambio del sistema de versionado

La verdad sea dicha, cambiar el sistema de versionado no puede considerarse como una tarea en si mismo. A fin de cuentas, es solo un cambio de herramienta.

11668623_20945227

Aunque esto es cierto, si me gustaría destacar algunos puntos, sólo por si os encontráis en una situación parecida.

• Optamos por utilizar Git no porque sea la mejor herramienta del mercado o porque haga todo perfecto, sino porque es el standard de facto. Hay cosas que me gusta y otras que detesto, aunque he aprendido a vivir con ellas.
• El principal problema al cambiar de herramienta es la formación, formar a tu equipo en el uso de una nueva herramienta y olvidar las viejas formas de hacer las cosas.
• Con el tiempo me doy cuenta qué tenía unas expectativas un tanto elevadas en cuanto al uso universal de Git. Es cierto que mucha gente lo conoce, aunque muchísimas compañías trabajan todavía con Subversion, y lo que es más preocupante muchos jóvenes no saben lo que es un sistema de versionado y lo que intenta resolver.

En cualquier caso, no me arrepiento en absoluto de haber comenzado a utilizar Git. Era un paso necesario en el cambio que intentábamos implantar, la mejora de nuestro proceso de construcción.

La modificación de nuestro proceso de CI y CD

Lo mejor que puedo decir de como trabajábamos es que usábamos algo "hecho en casa", creo que con eso se dice todo. Dudo, de hecho, de que pudiéramos llamar, con propiedad, gestión de dependencias a lo que teníamos hecho. El empaquetado de los proyectos se hacía en base a scripts en shell, utilizando sustitución de variables y todas esas cosas. Funcionaba, si bien funcionar no es suficiente, puesto que debe ser mantenible y repetible y, lógicamente, a medida que se incorporan nuevas personas reemplazar las viejas vía se convierte en una necesidad.

21683340_Teamwork of tiny people with gears and cogwheels

Si nos limitamos a cambiar de herramientas, el cambio no parece tan complejo, en resumen comenzamos a utilizar Nexus, los procesos de CI de Gitlab, integramos SonarQube y procedimos a entregar nuestros paquetes a través de Docker. Bastante sencillo y estándar, ¿no?

Pues no, no es simple en absoluto, si miramos las tripas hay una gran variedad de procesos involucrados, cambios que deben hacerse y aspectos que deben tratarse de alguna forma, para volver a hacerlos de otra en unas pocas semanas o meses, una vez el proceso se haya consolidado. En resumen, el cambio que asumimos fue,

• Planificado, puesto que teníamos un foco y conocíamos nuestro objetivo aunque el cambio no fue tan recto y lineal como nos hubiera gustado.
• Iterativo, integrando cambios sutiles y pequeños en como trabajábamos. Al final, fuimos capaces de llegar a donde queríamos, más o menos, y lo que habíamos planificado desde el principio.
• Global puesto que los cambios afectan a todo. No podemos hablar de un proceso de CI y CD bien acomodado sin hablar de los cambios en el proceso de construcción y desarrollo.

El cambio de nuestro proceso de desarrollo

Sin ninguna duda, de todas las tareas que realizamos ésta fue la más compleja. No queríamos una aproximación simplista y cosmética, puesto que, a fin de cuentas, lo que buscábamos no era sólo mejorar el proceso de integración continua sino asegurarnos de que el cambio desembocara en una mejora de la productividad para nuestros desarrolladores y nuestros equipos de operación.

development

Nuevamente, cambiamos la herramienta, nos olvidamos de ant y pasamos a utilizar Gradle. Pero, creedme, el problema no era cambiar la herramienta, sino las cosas que hacíamos con ella. Destacando algunas de ellas me quedaría con:

• Evitar un despliegue manual de lo que construíamos en un servidor de aplicaciones. Enseñar a cada nueva persona que incorporábamos, incluso a los de frontend, como debía hacerse, como funciona un Servidor de Aplicaciones en Java lleva mucho tiempo y es frustrante tanto para el formador como para los que reciben la formación.
• Simplificar el proceso de merge. De tal forma que pudiéramos aislar de forma sencilla entre lo que venía del proyecto y lo que venía de productos o librerías globales, incluyendo eso librerías, scripts, ficheros de mensajes, etc… Aunque parezca fácil no lo es tanto, implica "tocar con cariño" y "cuidado" en muchos sitios y modificar código para que se comporte de otra forma.
• Reestructurar el proceso de construcción, generando una distribución de Gradle local, que nos permita la compilación completa del proyecto, incluyendo código de servidor – en Java – y código de frontend basado en TypeScript y REACT.
• Mejorar la reusabilidad, de tal forma que el mismo proceso de empaquetado se utiliza tanto por nuestros desarrolladores como por el proceso de CI.

Algunas cosas que aprendimos

Cambiar no es fácil, pero eso no quiere decir que no sea necesario. Hacer siempre lo mismo sólo conduce al estancamiento y el estancamiento solo conduce a la desaparición.

Si os preguntáis por el esfuerzo os diré que el cambio completo nos llevo un año de trabajo de más o menos una persona y media. Aprendimos mucho, pero sobre todo mejoramos muchísimo y además nos ha permitido saber que tenemos todavía mucho por hacer.

Abrazad el cambio, no dudéis en hacer las cosas que deben hacerse.