Frecuencia recomendada para actualizar dependencias en Proyectos de Software

En mi experiencia con el desarrollo de aplicaciones de software, he aprendido que mantener nuestros proyectos actualizados va más allá de estar al día con las últimas tecnologías. Se trata también de la esencial, aunque a veces olvidada, gestión de librerías y paquetes que nuestras aplicaciones utilizan. Este es un tema que merece nuestra atención, no solo por las mejores prácticas sino también por la seguridad y el rendimiento óptimo de nuestros proyectos. En este artículo, quiero darte algunas ideas y mencionar puntos importantes cómo lo es la frecuencia deberíamos abordar esto, basado tanto en recomendaciones generales como en mis propias prácticas.

Consideraciones Generales

Seguridad

Lo primero y más crítico que viene a la mente es la seguridad. Las vulnerabilidades en las librerías pueden ser una puerta abierta para ataques a nuestras aplicaciones. Actualizar a la última versión nos permite beneficiarnos de los parches de seguridad que los desarrolladores han implementado, la mayoría de librerías que utilizamos son mantenidas mayormente por la comunidad opensource y claro, detrás algunas grandes compañías, así es que cada vez que se encuentra alguna vulnerabilidad, casi de forma inmediata llega un parche.

Mantenimiento

No es solo una cuestión de seguridad; también es una cuestión de mantenimiento eficaz. Trabajar con librerías obsoletas puede resultar en incompatibilidades con otras partes de tu proyecto o incluso con futuras actualizaciones de lenguajes de programación que utilices. Personalmente, he encontrado que una revisión y actualización periódica reduce las horas dedicadas a depuración y mantenimiento.

Deuda Técnica

Postergar estas actualizaciones se conoce como "deuda técnica", un costo oculto que se acumula y que eventualmente tendrá que pagarse, con intereses en forma de tiempo y recursos adicionales, y por experiencia te lo digo, esto es uno de los puntos más dolorosos en el desarrollo de software, porque tarde o temprano se tiene que hacer, básicamente esto en algún punto te alcanzará.

Frecuencia Recomendada

Determinar la frecuencia de revisión y actualización de librerías y paquetes puede ser un desafío. Demasiado frecuente, y estarás dedicando un tiempo valioso que podría ser utilizado en el desarrollo de nuevas funcionalidades. Demasiado tarde, aumentas el riesgo de deuda técnica y problemas de seguridad, así es que encontrar ese balance es difícil y depende grandemente de cada proyecto y de cada equipo.

Una vez al mes: Mi práctica personal

En mi caso, he encontrado un equilibrio revisando cada proyecto una vez al mes. Este enfoque me permite mantenerme al día sin comprometer otras áreas del desarrollo. Durante estas revisiones, verifico las versiones de los diferentes paquetes y leo los cambios en sus changelogs, lo que me ayuda a determinar si debo o no actualizar.

También como recomendación general, yo nunca tomo la última versión de una librería si ha sido recientemente publicada, ya que se requiere de algunas semanas, yo diría que al menos 3 semanas para determinar que esta lista para un ambiente productivo, y creo que 3 semanas porque considero que es el tiempo necesario para que muchos devs alrededor de la red prueben esas librerías y den su feedback.

Herramientas Automatizadas

Si bien hay herramientas como Dependabot en GitHub que pueden ayudar con la gestión de actualizaciones, he encontrado que su eficacia es limitada. Es bueno para notificar, pero considero que un enfoque más manual es a menudo necesario para evaluar adecuadamente el impacto de una actualización, yo lo uso en todos mis proyectos y me gusta porque en algunos casos es bastante granular y específico a tal grado que revisa las dependencias de mis dependencias, cosa que yo no hago.

Para los que están interesados en automatizar al menos parte de este proceso, aquí les dejo un fragmento de código que yo utilizo. Este es un archivo dependabot.yml que se coloca en la carpeta .github en la raíz de cada proyecto:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "monthly"
    open-pull-requests-limit: 50
    target-branch: "dev"
    ignore:
      - dependency-name: "*eslint*"
    labels:
      - "dependencies"

Con esta configuración, Dependabot revisará las dependencias de npm en mi proyecto una vez al mes y abrirá hasta 50 pull requests en la rama dev, ignorando cualquier paquete que contenga "eslint" en su nombre.

---

Para finalizar, La gestión de las librerías y paquetes en nuestros proyectos de software es una tarea que no debe pasarse por alto. Tal como hemos visto, la frecuencia con la que actualizamos estas dependencias es crucial tanto para la seguridad como para el mantenimiento efectivo de nuestras aplicaciones. Aunque herramientas como Dependabot pueden ofrecer un nivel de automatización, he encontrado que un enfoque más personalizado, respaldado por la revisión manual, brinda resultados más efectivos.

Suelo dedicar un medio día completo a revisar mis proyecto y actualizar sus librerías y lo considero definitivamente una buena práctica, no sé si te funcione a ti, pero al menos a partir de ahora espero que lo empieces a tener en cuenta.

Mi ejemplo es funcional para Github, pero si trabajas con otro tipo de servicio de código en la nube, quizás tenga herramientas similares o en tal caso, puedes contruir tu propio pipeline o action para automatizar esta tarea.

Happy coding! :D

---

Photo by Clément Falize on Unsplash