¿Cómo decides cuándo actualizar una biblioteca en tu proyecto?

Question

Trabajo en un proyecto que usa múltiples bibliotecas Java de código abierto. Cuando las actualizaciones a las bibliotecas salen, tenemos la tendencia a seguir una estrategia conservadora:

1. si no está roto, no lo arregles
2. si no tiene nuevas características que deseamos, lo ignoran

Seguimos esta estrategia porque normalmente no tenemos tiempo para poner en la nueva biblioteca y probar a fondo la aplicación en general. (Al igual que muchos equipos de desarrollo de software, siempre estamos retrasados ​​en las funciones que prometimos hace meses).

Pero a veces me pregunto si esta estrategia es acertada dado que algunas mejoras de rendimiento y una gran cantidad de correcciones suelen venir de la biblioteca actualizaciones (es decir, "Quién sabe, tal vez las cosas funcionen mejor de una manera que no prevemos ...")

¿Qué criterios utiliza cuando toma este tipo de decisiones en su proyecto?

Answer 1

He aprendido suficientes lecciones que hacer lo siguiente:

1. Comprobar la lista de cambios de la biblioteca. ¿Qué arreglaron? ¿Qué me importa? Si no hay una lista de cambios, entonces la biblioteca no se usa en mi proyecto.
2. ¿Qué publican las personas en el foro de la Biblioteca? ¿Hay una avalancha de publicaciones comenzando poco después del lanzamiento señalando problemas obvios?
3. En la misma línea que el número 2, no actualice de inmediato. TODOS tienen un mal lanzamiento. No pretendo ser el primero en meterse con ese pequeño error. (más que eso) Esto tampoco significa esperar 6 meses. Dentro del primer mes de publicación, debe conocer los inconvenientes.
4. Cuando decido continuar con una actualización; prueba, prueba de prueba. Aquí las pruebas automatizadas son extremadamente importantes.

EDIT: que quería añadir un elemento más que es al menos tan importante, y tal vez más que los otros.

• ¿Qué cambios de última hora se introdujeron en esta versión? En otras palabras, ¿está estallando la biblioteca en una dirección diferente? Si la biblioteca está desaprobando o reemplazando la funcionalidad, querrá estar al tanto de eso.

Answer 2

Importante: evitar Technical Debt.

"Si no está roto, no actualices" es una política disparatada que conduce a un software tan roto que nadie puede arreglarlo.

Erupciones, cambios no probados son una mala idea, pero no tan malo como la acumulación de deuda técnica, ya que parece más barato en el corto plazo.

Realice un proceso de "construcción nocturna" para que pueda probar continuamente todos los cambios, tanto los suyos como los paquetes de los que depende.

Hasta que tenga un proceso de integración continuo, puede realizar versiones principales trimestrales que incluyen actualizaciones de infraestructura.

Evite la deuda técnica.

Answer 3

Algunas preguntas importantes:

• Cómo ampliamente utilizados es la biblioteca? (Si se usa ampliamente, los errores se encontrarán y eliminarán más rápidamente)
• ¿Qué tan activamente desarrollado es?
• ¿La documentación es muy clara?
• ¿Se han producido cambios importantes, menores o solo cambios internos?
• ¿La actualización rompe la compatibilidad con versiones anteriores? (Se tiene que cambiar cualquiera de su código?)

menos que la actualización se ve mal de acuerdo a los criterios anteriores, es mejor ir con él, y si usted tiene algún problema, volver a la versión antigua.

Answer 4

Un enfoque es acercar las bibliotecas de código abierto que usa bajo su propio control de código fuente. A continuación, fusione periódicamente los cambios preliminares en su próxima rama de versiones, o antes si son soluciones de seguridad, y ejecute sus pruebas automatizadas.

En otras palabras, use los mismos criterios para decidir si usará cambios ascendentes que para ciclos de liberación en el código que escribe en casa. Considere a los desarrolladores de código abierto como parte de su equipo de desarrollo virtual. Este es realmente el caso de todos modos, solo se trata de si eliges reconocerlo como parte de tus prácticas de desarrollo.

Answer 5

Si bien no desea actualizar simplemente porque hay una nueva versión, hay otra consideración, que es la disponibilidad de la versión anterior. Me he encontrado con ese problema al intentar construir proyectos de código abierto.

Answer 6

Por lo general asumo que ignorar una nueva versión de una biblioteca (porque no tiene características o mejoras interesantes) es un error, porque un día descubrirá que esta versión es necesaria para la migración a la próxima versión a la que le gustaría actualizar.

Así que mi consejo es revisar cuidadosamente qué ha cambiado en la nueva versión, y considerar si los cambios requieren muchas pruebas, o poco.

Si se requieren muchas pruebas, es mejor actualizar a la biblioteca más nueva en la próxima versión (versión principal) de su software (como al pasar de v8.0 a v8.5). Cuando esto sucede, creo que hay otras modificaciones importantes también, por lo que se realizan muchas pruebas.

Answer 7

Prefiero no dejar que las versiones se retrasen demasiado en las bibliotecas dependientes. Hasta un año es aceptable para la mayoría de las bibliotecas a menos que se conozcan problemas de seguridad o rendimiento. Las bibliotecas con problemas de seguridad conocidos son una necesidad para refrescarse.

Periódicamente descargo la última versión de cada biblioteca y ejecuto mis pruebas de unidad de aplicaciones utilizándolas. Si pasan, los uso en nuestros entornos de desarrollo e integración por un tiempo y presiono para QA cuando estoy satisfecho de que no son una mierda.

El procedimiento anterior asume que la API no ha cambiado significativamente. Todas las apuestas están apagadas si necesito refactorizar el código existente solo para usar una versión de biblioteca más nueva. (Por ejemplo, Eje 1x frente a 2x) Entonces necesitaría involucrar a la administración para tomar la decisión de asignar recursos. Tal cambio normalmente sería diferente hasta que se planee una revisión mayor del código heredado.