Zarządzanie zależnościami dla dużych projektów

Question

Pracuję w dość dużym projekcie. Mamy wiele projektów i każdy projekt ma zależności. Używamy maven i zwykle nie mamy żadnych problemów. Tak więc, nie dając wiele szczegółów, wyobrazić sobie, że dla danego projektu, powiedzmy, tps-reports sekcja zależności od pom.xml wygląda następująco:

<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> 

Teraz, Initech ma mnóstwo projektów, które zależą od, powiedzmy, object-pooling, które również zależy od wielu innych składników, takich jak (utils i multithreading).

Życie jest dobre dla programistów . Jest to dość stabilny moduł i wszystko idzie dobrze. Jak każdy inny moduł, ma również zależności. object-pooling programiści to dżentelmeni i uczciwe kobiety, a gdy tylko znajdą krytyczny błąd, aktualizują wszystkie projekty zależne od object-pooling.

Teraz wersja 1.9.3.1 z object-pooling jest stabilna i nie ma znanych błędów krytycznych. Programiści bardzo ciężko pracują nad dodaniem mnóstwa nowych funkcji, a po pewnym czasie wypuszczają wersję 2.0.0.0. Oczywiście, pomiędzy 1.9.3.1 i 2.0.0.0, istnieją pośrednie wydania (na przykład 1.9.3.1, 1.9.3.2, 1.9.4.0, 1.9.5.3 itd.). Jak już powiedziałem, życie jest dobre dla programistów object-pooling. Wersja 2.0.0.0 ma nowe funkcje i wiele poprawek.

Jednak piekło jest tuż za rogiem dla deweloperów tps-reports. Już od jakiegoś czasu używają 1.9.3.1, a ponieważ nie ma znanych błędów w tej wersji, są wygodne ze starą wersją. Teraz chcą używać przebudowana object-pooling, więc aktualizować ich pom.xml używać wersji 2.0.0.0 i teraz wygląda tak:

<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> 

Odkrywają, że mają nowe błędy. Nie trzeba dodawać, że te błędy nie istniały, gdy zależały od wersji 1.9.3.1 z object-pooling. Przeszukują dziennik repozytorium kodu i odkrywają, że nie tylko użytkownicy object-pooling wykonali tysiące zatwierdzeń, ale także, że używają najnowszych wersji multithreading i utils, które również mają wiele zatwierdzeń.

Istnieje oczywiście mnóstwo miejsc, w których problem może się pojawić. Może być na object-pooling, może być w interakcji między object-pooling i tps-reports, może być na multithreading lub utils lub dowolnej dziwnej kombinacji.

Pytanie (-a) jest (są): Jak sobie radzicie z tego rodzaju problemami? Jak zarządzać zależnościami od dużych projektów, które z kolei zależą od innych projektów? Czy są jakieś narzędzia, które pomagają w tym zadaniu?

Dzięki!

Answer 1

Niestety, brak tu srebrnej kuli: testowanie jednostkowe jest odpowiedzią. Im większy projekt, tym ważniejsze automatyczne testy stają się.

W twoim przypadku, nawet jeśli błędy pojawiają się w testach ręcznych, ostatecznie sprowadza się do konkretnego przypadku korzystania z biblioteki i możesz być w stanie zmniejszyć to do testu jednostkowego. Test przejdzie w wersji 1.9.3.1 i zakończy się niepowodzeniem w wersji 2.0.0.0.

Teraz możesz wysłać testową sprawę do programistów tworzących pulę i powiedzieć im, że nie aktualizujesz, dopóki nie przejdzie tego i innych testów. To sprawi, że ich życie będzie trochę jak twoje i otrzymasz wystarczająco dużo testów, twoje życie będzie bardziej podobne do ich :-)

Jeśli błąd jest w ich bibliotece zależnej, będą musieli zrobić to samo programistów.

Answer 2

Używałbym kilku konfiguracji pom i umieścił je wszystkie w serwerze integracji kontynentów, aby uzyskać przegląd sytuacji, w których niektóre testy zawodzą.