Czy dobrą praktyką jest przechowywanie środowisk wykonawczych frameworka pod kontrolą źródła?

9

Wiem, że wiele sklepów z oprogramowaniem utrzymuje pliki binarne pod kontrolą źródła . Jednak nasz sklep przyszedł do przechowywania całych ram w repozytorium: środowiska wykonawczego DirectX, CUDA, nVidia Optix, cokolwiek.

Mówi się, że ułatwia konfigurację maszyny deweloperskiej (podobno pobierz najnowszą wersję i zacznij kodować). Jednak znacznie powiększa repozytorium i obciąża go nieistotną historią.

Nigdy nie widziałem takiego wzorca użytkowania. Czy uważasz to za dobrą praktykę?

[EDYCJA:] Nie mam problemu z kontrolowanymi źródłami izolowanych plików binarnych innych firm. Pytanie dotyczy całych środowisk uruchomieniowych frameworka, zwykle składających się z ponad 10 plików binarnych. Jako skrajny przykład weźmy Windows SDK (którego nie przechowujemy w repozytorium, dzięki Bogu, ale zasadniczo nie widzę różnicy).

Ofek Shilon
źródło
1
Możesz utworzyć skrypt, który pobiera najnowsze lub odpowiednie środowiska wykonawcze frameworka, i poddać ten skrypt kontroli wersji.
Basile Starynkevitch,
2
Jak myślisz, dlaczego obciąża [repozytorium] nieistotną historią ? Mówiąc dokładniej, dlaczego uważasz, że historia jest nieistotna ? Jeśli twój kod odwołuje się do tych frameworków i bibliotek, bardzo pomocne jest wiedzieć, które wersje były używane podczas konkretnej wersji w repozytorium.
James McNellis
Zgadzam się na wzdęcia (szczególnie jeśli te środowiska wykonawcze są współużytkowane przez wiele projektów), ale nie rozumiem części o nieistotnej historii. Zmiana, na przykład, której wersji środowiska uruchomieniowego używasz, jest dość istotna ...
6502
Czy nie będzie łatwiej tworzyć obrazy maszyny dewelopera, gdy pojawią się aktualizacje?
Ramhound,
@Ramhound: właśnie w tym kierunku staram się pchać. Zastanawiałem się, czy brakuje mi wad.
Ofek Shilon

Odpowiedzi:

6

Pliki binarne zasadniczo nie są odpowiednie dla systemu kontroli wersji, ponieważ:

  • nie korzystają z funkcji kontroli wersji (scalanie, porównywanie)
  • zwiększają rozmiar repo ...
  • ... co ma znaczenie, ponieważ nie można łatwo usunąć wersji z VCS (VCS zostały stworzone do przechowywania historii), w przeciwieństwie do repozytoriów artefaktów, takich jak Nexus , które są prostymi udostępnionymi katalogami (łatwe do czyszczenia: cd+ rm!)
  • powinny być przywoływane w VCS jako tekst , deklaracja ścieżki + wersja: możesz w ten sposób zachować odpowiednią historię , rejestrując każdą zmianę wersji binarnej jako zmianę w tym pliku tekstowym (np. pom.xml, jeśli używasz Nexusa na przykład)
VonC
źródło
1
Ostatni punkt jest bardzo cenny.
Noufal Ibrahim
Dzięki! Czy znasz podobne repozytorium artefaktów dla projektów w C ++? Jeszcze lepiej - może taki, który integruje się z TFS?
Ofek Shilon
2
@OfekShilon: Nexus może teoretycznie przechowywać każdy rodzaj artefaktu. Ale do przechowywania i zarządzania zależnościami .NET / C ++ masz także NuGet: nuget.codeplex.com . Przykład Net: lostechies.com/derekgreer/2011/09/20/... . Powinien także obsługiwać projekty C ++: nuget.codeplex.com/discussions/280649 .
VonC
@OfekShilon Możesz połączyć TFS z NuGet (na przykład: coolthingoftheday.blogspot.com/2011/08/… , hanselman.com/blog/… ). Zobacz także TFSNuGetter: nugetter.codeplex.com
VonC
6

Nie mam nic przeciwko kontrolowaniu wersji zasobów binarnych. Jestem przeciwny kontroli wersji generowanych plików.

Ponadto konfiguracja środowiska różni się od programowania. Tworzymy głównie w Pythonie i ma narzędzie o nazwie virtualenv, które pozwala stworzyć lekkie, izolowane środowisko (w tym biblioteki) dla projektu. Kiedy sprawdzamy nasze źródła, mamy skrypt instalacyjny, który buduje ten virtualenv. Za pomocą manifestu określa, które wersje bibliotek są potrzebne i inne tego typu rzeczy. Żadna z tych opcji nie jest kontrolowana pod kątem wersji. Jest tylko skrypt instalacyjny.

Przerzucenie całego frameworka w ramach głównego projektu zaśmieci twoją historię i poważnie zepsuje wszystko. To nie jest część twojego projektu i powinno być traktowane inaczej.

Noufal Ibrahim
źródło
3

Zasadniczo dobrym pomysłem jest zarządzanie konfiguracją przy użyciu wersji ramowych. Jeśli Twój kod potrzebuje konkretnej wersji DirectX, ta wersja powinna być łatwo dostępna, a jeśli wypróbujesz starszą wersję oprogramowania, łatwo będzie ustalić, jakie ma ona zależności zewnętrzne.

To, co nie wydaje mi się dobrym pomysłem, to użycie typowego systemu kontroli wersji do przechowywania tych plików binarnych. W naszej firmie przechowujemy każdą wersję ram, bibliotek i narzędzi zewnętrznych w strukturze podfolderów na dysku sieciowym. Tam, gdzie uważamy, że ma to sens, mamy pliki readme dokumentujące, która wersja narzędzia należy do której wersji oprogramowania lub, jeśli to możliwe, mamy skrypty do instalowania lub używania konkretnej wersji. Tylko te pliki i skrypty readme podlegają kontroli wersji.

Przechowujemy również starsze wersje narzędzi i bibliotek, o ile uważamy, że istnieje szansa na przebudowę i starszą wersję w zależności od tych narzędzi. W ten sposób daje nam możliwość usunięcia niektórych bardzo starych bibliotek i narzędzi z naszego dysku sieciowego, gdy są one przestarzałe (oczywiście na wypadek, gdybyśmy mieli archiwa na zewnętrznych nośnikach).

Doktor Brown
źródło
2

Myślę, że pliki binarne powinny gdzieś być sklepami. Sugerowałbym przechowywanie ich poza repozytorium, szczególnie jeśli są duże i prowadzą do dużych czasów wymeldowania. Nie zobaczę, że to słaba praktyka, ale też tego nie widziałem.

To może być dobry pomysł, jeśli Twoja organizacja ma wiele projektów ukierunkowanych na różne wersje środowiska wykonawczego. Zapewnia to, że masz odpowiedni plik binarny środowiska wykonawczego, gdy pracujesz nad odpowiednimi projektami.


źródło
Wyjaśniłem pytanie, aby rozwiązać ten problem.
Ofek Shilon
1

Osobiście uważam to za bardzo złą praktykę. Wolę założyć wiki z instrukcjami instalacji i wgrać do niej niezbędne pliki binarne. Te pliki są potrzebne tylko nowym deweloperom, nie ma potrzeby nadmuchiwania repozytoriów wszystkich innych.

Sergio Tulentsev
źródło
1

Istnieje dobry powód, aby to zrobić, mianowicie, że masz wszystko, czego potrzebujesz w jednym miejscu, bez żadnych zewnętrznych zależności.

Jest to o wiele ważniejsze niż myślisz. Zasadniczo zapewnia, że ​​nie będziesz polegać na artefakcie na serwerze dostawcy, który może zniknąć po kilku latach, ponieważ masz wszystko na miejscu.

Jeśli chodzi o wzdęcia repozytorium. Jest to problem tylko wtedy, gdy Twój VCS zachowuje pełną kopię lokalną (git robi to, cvs nie), ponieważ klonowanie i / lub aktualizacja będzie powolna. W zamian będziesz mieć kopie na każdym komputerze programistycznym, co może uratować Twoją firmę, jeśli pewnego dnia centralny system tworzenia kopii zapasowych zawiedzie.

Jest to kwestia priorytetu lub polityki. Tak długo, jak decyzja jest celowa, nie mam nic przeciwko temu.


źródło
2
Jeśli przechowujesz bibliotekę strony trzeciej w repozytorium artefaktów, takim jak własny serwer Nexus lub NuGet, nie będziesz musiał obawiać się, że serwer „dostawcy” zniknie. Więc zdecydowanie przechowuj je lokalnie. Po prostu nie używaj VCS. Nie są przeznaczone do przechowywania tego rodzaju plików.
VonC
@VonC zależy od infrastruktury i metodologii pracy. Aby „po prostu zapisać jeden plik binarny raz”, VCS może być tak samo dobry jak pełne repozytorium artefaktów. Utrzymuje również infrastrukturę prostą. Nie jestem zwolennikiem - OP zapytał, czy ktoś widział taki wzorzec użytkowania.
Ok. Widziałem taki wzorzec użytkowania. Musiałem administrować takimi repozytoriami (głównie scentralizować VCS jak SVN lub ClearCase, nigdy nie widziałem takiego użycia w DVCS jak Git). I to jest na ogół bałagan. Podczas ładowania bibliotek dostawców rzadko przechowuje się tylko jeden plik binarny. Musisz radzić sobie z łatkami. Wiele z nich. Plus pamięci masowej nie jest jedynym celem (gdyby tak było, VCS może być potencjalnym rozwiązaniem). Zarządzanie zależnościami to. I to, co oferują Nexus lub NuGet (oprócz łatwego w administrowaniu i czyszczenia) magazynu.
VonC