Entre los post tradicionales de este blog se encuentra el repaso de las tecnologías que he usado profesionalmente a lo largo del año. Si alguien tiene curiosidad por ver la evolución, puede revisar lo que usé en el 2015, 2016 y 2017.

Como el contexto es importante, vamos a centrar un poco desde qué perspectiva está escrito este post.

Sólo voy a mencionar tecnologías que uso profesionalmente, no aquellas con la que haya podido jugar un rato pero no haya tenido en producción. Para eso ya están otros posts de este blog.

También es fundamental recordar que me dedico a productos, no proyectos. Además son productos (software para puntos de venta) que se despliegan localmente en las máquinas y en los cuales no controlamos el proceso de despliegue, el cual se realiza de forma manual no por una cuestión técnica sino de negocio: nuestros clientes son distribuidores que se ganan la vida vendiendo nuestro producto y cobrando por cosas como ésta. Si a esto le unes la importancia de mantener la compatibilidad con versiones anteriores del software, y sistemas operativos entre antiguos y obsoletos, el margen de maniobra que nos queda para jugar con nuevas tecnologías es menor y preferimos garantizar la estabilidad de todo el sistema.

.NET, servidores y escritorio

La base de nuestras aplicaciones está desarrollada usando .NET Framework 3.5 SP1. Sí, es antiguo, pero tenemos mucho parque instalado cuya actualización no es trivial (o ni siquiera está soportada). También tenemos algunos desarrollos de servidor «puro» en los que controlamos el despliegue y usamos versiones más modernas de .NET Framework (tradicional, no .NET Core), pero representa una parte mucho menor de nuestro código.

Aquí miro con envidia algunas funcionalidades nuevas que ofrecen las últimas versiones de C#, pero para usarlas tendríamos que actualizar el tooling (seguimos con Visual Studio 2013 y el msbuild y Resharper de aquella época) y, hasta ahora, no nos ha compensado.

Mantenemos nuestro stack clásico basado en NHibernate, Castle.Windsor, log4net y NUnit. Son piezas que nos funcionan muy bien, las conocemos perfectamente para explotar sus ventajas y minimizar sus inconvenientes, y la migración a otras librerías no creemos que nos aporte lo suficiente como para compensar el coste de hacerlo.

Como servidor de base de datos seguimos usando Microsoft SQL Server, fundamentalmente las versiones 2005 y 2014. La realidad es que tampoco usamos nada especial del 2014 (más allá de que en la versión Express es algo más generoso en tamaño de base de datos) y nos ceñimos a lo soportado por 2005 para mantener compatibilidad. Tampoco es que tengamos unos requisitos muy elevados en este aspecto.

Clientes web

Cada vez más hemos ido migrando las aplicacones escritas en .NET (usando Windows Forms) a tecnologías web.
Ahí se nota más la evolución a lo largo de los años (se puede ver también en los posts que he ido escribiendo sobre tecnologías front) y tenemos variedad de librerías, frameworks y lenguajes. Eso complica el mantenimiento, pero de momento no lo suficiente como para justificar la reescritura de aplicaciones, que están funcionando bien y generando negocio, en aras de usar The Best Platform™.

Tenemos cosas con AngularJS 1.x (estamos deseando quitárnoslo de encima, pero es difícil de justificar económicamente) y con varias versiones de ReactJS (todas relativamente añejas). Tenemos cosas con ES5, otras con ES2015 y otras con TypeScript.

Para hacerlo más entretenido, cada una usa el sistema de compilación que mejor nos pareció en cada momento, incluyendo Grunt, Webpack o simples scripts npm.

En la parte de testing en frontend usamos estrategias variadas, pero al final utilizamos las librerías típicas: jasmine, mocha, chai, protractor y karma (para la parte de angular), nightwatch para tests de extremo a extremo con React. Con Enzyme ya el año anterior vimos que acabábamos teniendo tests que nos resultaban poco útiles y creo que este año no hemos escrito ningún test nuevo con él (incluso hemos borrado algunos existentes para no tener que mantenerlos).

La nube

Este año hemos empezado a prestar más atención a la nube. Nos hemos encontrado con la necesidad de ofrecer determinados servicios mantenidos por nosotros y eso nos ha llevado a aprovechar la parte de IaaS para levantar servidores dedicados para algunos clientes.

De momento estamos usando como proveedor Azure (paso lógico dado nuestro bagaje), y por el camino hemos comenzado también a utilizar algunos servicios concretos de Azure, como Azure Blobs. Imagino que poco a poco iremos usando más servicios de Azure y atándonos más a él. No es algo que me deje demasiado tranquilo, pero bueno.

En nuestra (limitadísima) experiencia con la nube y, especialmente, con Azure, ha habido cosas que nos han gustado más y cosas que nos han gustado menos, como era de esperar.

Por una parte, la flexibilidad para levantar máquinas, aumentar o disminuir su potencia en función de las necesidades, gestionar backups, infraestructura de red, etc., es muy práctica. Como todas las cosas para pobres, lo barato acaba saliendo caro a la larga y los costes cuando empiezas a mirar a medio plazo pueden ser más elevados que con sistemas propios, pero la comodidad y la disminución de la barrera de entrada compensa en muchos casos.

En la parte mala, a veces nos quedamos con la idea de que avanza todo un poco demasiado rápido. Y eso no es necesariamente malo, sino fuese porque te quedas con la impresión de producto a medio hacer. Que estén cambiando continuamente el UI del portal, que tengas unas cuantas cosas en preview, otras marcadas como classic (que suena a que las vas a descontinuar pasado mañana), otras con v1, v2, v3…

Genera cierta sensación de inseguridad y no saber realmente qué puedes usar y hasta cuándo. Nos ocurrió por ejemplo con la parte de RBAC que nos gustó mucho pero cuando fuimos a implementarla nos encontramos con algunos problemas por no estar completamente integrada con otros servicios.

(D)VCS e integración continua

En esta parte es donde más cambios hemos introducido este año. Después de diez años usando Subversion para gestionar el código y CruiseControl.NET para lanzar nuestros scripts de compilación, hemos dado el salto a GitLab.

No es que hubiera dejado de funcionar lo que teníamos, pero empezaba a suponer demasiada fricción para algunas cosas que queríamos hacer.

El rendimiento de SVN ya se hacía difícil de soportar con el volumen de código que teníamos. Por su parte, CCNET nos complicaba la parte de compilar varias ramas de una misma aplicación. Lo hacíamos, pero de forma muy manual. Eso, unido a una suite de tests grande que tarda mucho en ejecutarse hacía que la rama principal se rompiese con frecuencia porque para evitar lanzar los tests en nuestros equipos de desarrollo subíamos directamente y dejábamos que se pasaran arriba.

Con GitLab conseguimos un sistema de control de versiones más rápido y potente, que nos deja hacer más cosas, y de paso la gestión de pipelines de compilación.

La migración de la parte de código no ha existido (adiós a la historia, que sigue viviendo en SVN) y ha consistido más en empezar a usar git “en serio”. Todos conocíamos git, pero no lo habíamos explotado realmente. De momento está siendo una buena experiencia.

Adaptar nuestros scripts de compilación ha sido sencillo porque siempre hemos apostado por independizarlos de la herramienta que los lanza. Eso nos ha permitido aprovechar para automatizar un par de procesos manuales que nos quedaban y montar algo parecido a un sistema de entrega continua hacia la gente de QA que nos ayuda a detectar bugs antes.

Después de probar unas cuantas (bastantes) herramientas para usar git, todos hemos acabado adoptando Git Bash como interfaz principal, apoyándonos en alguna otra cosa para tareas puntuales. Aquí me quedo con la espinita clavada de magit, que me encantó por filosofía y usabilidad, pero que es inmanejable con repositorios grandes en Windows.

Resumen

Viendo la evolución tecnológica que hemos tenido en los últimos años está claro que no formamos un equipo que esté trabajando siempre con lo último de lo último. Como decía al principio, el contexto en que nos movemos hace que eso no sea práctico y necesitemos ser más conservadores.

Sin embargo, que tengamos que ser conservadores al adoptar nuevas tecnologías no nos exime de tener que estar pendientes de lo que va surgiendo y conocer qué nos ofrece esa nueva moda superinteresante de la que todo habla (spoiler: muchas veces, más de lo mismo). Puede que no lo pongamos en producción en la versión 1, y ni siquiera en la versión 2, pero si realmente nos soluciona un problema, es probable que acabemos usándolo.

En lo que sí tenemos mucho cuidado es en evitar la tecnología por la tecnología. Jugar con cosas nuevas y cambiar de plataformas cada cierto tiempo es muy divertido y tentador, pero desde un punto de vista puramente económico (y no olvidemos que aquí estamos hablando de tecnologías que usamos profesionalmente), casi nunca es rentable.