¿Cuándo deben actualizarse las dependencias?

Tuvimos dos crisis principales relacionadas con la dependencia con dos bases de código diferentes (Android y una aplicación web Node.js). El repositorio de Android necesitaba migrar de Flurry a Firebase, lo que requería actualizar la biblioteca de Google Play Services en cuatro versiones principales. Algo similar sucedió con nuestra aplicación Node alojada en Heroku, donde nuestra pila de producción (cedro) fue obsoleta y necesitaba actualizarse a cedar-14. Nuestra base de datos PostgreSQL también necesitaba actualizar de 9.2 a 9.6.

Las dependencias de cada una de estas aplicaciones permanecieron obsoletas durante casi dos años, y cuando algunas quedaron en desuso y llegamos al período de `` puesta del sol '', ha sido un gran dolor de cabeza actualizarlas o reemplazarlas. He pasado más de 30 horas durante el último mes o dos resolviendo lentamente todos los conflictos y el código roto.

Obviamente, dejar que las cosas reposen durante dos años es demasiado tiempo. La tecnología se mueve rápidamente, especialmente cuando está utilizando un proveedor de plataforma como Heroku. Supongamos que tenemos un conjunto de pruebas completo y un proceso de CI como Travis CI, que elimina muchas conjeturas de la actualización. Por ejemplo, si una función se eliminó después de una actualización y la estaba usando, sus pruebas fallarían.

¿Con qué frecuencia deben actualizarse las dependencias o cuándo deben actualizarse las dependencias? Actualizamos porque nos vimos obligados a hacerlo, pero parece que algún tipo de enfoque preventivo sería mejor. ¿Deberíamos actualizar cuando se lanzan versiones menores? Versiones principales? ¿Todos los meses si hay actualizaciones disponibles? Quiero evitar a toda costa una situación como la que acabo de experimentar.

PD: para uno de mis proyectos personales de Rails, utilizo un servicio llamado Gemnasium que rastrea sus dependencias para que pueda ser notificado, por ejemplo, de vulnerabilidades de seguridad. Es un gran servicio, pero tendríamos que verificar manualmente las dependencias para los proyectos que mencioné.

En general, debe actualizar las dependencias cuando:

1. Es necesario
2. Hay una ventaja para hacerlo
3. No hacerlo es desventajoso

(Estos no son mutuamente excluyentes).

La motivación 1 ("cuando tiene que hacerlo") es el conductor más urgente. Algún componente o plataforma de la que dependa (p. Ej. Heroku) lo exige, y debe alinearse. Las actualizaciones requeridas a menudo caen en cascada de otras opciones; decide actualizar a la versión PostgreSQL tal y cual. Ahora tiene que actualizar sus controladores, su versión ORM, etc.

La actualización porque usted o su equipo perciben una ventaja al hacerlo es más suave y más opcional. Más de un juicio: "¿La nueva característica, capacidad, rendimiento, ... vale la pena el esfuerzo y la dislocación que traerá?" En Olden Times, había un fuerte sesgo contra las actualizaciones opcionales. Eran manuales y difíciles, no había buenas maneras de probarlos en una caja de arenao entorno virtual, o para revertir la actualización si no funcionó, y no hubo pruebas automáticas rápidas para confirmar que las actualizaciones no habían "alterado el carrito de la manzana". Hoy en día, el sesgo es hacia ciclos de actualización mucho más rápidos y agresivos. Los métodos ágiles adoran probar cosas; Los instaladores automáticos, los administradores de dependencias y los repositorios hacen que el proceso de instalación sea rápido y, a menudo, casi invisible; los entornos virtuales y el control de versiones omnipresentes facilitan las ramificaciones, los tenedores y las reversiones; y las pruebas automatizadas nos permitieron probar una actualización y luego evaluar de forma fácil y sustancial "¿Funcionó? ¿Arruinó algo?" El sesgo ha cambiado al por mayor, de "si no está roto, no lo arregles" a "actualizar temprano, actualizar a menudo"

Motivation 3 es el más suave. Las historias de usuarios no se refieren a "la plomería" y nunca mencionan "y mantienen la infraestructura no más de N versiones detrás de la actual". Las desventajas de la deriva de la versión (más o menos, la deuda técnica asociada con caer detrás de la curva) invaden en silencio, y luego a menudo se anuncian a través de la rotura. "Lo siento, ¡esa API ya no es compatible!" Incluso dentro de los equipos ágiles, puede ser difícil motivar el incrementalismo y "mantenerse al tanto" de la frescura de los componentes cuando no se considera crucial para completar un sprint o lanzamiento dado. Si nadie aboga por las actualizaciones, pueden pasar desatendidas. Esa rueda puede no chirriar hasta que esté lista para romperse, o incluso hasta que se rompa.

Desde una perspectiva práctica, su equipo debe prestar más atención al problema de deriva de la versión. 2 años es demasiado largo. No hay magia Es solo una cuestión de "pagarme ahora o pagarme después". Aborde el problema de deriva de la versión de forma incremental, o sufra y luego supere sacudidas más grandes cada pocos años. Prefiero el incrementalismo, porque algunas de las sacudidas de la plataforma son enormes. Una API o plataforma clave de la que dependa que ya no funcione realmente puede arruinar su día, semana o mes. Me gusta evaluar la frescura de los componentes al menos 1-2 veces al año. Puede programar revisiones explícitamente, o dejar que se activen orgánicamente por los ciclos de actualización relativamente metronómicos, generalmente anuales, de componentes principales como Python, PostgreSQL y node.js. Si las actualizaciones de componentes no activan a su equipo con demasiada fuerza, la actualización verifica las versiones principales, en mesetas de proyectos naturales, o cada k lanzamientos también puede funcionar. Lo que llama la atención para corregir la deriva de la versión en una cadencia más regular.

Las bibliotecas deben actualizarse cuando se requiere que se actualicen. Eso significa que si la actualización no aporta valor, no deberías.

En su caso particular, estaba migrando de una pila tecnológica antigua a una nueva, y para hacerlo se vio obligado a actualizar sus dependencias. Ese mismo momento es el momento correcto para actualizar las dependencias.

Si hubiera estado actualizando sus dependencias a lo largo del tiempo, para "no tener dolor de cabeza ahora", habría tenido que invertir mucho tiempo de trabajo (codificación) sin ningún valor de retorno. Y cuando tenía que hacer la última actualización (la que está haciendo ahora, pero actualizando 1 versión principal en lugar de 4), probablemente todavía tenga dolor de cabeza en alguna parte (después de todo, la versión principal significa cambios importantes). Así que creo que estás en el camino correcto.

Sin embargo, si le resulta demasiado difícil migrar y tiene que refactorizar mucho, es probable que el problema se encuentre en su base de código. Es bastante común que los proyectos de Android no tengan una arquitectura general en términos de estructura de código. Un buen marco de inyección de dependencias como Dagger 2 , y un par de principios de ingeniería de software como SOLID habrían facilitado cambiar la implementación del código manteniendo el mismo comportamiento / requisitos.

Además, dado que estamos en refactorización, lea un poco sobre las Pruebas de Unidad, ya que eso ayudaría mucho al hacer este tipo de trabajo.

Si está utilizando herramientas de administración de paquetes (por ejemplo, npm, NuGet) y tiene un conjunto completo de pruebas automatizadas, la actualización de las dependencias debería ser una actividad de bajo esfuerzo, simplemente actualice el paquete, ejecute su conjunto de pruebas y vea si hay algún problema. Si hay una reversión, levante un elemento de trabajo para investigar y solucionar el problema.

Mientras el costo de actualizar las dependencias sea bajo, vale la pena mantenerse actualizado:

• Si hay problemas con la actualización que desea saber más temprano que tarde en caso de que se requieran cambios ascendentes.
• Dejar las actualizaciones de dependencia hasta el último minuto a menudo significa que está haciendo esas actualizaciones en el momento crítico (por ejemplo, en respuesta a un error crítico de seguridad). Mantenerse al tanto de sus dependencias significa que tiene el control de cuándo gasta ese esfuerzo y puede realizar esas actualizaciones en momentos en que no está tan ocupado.
• Las versiones más nuevas pueden tener mejoras de productividad, por ejemplo, mejor documentación, API más fácil de usar, correcciones de errores (aunque también es posible lo contrario).

Si la actualización de dependencias no es un esfuerzo bajo (por ejemplo, porque necesita probar manualmente la actualización o porque hay problemas conocidos / cambios importantes), entonces debe sopesar los pros y los contras con respecto a sus otras tareas. Las antiguas dependencias son un tipo de deuda técnica de bajo interés, por lo que deben tratarse en consecuencia.

No debe hacer una versión en la que use versiones antiguas de sus dependencias, a menos que esas versiones sean alternativas compatibles.

es decir, si está en V1 y todavía es compatible, puede seguir utilizando la última versión de v1.

El único momento en que debe estar desactualizado es si:

A: No has hecho un lanzamiento en algún tiempo.

B: Has estado en v1 tanto tiempo que ya no es compatible

Las actualizaciones se lanzan por una razón, contienen correcciones de seguridad que debe tener en cuenta.

Si sale una nueva versión de su dependencia, también debería estar haciendo una versión

Creo que debe depender de la biblioteca en cuestión hasta cierto punto, pero yo también he tenido dolores de cabeza de dependencia similares.

El sentido común me dice que una versión principal es probablemente el momento adecuado para actualizar, y una versión menor que soluciona un defecto grave o incluye un beneficio significativo lo reemplazaría.

A veces no tenemos el lujo de trabajar en todas las aplicaciones que requieren mantenimiento, o incluso de implementar una misión crítica, ¡pero eventualmente lo morderán y una onza de prevención a menudo supera una libra de cura!

Las bibliotecas deben actualizarse cuando ofrece una ventaja que utilizará su software para compensar el trabajo dedicado al cambio.

Incluso las actualizaciones menores de la versión de la biblioteca pueden romper o insertar inconsistencias en las aplicaciones. Desde esa perspectiva no hay cambios menores.

No hay vergüenza en usar viejos libs. Cuando se necesita el cambio puede ser doloroso, pero es parte del trabajo.