Gestión de dependencias para grandes proyectos

Question

Estoy trabajando en un proyecto bastante grande. Tenemos muchos proyectos y cada proyecto tiene dependencias. Usamos maven y normalmente no tenemos ningún problema. Así, sin dar muchos detalles, imagina que para un proyecto determinado, por ejemplo, tps-reports la sección dependencias del pom.xml parece:

<name>TPS-Reports</name> 
    <description> 
    TPS Reports frontend. 
    </description> 
    <dependencies> 
    <dependency> 
    <groupId>com.initech</groupId> 
    <artifactId>gui-components</artifactId> 
    <version>2.5</version> 
    </dependency> 
    <dependency> 
    <groupId>com.initech</groupId> 
    <artifactId>multithreading</artifactId> 
    <version>3.7</version> 
    </dependency> 
    <dependency> 
    <groupId>com.initech</groupId> 
    <artifactId>utils</artifactId> 
    <version>2.3.0.0</version> 
    </dependency> 
    <dependency> 
    <!-- TODO: update to new version --> 
    <groupId>com.initech</groupId> 
    <artifactId>object-pooling</artifactId> 
    <version>1.9.3.1</version> 
    </dependency> 
    </dependencies> 

Ahora, Initech tiene un montón de proyectos que dependen de, por ejemplo, object-pooling, que también depende de muchos otros componentes más, como (utils y multithreading).

La vida es buena para los desarrolladores de object-pooling. Es un módulo bastante estable y todo va bien. Como cualquier otro módulo, también tiene dependencias. object-pooling los desarrolladores son todos caballeros y damas de feria y cada vez que encuentran un error crítico, actualizan todos los proyectos que dependen de object-pooling.

Ahora, la versión 1.9.3.1 de object-pooling es estable y no tiene errores críticos conocidos. Los desarrolladores trabajan muy duro para agregar un montón de nuevas características y después de un tiempo, lanzan la versión 2.0.0.0. Por supuesto, entre 1.9.3.1 y 2.0.0.0, hay versiones intermedias (por ejemplo, 1.9.3.1, 1.9.3.2, 1.9.4.0, 1.9.5.3, etc.). Como dije, la vida es buena para los desarrolladores de object-pooling. La versión 2.0.0.0 tiene nuevas características y muchas correcciones.

Sin embargo, el infierno está a la vuelta de la esquina para los desarrolladores de tps-reports. Han estado usando 1.9.3.1 desde hace bastante tiempo y, dado que no hay errores conocidos en esta versión, se sienten cómodos con una versión anterior. Ahora, quieren utilizar el object-pooling renovado, por lo que actualicen su pom.xml utilizar la versión 2.0.0.0 y ahora se ve así:

<name>TPS-Reports</name> 
    <description> 
    TPS Reports frontend. 
    </description> 
    <dependencies> 
    <dependency> 
    <groupId>com.initech</groupId> 
    <artifactId>gui-components</artifactId> 
    <version>2.5</version> 
    </dependency> 
    <dependency> 
    <groupId>com.initech</groupId> 
    <artifactId>multithreading</artifactId> 
    <version>3.7</version> 
    </dependency> 
    <dependency> 
    <groupId>com.initech</groupId> 
    <artifactId>utils</artifactId> 
    <version>2.3.0.0</version> 
    </dependency> 
    <dependency> 
    <!-- use object poooling's new features --> 
    <groupId>com.initech</groupId> 
    <artifactId>object-pooling</artifactId> 
    <version>2.0.0.0</version> 
    </dependency> 
    </dependencies> 

Ellos descubren que tienen nuevos errores. Huelga decir que estos errores no existían cuando dependían de la versión 1.9.3.1 de object-pooling. Buscan en el registro de su repositorio de código y descubren que, no solo los chicos object-pooling han hecho miles de confirmaciones, sino también que están usando las versiones más recientes de multithreading y utils, que también tienen muchas confirmaciones.

Hay, obviamente, una gran cantidad de lugares donde puede residir el problema. Puede estar en object-pooling, puede estar en la interacción entre object-pooling y tps-reports, puede estar en multithreading o utils o en cualquier combinación extraña.

La (s) pregunta (s) es (son): ¿Cómo manejan este tipo de problemas? ¿Cómo gestionas las dependencias en grandes proyectos que a su vez dependen de otros proyectos? ¿Hay algunas herramientas para ayudar en esta tarea?

Gracias!

Answer 1

Lo sentimos, no hay ninguna bala de plata aquí: la prueba de unidad es la respuesta. Cuanto más grande sea el proyecto, más importante será la prueba automática.

En su caso, incluso si los errores surgen en las pruebas manuales, finalmente se trata de casos particulares de uso de la biblioteca y es posible que pueda reducir esto a una prueba unitaria. La prueba pasará en 1.9.3.1 y fallará en 2.0.0.0.

Ahora puede enviar el caso de prueba a los desarrolladores de agrupación de objetos y decirles que no se están actualizando hasta que pasen esta y otras pruebas. Esto hará que su vida sea un poco como la tuya y dado suficientes casos de prueba, tu vida será más parecida a la suya :-)

Si el error está en su biblioteca dependiente, tendrán que hacer lo mismo con sus usuarios desarrolladores.

Answer 2

Usaría varias configuraciones de pom y las pondría todas en un servidor de integración continua para obtener una visión general bajo qué circunstancias fallan ciertas pruebas.