Jak dbać o aktualność bibliotek stron trzecich?

Powiedzmy, że mam projekt, który zależy od 10 bibliotek, a w ramach mojego projektu mogę swobodnie korzystać z dowolnych wersji tych bibliotek. Zacznę więc od najnowszych wersji. Następnie każda z tych bibliotek otrzymuje aktualizację raz w miesiącu (średnio). Teraz, aby mój pień był całkowicie aktualny, wymagałbym aktualizacji odwołania do biblioteki co trzy dni.

To oczywiście za dużo. Chociaż zazwyczaj wersja 1.2.3 zastępuje wersję 1.2.2, nigdy nie wiadomo bez testowania. Testy jednostkowe to za mało; jeśli jest to silnik plików / DB, musisz upewnić się, że działa on poprawnie z plikami utworzonymi w starszych wersjach i być może na odwrót. Jeśli ma to coś wspólnego z graficznym interfejsem użytkownika, musisz wszystko sprawdzić wizualnie. I tak dalej.

Jak sobie z tym poradzisz? Niektóre możliwe podejścia:

• Jeśli nie jest zepsuty, nie naprawiaj go . Zostań ze swojej aktualnej wersji biblioteki tak długo jak ty nie zauważają nic złego się z nim, gdy używany w aplikacji, nie ważne jak często sprzedawca biblioteka publikuje aktualizacje. Małe przyrostowe zmiany to tylko marnotrawstwo.
• Aktualizuj często, aby zmiany pozostały niewielkie. Ponieważ w każdym razie będziesz musiał zaktualizować, lepiej aktualizować często, abyś zauważył wszelkie problemy wcześnie, gdy można je łatwo naprawić, zamiast przeskakiwać kilka wersji i pozwolić na potencjalne problemy.
• Coś pomiędzy. Czy jest jakieś słodkie miejsce?

Jestem zszokowany - i naprawdę przerażony - liczbą odpowiedzi tutaj: „nie aktualizuj, chyba że musisz”. Zrobiłem to i chociaż na krótką metę jest to łatwiejsze, na dłuższą metę pali się jak diabli. Częstsze, mniejsze aktualizacje są znacznie, znacznie łatwiejsze do zarządzania niż sporadyczne duże, a Ty zyskujesz korzyści z nowych funkcji, poprawek błędów i tak dalej.

Nie kupuję tego, że zmiany w bibliotece są trudniejsze do przetestowania niż zmiany w kodzie. Tak samo jest - wprowadzasz zmiany w bazie kodu i musisz je zweryfikować przed zatwierdzeniem i głębiej przed wydaniem. Ale musisz już mieć do tego odpowiednie procesy, ponieważ wprowadzasz zmiany w kodzie!

Jeśli pracujesz w iteracjach, trwających od dwóch do czterech tygodni, sugerowałbym, aby aktualizować biblioteki raz na zadanie iteracji, aby było to zrobione jak najszybciej po rozpoczęciu, gdy sprawy są nieco bardziej zrelaksowane niż tuż przed iteracją termin, a projekt ma większą zdolność do wchłaniania zmian. Poproś kogoś (lub parę, jeśli wykonujesz programowanie w parach), aby usiadł, sprawdź, które biblioteki zostały zaktualizowane, i spróbuj uruchomić każdą z nich i uruchomić przebudowę i test. Być może przeznaczasz na to od pół do jednego dnia na każdą iterację. Jeśli coś działa, sprawdź zmiany (zakładam, że utrzymujesz biblioteki pod kontrolą źródła, tak jak my; nie jestem pewien, jak propagowałbyś zmianę w kontrolowany sposób, jeśli nie). Będzie to oczywiście o wiele łatwiejsze, jeśli masz zautomatyzowane testy, niż jeśli testy są całkowicie ręczne.

Pytanie brzmi, co robisz, jeśli aktualizacja psuje rzeczy - czy poświęcasz czas na ich naprawianie, czy pomijasz? Sugerowałbym pochylenie się w tym drugim; jeśli można to naprawić w ciągu godziny, zrób to, ale jeśli aktualizacja będzie wymagała znacznej pracy, aby ją zintegrować, to podnieś ją jako własne zadanie programistyczne, które ma być oszacowane, uszeregowane według priorytetów i zaplanowane tak jak każde inne. Szanse są takie, że jeśli nie wprowadzi jakiejś bardzo istotnej poprawki lub poprawy, priorytet będzie niski i nigdy się do tego nie obejdziesz. Ale nigdy nie wiadomo, zanim nadejdzie kolejna iteracyjna aktualizacja dnia, problem mógł się rozwiązać; nawet jeśli nie, przynajmniej teraz wiesz, że na ścieżce aktualizacji jest blokada i nie zaskoczy Cię.

Jeśli nie wykonujesz iteracji o takiej długości, skonfigurowałbym jakiś autonomiczny harmonogram aktualizacji - nie dłużej niż raz w miesiącu. Czy jest jakiś inny rytm projektu, z którym możesz go powiązać, na przykład comiesięczny przegląd statusu lub spotkanie rady architektury? Dzień wypłaty? Noc pizzy? Pełnia księżyca? Cokolwiek, musisz znaleźć coś znacznie krótszego niż tradycyjny cykl wydawniczy, ponieważ próba aktualizacji wszystkiego za jednym razem co 6-18 miesięcy będzie bolesna i demoralizująca.

Nie trzeba dodawać, że jeśli wykonasz gałęzie stabilizacji przed wydaniami, nie zastosujesz wobec nich tej polityki. Tam można tylko aktualizować biblioteki, aby uzyskać krytyczne poprawki.

Oceniam

• Po pierwsze szukam błędów, które zgłosiliśmy w stosunku do tej biblioteki i sprawdzam, czy zostały naprawione.
• Po drugie, szukam innych poprawek błędów w bibliotece, z których moglibyśmy skorzystać (być może coś, co jest możliwym przypadkiem narożnym).
• Po trzecie, szukam ulepszeń w lib / API, a następnie badam wpływ zmiany naszego kodu, aby to wykorzystać i korzyści. W przeszłości zbyt często aktualizowałem biblioteki bez faktycznego korzystania z ich nowych funkcji, naprawdę głupie!

Następnie porównuję to z pozostałością istniejącej biblioteki.

Zawsze testuj - mam nadzieję, że testy jednostkowe / integracyjne zapewnią, że nie dojdzie do poważnych regresji.

Główny problem z bibliotekami stron trzecich polega na tym, że musisz ponownie przetestować aplikację podczas aktualizacji, zanim zacznie ona być produkowana. Więc jeśli nie masz zgłoszonego błędu, który wymaga aktualizacji biblioteki, nie dotykaj ich, dopóki nie będziesz mieć czasu na wykonanie pełnego cyklu zapewnienia jakości.

Zwykle odbywa się to po wydaniu nowej wersji.

Sugerowałbym jednak, aby dysponować pakietem testowym do ciągłej kompilacji, który pozwala aktualizować biblioteki w gałęzi programistycznej i robić to automatycznie. Zapewni to wczesne wykrycie, kiedy się zepsuje, abyś mógł zgłaszać zgłoszenia błędów do projektu.

Częściowo, jak opisano w gałęziach dostawców svn . Opisana tam procedura jest bardzo przydatna, gdy przez długi czas używasz bibliotek innych firm typu open source i wprowadzasz zmiany, aby dostosować je do swoich potrzeb.

Pomyślałbym o zaktualizowaniu wszystkich bibliotek projektu tuż przed wydaniem lub tuż po jego wydaniu. Może to jednak wymknąć się spod kontroli, jeśli polegasz na więcej niż 10 lub 15 bibliotekach, w którym to przypadku jakiś mechanizm sprawdzania aktualizacji bardzo by pomógł. Zaletą tego jest to, że masz czas poświęcony na testowanie bibliotek i możesz rozwiązać wszelkie problemy za jednym przejściem. Nie musisz także stale śledzić aktualizacji z każdej biblioteki, po prostu sprawdzasz w danym dniu jakieś aktualizacje.

Byłbym także przeciwny jakiejkolwiek funkcji automatycznej aktualizacji nawet w gałęzi deweloperów. Byłoby frustrujące, gdyby w środku pracowałem nad czymś, co projekt się zepsuł, ponieważ biblioteka automatycznie się zaktualizowała, albo nagle dostałem ostrzeżenia o deprecjacji za używanie interfejsu API, który właśnie został zastąpiony przez coś innego.

Musisz zapytać, czego naprawdę chcesz od aktualizacji? Większość poprawek bezpieczeństwa to tak naprawdę trywialne łatki, w postaci poprawek:

• Wyłączony przez jeden błąd, w którym dowolny kod można skopiować na nieużywane miejsce w buforze
• Zwisające wskaźniki lub coś innego, co wyzwala niezdefiniowane, ale (raczej) deterministyczne zachowanie
• Błędy, które pozwalają na pewien rodzaj DoS
• Błędy, które przypadkowo ułatwiają szpiegowanie prywatnych danych
• Błędy matematyczne
• Opiekunowie dotykają rzeczy, których nie powinni (błąd Debiana SSL, ktoś?)

Jeśli przejrzysz większość CVE w ciągu ostatnich pięciu lat, łatki, które je naprawiają, są zazwyczaj dość trywialne, jeśli używasz otwartych bibliotek, które mam nadzieję.

Następnie masz aktualne poprawki błędów, które prawdopodobnie chcesz, ale być może już je naprawiłeś. Jeśli nie jest zepsuty, nie naprawiaj go.

Wreszcie masz nowe funkcje ... i być może przestarzałe. Musisz dokładnie zapoznać się z uwagami do wydania i różnicami. Czy potrafisz ich używać, nawet jeśli psują interfejs API, od którego zależy wiele innych rzeczy? Jeśli tak, czas na operację. Jeśli nie, wybierz to, co chcesz i idź dalej.

Niektórzy mogą się ze mną nie zgadzać, ale odmawiam korzystania z biblioteki bez kodu źródłowego.

Różni się w zależności od rzeczy, takich jak biblioteki, do czego są używane, jak wszechobecne są w twoim kodzie, koszt (pod względem czasu i pieniędzy) wykonania aktualizacji i tak dalej.

Idealnie byłoby zawsze mieć najnowszą przez cały czas, ale jeśli nowa wersja nie jest kompatybilna wstecz, co wtedy? Być może będziesz musiał odłożyć tę aktualizację do przyszłej wersji, dopóki nie poradzisz sobie ze zmianą ostrożnie. Może wystąpić pewna subtelna zmiana w zachowaniu (np. „Musisz teraz ustawić właściwość X przed wywołaniem metody Y lub dostaniesz powolnego wycieku pamięci”), co jest trudne do zweryfikowania w testach.

Z drugiej strony nowa wersja może zawierać poważne poprawki bezpieczeństwa, więc należy to również wziąć pod uwagę.

Wersja skrócona: weź ją indywidualnie dla każdego przypadku.

To zależy od twoich harmonogramów wydania.

Ale moją radą byłoby zainstalowanie zestawu bibliotek na wszystkich komputerach programistów. Uważaj to za złoty standard, jeśli chcesz to nazwać, a następnie rozpocznij prace nad tym wydaniem.

Dopiero po wdrożeniu wydania i przejściu w fazę po wydaniu ponownie ocenia się biblioteki, ich wersje i funkcje. Jeśli oferują znaczące ulepszenia lub nowe funkcje, zainstaluj je przed rozpoczęciem następnego cyklu programowania.

Instaluj nowe wersje tylko wtedy, gdy występuje poważny problem lub błąd, który należy naprawić przed wdrożeniem oprogramowania.

Oznacza to, że przegapisz niektóre wersje, ale powinno zaoszczędzić trochę problemów i problemów z wersją, pozwalając Ci skoncentrować się na rozwoju aplikacji.

Subversion Zewnętrzne

Zaletą tej funkcji jest to, że możesz określić żądaną wersję.

Pamiętaj, że aktualizacje będą wolniejsze, jeśli masz wiele zewnętrznych.

Obecnie konfiguruję coś takiego:

• 1 repozytorium rtęciowe dla każdego rozszerzenia mojej aplikacji
• repozytorium rtęciowe, które gromadzi określone wersje kilku bibliotek stron trzecich
• repozytorium SVN dla zasobów / prac graficznych (ale może zmienić się na coś innego)
• repozytorium mercurial dla mojej aplikacji, które korzysta z funkcji mercurial subrepos do użycia określonej wersji repozytorium 3 pary oraz niektórych podstawowych rozszerzeń

Teraz, gdy muszę pracować nad rozszerzeniem, które nie jest „podstawowe” (domyślnie włączone jako subrepo w repozytorium aplikacji), po prostu klonuję repozytorium w folderze rozszerzeń i pozwalam CMake generować projekty i rozwiązania dla całej aplikacji.

W ten sposób mogę:

• zmień strony trzecie w klonie, sprawdź, czy działa z aplikacją, wypchnij je w repozytorium 3rd pary, a następnie zaktualizuj wersję subrepo repozytorium aplikacji do nowej wersji repozytorium trzeciej strony
• pracować nad rozszerzeniami niezależnie, wszystkie razem lub po prostu wybrać jakieś konkretne
• Cmake nie musi się martwić koniecznością łączenia projektów, po prostu skanując podrepki projektów wraz z repozytorium całej aplikacji.

Nie mam jeszcze dużego doświadczenia w tej organizacji, ale myślę, że to całkiem przydatne.

Jeśli twoje oprogramowanie ma krytyczne znaczenie dla bezpieczeństwa, musisz zaktualizować jak najszybciej, bez wymówek. Nie chcesz, aby mały błąd w bibliotece graficznej naraził cały twój program.

W przeciwnym razie, gdy lib jest dojrzały, to „Jeśli nie jest zepsuty, nie naprawiaj go”. dla mnie. Prędzej czy później może potrzebuję funkcji późniejszej wersji i nie mam wyboru i muszę ją zaktualizować, ale do tego czasu wysiłek jest trudny do uzasadnienia. Z drugiej strony, kiedy pracuję ze stosunkowo nową biblioteką lub frameworkiem, takim jak Grails lub ExtJS, jestem na bieżąco z najnowszą wersją, ponieważ produkty te nie wydają się jeszcze w pełni dojrzałe, więc aktualizacja może mnie uratować od uruchomienia jednego z tych błędów została naprawiona późniejsza wersja.

Korzystam z NuGet, aby aktualizować biblioteki stron trzecich.

Gdy znajomy, współpracownik lub blog powiadomi mnie, że jedna z moich bibliotek DLL innych firm jest nieaktualna, NuGet bardzo ułatwia jej aktualizację.