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

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

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)

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.

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

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.

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.

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.