¿Cómo se manejan las principales actualizaciones de marco/dependencia?

Question

Buscando algunas mejores prácticas en el manejo de una importante actualización de dependencias dentro de un proyecto, asumiendo el uso de una herramienta de administración de dependencias (por ejemplo, Maven 2).

Específicamente, estoy interesado en:

• Cómo obtener una solicitud heredada hasta a la fecha (por ejemplo, 1.2.x primavera a 2.5.x)
• ¿Qué prácticas se pueden poner en lugar para después de tal revisión para mantener las aplicaciones algo actualizadas

Se agradecen sus propias experiencias o cualquier artículo/documentación que haya encontrado útil.

EDITAR: La actualización de un número de versión de dependencia es trivial. Estoy más buscando cómo abordar los cambios que necesita realizar, en función de los cambios en la dependencia (depreciación, eliminación, cambios en los tipos en los parámetros/valores devueltos, etc.). Y si hay una buena manera de facilitar estos cambios en el futuro, como mantener sus dependencias actualizadas , debería permitirle estar al tanto de los cambios y evitar que se desperdicie mucho tiempo solo para obtener la característica 'más segura' x 2.1 '.

Answer 1

En mi experiencia, las actualizaciones de dependencia se implementan debido a una funcionalidad necesaria propiedad de la dependencia, como una solución a un error en la dependencia que afecta directamente a su propio código, para admitir una nueva versión de Java o para mantener su código conforme a un estándar particular (con respecto a las dependencias que afectan la seguridad). Si su código no cae en una de estas áreas de necesidad, no me molestaría en mantenerlos actualizados, sino que solo los actualizo cuando sea necesario, ya que la actualización de una versión a otra puede en realidad introducir errores en su aplicación.

Siempre he encontrado que la mejor práctica comienza con terminar la producción de su aplicación para el ciclo, liberándola como una compilación estable y actualizando manualmente sus dependencias en la siguiente iteración de desarrollo. Centralizar sus versiones en su POM principal resultará en modificaciones de versiones de dependencia mínimas y una mayor extensibilidad. Suponiendo que está utilizando Maven:

<dependency> 
    <groupId>your.dep.group</groupId> 
    <artifactId>your-artifact-id</artifactId> 
    <version>${desiredVersion}</version> 
</dependency> 

Answer 2

Buenas prácticas para el manejo de cambios de dependencias son las mismas que las buenas prácticas para el diseño de aplicaciones. Desea aplicar capas a la arquitectura y minimizar el acoplamiento generalizado de su código en cada dependencia para mantener los cambios aislados, de modo que la actualización de una dependencia no interrumpa todas las partes de la aplicación. Codifique las interfaces y mantenga la lógica de negocios separada del código de la infraestructura.

Para actualizaciones menores (actualización de versiones de punto de una dependencia), ayuda si tiene un conjunto completo de pruebas unitarias para detectar fallas debido a cambios de API. Esta es una de las razones principales por las que a veces resulta útil escribir pruebas triviales que parezcan superficiales para que funcionen siempre. Un ejemplo de esto es escribir una prueba de unidad JDBC simple para realizar una consulta simple. Esto parece una pérdida de esfuerzo hasta que detecta un problema de tiempo de ejecución con el controlador JDBC después de una actualización de la base de datos (me ha sucedido a mí).

Para cambios más grandes (como actualizar entre versiones incompatibles de un marco como Spring), es útil tener algunas pruebas funcionales o de integración automatizadas, o al menos tener una especificación funcional que su gente de QA pueda ejecutar para verificar el nivel alto funcionalidad. Es probable que las pruebas unitarias ya no sean relevantes si la API marco que está actualizando es lo suficientemente diferente como para requerir amplios cambios de código.

La parte táctica real de administrar una migración de una versión de una dependencia a otra incompatible realmente depende de lo que esté haciendo. Una biblioteca madura proporcionará algún tipo de ruta de migración y con suerte no requerirá que reescriba todo. Es una buena idea separar los cambios de código relacionados con una actualización de la infraestructura de los cambios relacionados con la implementación de una nueva característica. De esta forma, si algo se rompe, sabrá que tiene que ver con la actualización del marco y no con algo que se rompió al implementar una nueva función.

Parte de lo que hace esto tan difícil es que en el tiempo de ejecución solo puede tener una versión de una dependencia particular en su JVM, por lo que debe actualizar todo el código a la vez. OSGi aborda este problema en particular al permitir que diferentes paquetes OSGi que se ejecutan en el mismo dependan de diferentes versiones de dependencia, por lo que podría depender de diferentes versiones de dependencia en tiempo de ejecución. Así es como Eclipse gestiona las dependencias de los complementos sin romper otros complementos.