Przechowywanie bibliotek innych firm w kontroli źródła

Czy biblioteki, na których opiera się aplikacja, powinny być przechowywane w kontroli źródła? Jedna część mnie mówi, że powinno, a druga - nie. Wydaje się niewłaściwe, aby dodać bibliotekę 20 MB, która przyćmiewa całą aplikację tylko dlatego, że polegasz na kilku jej funkcjach (choć dość mocno). Czy powinieneś po prostu przechowywać jar / dll, a może nawet rozproszony zip / tar projektu?

Co robią inni ludzie?

Oprócz posiadania bibliotek innych firm w swoim repozytorium warto to zrobić w taki sposób, aby ułatwić śledzenie i łączenie przyszłych aktualizacji biblioteki (na przykład poprawki bezpieczeństwa itp.). Jeśli używasz Subversion, warto skorzystać z odpowiedniej gałęzi dostawcy .

Jeśli wiesz, że byłby to zimny dzień w piekle, zanim będziesz modyfikował kod swojej strony trzeciej, to (jak powiedział @Matt Sheppard) zewnętrzne ma sens i daje dodatkową korzyść, że bardzo łatwo jest przejść najnowsza wersja biblioteki powinna sprawić, że będzie to pożądane przez aktualizacje zabezpieczeń lub niezbędną nową funkcję.

Możesz również pominąć zewnętrzne podczas aktualizowania zapisywania kodu podstawowego w długim, powolnym procesie ładowania, jeśli zajdzie taka potrzeba.

@Stu Thompson wspomina o przechowywaniu dokumentacji itp. W kontroli źródła. W większych projektach przechowywałem cały folder naszych klientów w kontroli źródła, w tym faktury / rachunki / protokoły ze spotkań / specyfikacje techniczne itp. Cały mecz strzelecki. Chociaż, ahem, pamiętaj, aby przechowywać je w ODDZIELNYM repozytorium od tego, które będziesz udostępniać: innym programistom; Klient; Twój „widok źródła przeglądarki” ... kaszle ... :)

przechowuj wszystko, czego będziesz potrzebować do zbudowania projektu za 10 lat, na wszelki wypadek przechowuję całą dystrybucję zip dowolnej biblioteki

Edycja na rok 2017: Ta odpowiedź nie starzeje się dobrze :-). Jeśli nadal używasz czegoś starego, takiego jak ant lub make, powyższe nadal ma zastosowanie. Jeśli używasz czegoś bardziej nowoczesnego, takiego jak maven lub graddle (lub na przykład Nuget w .net), z zarządzaniem zależnościami, oprócz serwera kontroli wersji powinieneś uruchomić serwer zarządzania zależnościami. Tak długo, jak masz dobre kopie zapasowe obu, a serwer zarządzania zależnościami nie usuwa starych zależności, wszystko powinno być w porządku. Aby zapoznać się z przykładem serwera zarządzania zależnościami, zobacz między innymi Sonatype Nexus lub JFrog Artifcatory .

Nie przechowuj bibliotek; nie są ściśle mówiąc częścią twojego projektu i bezużytecznie zajmują miejsce w twoim systemie kontroli wersji. Jednak używaj maven (lub Ivy w przypadku kompilacji mrówek), aby śledzić, z jakich wersji bibliotek zewnętrznych korzysta twój projekt. Powinieneś uruchomić kopię lustrzaną repozytorium w swojej organizacji (która jest zarchiwizowana), aby mieć pewność, że zależności zawsze masz pod kontrolą. To powinno dać ci to, co najlepsze z obu światów; zewnętrzne słoiki poza Twoim projektem, ale nadal niezawodnie dostępne i dostępne centralnie.

Biblioteki przechowujemy w kontroli źródła, ponieważ chcemy mieć możliwość zbudowania projektu, po prostu sprawdzając kod źródłowy i uruchamiając skrypt kompilacji. Jeśli nie jesteś w stanie pobrać najnowszych i zbudować w jednym kroku, napotkasz problemy dopiero później.

nigdy nie przechowuj plików binarnych innych firm w kontroli źródła. Systemy kontroli źródła to platformy obsługujące współbieżne udostępnianie plików, pracę równoległą, łączenie wysiłków i historię zmian. Kontrola źródła nie jest witryną FTP dla plików binarnych. Zespoły innych firm NIE są kodem źródłowym; zmieniają się może dwa razy na SDLC. Pragnienie, aby móc wyczyścić obszar roboczy, usunąć wszystko z kontroli źródła i kompilacji, nie oznacza, że ​​zestawy innych firm muszą utknąć w kontroli źródła. Za pomocą skryptów kompilacji można sterować pobieraniem zestawów innych firm z serwera dystrybucji. Jeśli obawiasz się kontrolowania, która gałąź / wersja aplikacji używa określonego komponentu innej firmy, możesz to również kontrolować za pomocą skryptów kompilacji. Ludzie wspominali o Maven dla Java i możesz zrobić coś podobnego z MSBuild dla .Net.

Generalnie przechowuję je w repozytorium, ale sympatyzuję z twoim pragnieniem zmniejszenia rozmiaru.

Jeśli nie przechowujesz ich w repozytorium, absolutnie trzeba je jakoś zarchiwizować i wersjonować, a twój system kompilacji musi wiedzieć, jak je zdobyć. Wydaje się, że wiele osób w świecie Javy używa Mavena do automatycznego pobierania zależności, ale ja nie używałem I, więc tak naprawdę nie mogę polecać tego za lub przeciw.

Dobrą opcją może być przechowywanie oddzielnego repozytorium systemów firm trzecich. Jeśli korzystasz z Subversion, możesz następnie użyć zewnętrznego wsparcia Subversion, aby automatycznie sprawdzić biblioteki z innego repozytorium. W przeciwnym razie sugerowałbym zachowanie wewnętrznego anonimowego serwera FTP (lub podobnego), z którego system kompilacji może automatycznie pobierać wymagania. Oczywiście będziesz chciał się upewnić, że zachowujesz wszystkie stare wersje bibliotek i masz tam kopię zapasową wszystkiego wraz z repozytorium.

To, co mam, to intranetowe repozytorium podobne do Mavena, w którym przechowywane są wszystkie biblioteki innych firm (nie tylko biblioteki, ale ich odpowiednia dystrybucja źródeł wraz z dokumentacją, Javadoc i wszystkim). Powód jest następujący:

1. po co przechowywać pliki, które się nie zmieniają, w systemie zaprojektowanym specjalnie do zarządzania plikami, które się zmieniają?
2. to radykalnie przyspiesza kasy
3. za każdym razem, gdy widzę plik „something.jar” przechowywany pod kontrolą źródła, pytam „i która to wersja?”

Umieściłem wszystko oprócz JDK i IDE w kontroli źródła.

Filozofia Tony'ego jest rozsądna. Nie zapomnij o skryptach do tworzenia baz danych i skryptach do aktualizacji struktury danych. Zanim pojawiły się strony wiki, nawet przechowywałem naszą dokumentację w kontroli źródła.

Wolę przechowywać biblioteki stron trzecich w repozytorium zależności ( na przykład Artifactory z Mavenem ), zamiast przechowywać je w Subversion.

Ponieważ biblioteki innych firm nie są zarządzane ani wersjonowane tak jak kod źródłowy, nie ma sensu ich mieszać. Zdalni programiści doceniają również brak konieczności pobierania dużych bibliotek przez powolne łącze WPN, gdy mogą je łatwiej pobrać z dowolnej liczby repozytoriów publicznych.

U poprzedniego pracodawcy wszystko, co niezbędne do tworzenia aplikacji, przechowywaliśmy pod kontrolą źródła. Uruchomienie nowej maszyny kompilacji wymagało synchronizacji z kontrolą źródła i zainstalowania niezbędnego oprogramowania.

Przechowuj biblioteki innych firm w kontroli źródła, aby były dostępne, jeśli sprawdzisz kod w nowym środowisku programistycznym. Wszelkie polecenia „włączania” lub budowania, które możesz mieć w skryptach budowania, powinny również odnosić się do tych „lokalnych” kopii.

Oprócz zapewnienia, że ​​kod lub biblioteki stron trzecich, na których polegasz, są zawsze dostępne, powinno to również oznaczać, że kod jest (prawie) gotowy do zbudowania na nowym komputerze lub koncie użytkownika, gdy nowi programiści dołączą do zespołu.

Przechowuj biblioteki! Repozytorium powinno być migawką tego, co jest wymagane do zbudowania projektu w dowolnym momencie. Ponieważ projekt wymaga innej wersji bibliotek zewnętrznych, będziesz chciał zaktualizować / sprawdzić nowsze wersje tych bibliotek. W ten sposób będziesz w stanie uzyskać właściwą wersję, która będzie pasować do starej migawki, jeśli będziesz musiał załatać starszą wersję itp.

Osobiście mam folder zależności jako część moich projektów i przechowuję tam biblioteki, do których się odwołuję.

Uważam, że ułatwia to życie, ponieważ pracuję nad wieloma różnymi projektami, często z zależnymi od siebie częściami, które wymagają tej samej wersji biblioteki, co oznacza, że ​​aktualizacja do najnowszej wersji danej biblioteki nie zawsze jest wykonalna.

Posiadanie wszystkich zależności używanych podczas kompilacji dla każdego projektu oznacza, że ​​kilka lat później, gdy sprawy się posunęły, nadal mogę zbudować dowolną część projektu, nie martwiąc się o zepsucie innych części. Uaktualnienie do nowej wersji biblioteki to po prostu przypadek zastąpienia pliku i przebudowania powiązanych komponentów, co nie jest zbyt trudne w zarządzaniu, jeśli zajdzie taka potrzeba.

Powiedziawszy to, uważam, że większość bibliotek, do których się odwołuję, jest stosunkowo niewielkich rozmiarów, ważących około kilkuset kb, rzadko większych, co sprawia, że ​​mniejszym problemem jest dla mnie umieszczenie ich w kontroli źródła.

Użyj podprojektów git i albo odwołania z głównego repozytorium git biblioteki innej firmy, albo (jeśli go nie ma) utwórz nowe repozytorium git dla każdej wymaganej biblioteki. Nie ma powodu, dla którego jesteś ograniczony tylko do jednego repozytorium git i nie polecam używania cudzego projektu jako zwykłego katalogu we własnym.

przechowuj wszystko, czego potrzebujesz do zbudowania projektu, abyś mógł to sprawdzić i zbudować bez wykonywania jakichkolwiek czynności.

(i jako osoba, która doświadczyła bólu - zachowaj kopię wszystkiego, co jest potrzebne do zainstalowania elementów sterujących i pracy na platformie deweloperskiej. Kiedyś otrzymałem projekt, który można zbudować - ale bez pliku instalacyjnego i kluczy rejestracyjnych nie można nie wprowadzaj żadnych zmian w układzie sterowania innej firmy. To była fajna przeróbka)

Musisz przechowywać wszystko, czego potrzebujesz, aby zbudować projekt. Ponadto różne wersje Twojego kodu mogą mieć różne zależności od stron trzecich. Będziesz chciał rozgałęzić swój kod na wersję konserwacyjną wraz z zależnościami innych firm ...

Osobiście zrobiłem i do tej pory podobało mi się, że wyniki to przechowywanie bibliotek w oddzielnym repozytorium, a następnie łącze do każdej biblioteki, której potrzebuję w innych moich repozytoriach, za pomocą funkcji Subversion svn: externals. Działa to dobrze, ponieważ mogę przechowywać wersjonowane kopie większości naszych bibliotek (głównie zarządzanych zestawów .NET) w kontroli źródła bez zwiększania przez nie rozmiaru naszego głównego repozytorium kodu źródłowego. Posiadanie zestawów przechowywanych w repozytorium w ten sposób sprawia, że ​​serwer kompilacji nie musi ich instalować, aby utworzyć kompilację. Powiem, że doprowadzenie kompilacji do sukcesu bez zainstalowania programu Visual Studio było dość uciążliwe, ale teraz, gdy zaczęliśmy działać, jesteśmy z tego zadowoleni.

Zwróć uwagę, że obecnie nie używamy wielu komercyjnych pakietów kontrolnych innych firm lub podobnych rzeczy, więc nie napotkaliśmy problemów z licencją, w przypadku których może być konieczne zainstalowanie zestawu SDK na serwerze kompilacji, ale widzę, gdzie to łatwo może stać się problemem. Niestety nie mam na to rozwiązania i zamierzam rozwiązać ten problem, gdy pierwszy raz go spotkam.