Kiedy należy aktualizować zależności?

Mieliśmy dwa główne kryzysy związane z zależnościami z dwiema różnymi bazami kodu (Android i aplikacja internetowa Node.js). Repozytorium Androida wymagało migracji z Flurry do Firebase, co wymagało aktualizacji biblioteki usług Google Play czterech głównych wersji. Podobnie stało się z naszą aplikacją Node hostowaną przez Heroku, w której nasz stos produkcyjny (cedr) był przestarzały i wymagał aktualizacji do cedru-14. Nasza baza danych PostgreSQL również wymagała aktualizacji z wersji 9.2 do 9.6.

Zależności każdej z tych aplikacji pozostawały nieaktualne przez prawie dwa lata, a kiedy niektóre były przestarzałe i osiągnęliśmy okres „wygaśnięcia”, poważnym problemem było ich zaktualizowanie lub zastąpienie. W ciągu ostatniego miesiąca spędziłem ponad 30 godzin, powoli rozwiązując wszystkie konflikty i zepsuty kod.

Oczywiście pozostawienie rzeczy na dwa lata jest zdecydowanie za długie. Technologia szybko się rozwija, szczególnie gdy korzystasz z dostawcy platformy, takiego jak Heroku. Załóżmy, że mamy pełnoprawny pakiet testowy i proces CI, taki jak Travis CI, który wymaga dużo zgadywania podczas aktualizacji. Np. Jeśli funkcja została usunięta po aktualizacji, a użytkownik jej używał, testy zakończyłyby się niepowodzeniem.

Jak często należy aktualizować zależności lub kiedy należy aktualizować zależności? Zaktualizowaliśmy, ponieważ byliśmy do tego zmuszeni, ale wydaje się, że lepiej byłoby zastosować podejście wyprzedzające . Czy powinniśmy aktualizować po wydaniu mniejszych wersji? Główne wersje? Co miesiąc, jeśli aktualizacje są dostępne? Chcę uniknąć takiej sytuacji, jakiej właśnie doświadczyłem za wszelką cenę.

PS - w jednym z moich osobistych projektów Railsowych korzystam z usługi Gemnasium, która śledzi twoje zależności, dzięki czemu możesz być powiadamiany np. O zagrożeniach bezpieczeństwa. To świetna usługa, ale musielibyśmy ręcznie sprawdzić zależności dla wspomnianych projektów.

Zasadniczo powinieneś aktualizować zależności, gdy:

1. Jest wymagane
2. Jest to zaleta
3. Nieprzestrzeganie tego jest niekorzystne

(Nie wykluczają się wzajemnie.)

Motywacja 1 („kiedy trzeba”) jest najpilniejszym kierowcą. Wymaga tego jakiś komponent lub platforma, od której zależysz (np. Heroku) i musisz się zgodzić. Wymagane aktualizacje często kaskadują z innych opcji; decydujesz się na aktualizację do wersji PostgreSQL. Teraz musisz zaktualizować sterowniki, wersję ORM itp.

Aktualizacja, ponieważ Ty lub Twój zespół dostrzegacie w tym przewagę, jest bardziej miękka i bardziej opcjonalna. Więcej wezwania do osądu: „Czy nowa funkcja, zdolność, wydajność… są warte wysiłku i dyslokacji, które ją przyniosą?” W Olden Times istniało silne uprzedzenie wobec opcjonalnych ulepszeń. Były ręczne i trudne, nie było dobrych sposobów na wypróbowanie ich w piaskownicylub środowisko wirtualne albo wycofać aktualizację, jeśli nie zadziałała, a nie przeprowadzono szybkich automatycznych testów potwierdzających, że aktualizacje nie „zdenerwowały koszyka na jabłka”. Obecnie tendencyjność polega na znacznie szybszych, bardziej agresywnych cyklach aktualizacji. Zwinne metody uwielbiają próbować różnych rzeczy; zautomatyzowani instalatorzy, menedżerowie zależności i repozytorium sprawiają, że proces instalacji jest szybki i często prawie niewidoczny; środowiska wirtualne i wszechobecna kontrola wersji ułatwiają rozgałęzienia, rozwidlenia i wycofywanie; i zautomatyzowane testowanie pozwala nam wypróbować aktualizację, a następnie łatwo i gruntownie ocenić „Czy to działało? Czy to coś popsuło?” Błąd systematyczny zmienił się hurtowo z „jeśli nie jest zepsuty, nie naprawiaj go” na „aktualizuj wcześnie, aktualizuj często”

Motywacja 3 jest najłagodniejsza. Historie użytkowników nie zajmują się „instalacją wodno-kanalizacyjną” i nigdy nie wspominają „i utrzymują infrastrukturę nie więcej niż N wydań za obecną”. Wady driftu wersji (w przybliżeniu dług techniczny związany z opóźnieniem w zakrzywieniu) wkraczają cicho, a następnie często ogłaszają się przez złamanie. „Przepraszamy, ten interfejs API nie jest już obsługiwany!” Nawet w zespołach Agile może być trudno zmotywować się do inkrementalizmu i „utrzymywania” świeżości komponentów, gdy nie jest to postrzegane jako kluczowe dla ukończenia danego sprintu lub wydania. Jeśli nikt nie opowiada się za aktualizacjami, może przejść bez opieki. Koło może nie pisnąć, dopóki nie będzie gotowe do złamania, a nawet do złamania.

Z praktycznego punktu widzenia zespół musi zwracać większą uwagę na problem związany z przesunięciem wersji. 2 lata to za długo. Nie ma magii. To tylko kwestia „zapłać mi teraz lub zapłać później”. Albo rozwiąż stopniowo problem zmiany wersji, albo cierpieć, a potem co kilka lat przeżywać większe wstrząsy. Wolę inkrementalizm, ponieważ niektóre wstrząsy platformy są ogromne. Kluczowy interfejs API lub platforma, od której zależysz, że już nie działa, może naprawdę zrujnować Twój dzień, tydzień lub miesiąc. Lubię oceniać świeżość składników co najmniej 1-2 razy w roku. Możesz jawnie zaplanować recenzje lub pozwolić, aby były one organicznie uruchamiane przez stosunkowo metronomiczne, zwykle coroczne cykle aktualizacji głównych komponentów, takich jak Python, PostgreSQL i node.js. Jeśli aktualizacje składników nie wyzwalają twojego zespołu bardzo mocno, sprawdzamy świeżość głównych wydań, na naturalnych płaskowyżach projektowych, lub każde k wydań może również działać. Cokolwiek zwraca uwagę na poprawianie wersji, dryfuj w bardziej regularnym rytmie.

Biblioteki powinny zostać zaktualizowane, gdy wymagają aktualizacji. Oznacza to, że jeśli aktualizacja nie przynosi żadnej wartości, nie powinieneś.

W twoim konkretnym przypadku przeprowadzałeś migrację ze starego stosu technologii na nowy, w tym celu musiałeś zaktualizować swoje zależności. Ten moment to właściwy czas na aktualizację zależności.

Gdybyś aktualizował swoje zależności w czasie, aby „nie odczuwać bólu głowy”, musiałbyś zainwestować dużo czasu pracy (kodowania), aby nie zwracać wartości. A kiedy miałbyś zrobić ostatnią aktualizację (tę, którą teraz robisz, ale aktualizujesz 1 główną wersję zamiast 4), prawdopodobnie nadal gdzieś boli cię głowa (w końcu główna wersja oznacza zerwanie zmian). Więc myślę, że podążasz właściwą ścieżką.

Jeśli jednak migracja jest zbyt trudna i trzeba wykonać wiele zmian, istnieje prawdopodobieństwo, że problem leży w bazie kodu. Dość powszechne jest, że projekty Androida nie mają ogólnej architektury pod względem struktury kodu. Dobra struktura wstrzykiwania zależności, taka jak Dagger 2 , oraz kilka zasad inżynierii oprogramowania, takich jak SOLID , ułatwiłyby zmianę implementacji kodu przy zachowaniu tych samych zachowań / wymagań.

Ponadto, ponieważ jesteśmy w trakcie refaktoryzacji, przeczytaj trochę o testowaniu jednostkowym, ponieważ bardzo pomogłoby to podczas wykonywania tego rodzaju pracy.

Jeśli korzystasz z narzędzi do zarządzania pakietami (np. Npm, NuGet) i posiadasz kompleksowy zautomatyzowany pakiet testowy, to aktualizowanie zależności powinno być działaniem łatwym, po prostu zaktualizuj pakiet, uruchom pakiet testowy i sprawdź, czy występują jakieś problemy. W takim przypadku wycofaj i podnieś element roboczy, aby zbadać i naprawić problem.

Dopóki koszt aktualizacji zależności jest niski, warto go aktualizować:

• Jeśli występują problemy z aktualizacją, musisz wiedzieć wcześniej niż później, na wypadek, gdyby konieczne były wcześniejsze zmiany.
• Pozostawienie aktualizacji zależności do ostatniej chwili często oznacza, że ​​wykonujesz te aktualizacje w czasie awarii (np. W odpowiedzi na błąd krytyczny dla bezpieczeństwa). Utrzymywanie kontroli nad swoimi zależnościami oznacza, że ​​masz kontrolę nad tym, kiedy wydajesz ten wysiłek i możesz wykonywać te aktualizacje, gdy nie jesteś tak zajęty.
• W nowszych wersjach mogą występować ulepszenia wydajności, np. Lepsza dokumentacja, łatwiejszy w użyciu interfejs API, poprawki błędów (chociaż możliwe jest również odwrócenie).

Jeśli uaktualnienie zależności nie wymaga niewielkiego wysiłku (np. Ponieważ musisz ręcznie przetestować uaktualnienie lub ponieważ istnieją znane problemy / przełamywanie zmian), musisz porównać zalety i wady w stosunku do innych zadań. Stare zależności są rodzajem niskiego oprocentowania długu technicznego i dlatego należy je odpowiednio traktować.

Nie powinieneś robić wydania, w którym świadomie używasz starych wersji swoich zależności, chyba że te wersje są obsługiwanymi alternatywami.

tzn. jeśli korzystasz z wersji V1 i jest ona nadal obsługiwana, nadal możesz używać najnowszej wersji wersji 1.

Jedyny czas, w którym powinieneś być nieaktualny, to:

Odp .: Nie wydałeś jeszcze żadnej wersji.

B: Używasz wersji v1 tak długo, że nie jest już obsługiwana

Aktualizacje są wydawane z jakiegoś powodu, zawierają poprawki bezpieczeństwa, które powinieneś wziąć na pokład.

Jeśli pojawi się nowa wersja twojej zależności, powinieneś także zrobić wydanie

Myślę, że do pewnego stopnia musi to zależeć od danej biblioteki, ale sam miałem podobne problemy z uzależnieniem.

Zdrowy rozsądek mówi mi, że główna wersja jest prawdopodobnie właściwym momentem na aktualizację, a mniejsza wersja, która rozwiązuje poważną wadę lub zawiera znaczną korzyść, zastąpiłaby to.

Czasami nie mamy luksusu pracy nad każdą aplikacją wymagającą konserwacji, a nawet cofnięcia zadania kluczowego dla misji, ale ostatecznie cię ugryzą, a uncja zapobiegania często przebije funt lekarstwa!

Biblioteki powinny być aktualizowane, gdy oferuje korzyść, z której będzie korzystać oprogramowanie, która rekompensuje nakład pracy związany ze zmianą.

Nawet drobne aktualizacje wersji bibliotek mogą powodować uszkodzenie lub wstawianie niespójności w aplikacjach. Z tej perspektywy nie ma drobnych zmian.

Nie ma wstydu w używaniu starych bibliotek. Kiedy zmiana jest potrzebna, może być bolesna, ale jest częścią pracy.