Jak zachować wydane pliki binarne pod kontrolą wersji?

14

Jak zachować wydane pliki binarne pod kontrolą wersji? Pozwala to śledzić, które elementy są zmieniane między poszczególnymi wydaniami. Mam na myśli oddzielenie wydanych plików binarnych od repozytorium źródłowego. Wydane pliki binarne są zbudowane z oprogramowania Continuous Integration lub skompilowane ręcznie.

version-control release-management

— linquize
źródło

Co rozumiesz przez „śledzenie, które rzeczy się zmieniły”? Jakie atrybuty plików binarnych wersji śledzisz (lub chcesz być) śledzony? To po prostu dziwne, więc jestem ciekawa.

— Jeremy Heiler

np. między wersją 1.0.0 a wersją 1.0.1, zmienia się tylko ABC.exe, a zależność DEF.dll pozostaje niezmieniona

— linquize

1

Jak to ustalić, patrząc na pliki binarne?

— Jeremy Heiler,

diff stara i nowa wersja tego samego pliku

— linquize

21

Dwie opcje:

a) Nie. Upewnij się tylko, że masz odtwarzalne deterministyczne kompilacje, to znaczy, że zbudowanie tej samej wersji kontroli źródła przy tej samej konfiguracji zawsze daje dokładnie ten sam plik binarny.

b) Wyznacz gdzieś katalog jako wiarygodne źródło opublikowanych kompilacji. Włącz przesyłanie plików binarnych do procedury wdrażania / wysyłki i upewnij się, że katalog opublikowanych kompilacji jest objęty Twoim planem tworzenia kopii zapasowych. Nie potrzebujesz tutaj żadnej kontroli wersji; kompilacje są zapisywane raz, jeśli chcesz coś zmienić, tworzysz nową kompilację.

Tak czy inaczej, pliki binarne i inne dane wyjściowe kompilacji nie podlegają kontroli źródła z wielu powodów.

— tdammers
źródło

7

a) często nie jest możliwe oczywiście blogs.msdn.com/b/ericlippert/archive/2012/05/31/...

— jk.

@jk: nice link. Wydaje mi się, że posiadanie kodu źródłowego i wszystkich plików wejściowych na etapie kompilacji pod pełną kontrolą źródła (i posiadanie zainstalowanej właściwej wersji kompilatora) może być „wystarczająco deterministyczne” w wielu rzeczywistych scenariuszach (a niewystarczająco w innych, oczywiście ). To, jak ważne jest, aby odtwarzać pliki binarne krok po kroku, zależy od wielkości liter.

— Doc Brown

10

Użyj repozytorium artefaktów dla plików binarnych, a nie systemu kontroli wersji. Określona wersja wydanego pliku binarnego nie powinna się zmieniać w czasie, dlatego kontrola wersji nie ma sensu, ponieważ pliki nie uległyby zmianie.

Zobacz na przykład repozytoria Maven jako repozytorium do archiwizowania / publikowania / oferowania wydań i innych plików binarnych (np. Takich jak dokumentacja)

— mhaller
źródło

konkretna wersja wydanego pliku źródłowego również nie powinna się zmieniać w czasie. SCM jest dobrym miejscem do umieszczenia dostarczonego pliku binarnego, wystarczy przechowywać go obok plików źródłowych użytych do jego zbudowania.

— gbjbaanb

2

gbjbaanb, SCM oznacza „Source Control Management”. To powinno dać każdemu podpowiedź, że systemy te nie są przeznaczone do przechowywania plików binarnych, ale źródła. Jeśli nadal chcesz przechowywać pliki binarne, śmiało. Nie będę

— mhaller

4

SCM to skrót od „Software Control Management”, ale niezła próba. „kod źródłowy” to często nie tylko pliki tekstowe, ale obrazy, dokumenty, diagramy itp.

— gbjbaanb

Zwykle „Zarządzanie konfiguracją oprogramowania”. Nigdy nie słyszałem o „zarządzaniu kontrolą oprogramowania”.

— James McLeod,

7

Po prostu włóż je. Nie ma z tym problemu, chyba że używasz git (który nie łączy dobrze plików binarnych, więc musisz sam nimi zarządzać) lub popełniasz je zbyt wiele razy (zatwierdzaj tylko wtedy, gdy jest to gotowy do wysyłki, nie za każdym razem, gdy go zbudujesz).

Większość plików binarnych delta SCM całkiem dobrze, umieściliśmy dll zasobów 2Mb w naszym SVN i za każdym razem zmniejszałoby to do kilku KB.

Słyszę wiele argumentów, że SCM są źródłowe, a nie binarne, ale jest to po prostu nieprawda, jeśli weźmie się pod uwagę, że większość oprogramowania składa się z obrazów, nawet jeśli są to tylko pliki ikon. Są to pliki binarne, ale są częścią źródła, więc włóż je i nie bądź taki dogmatyczny. Słyszę również, że możesz po prostu odbudować plik binarny, gdy jest to potrzebne, często tak jest, ale może to być ogromny wysiłek marnujący czas w przypadku starszych systemów, które nie są już aktywnie obsługiwane. Jeśli musisz ponownie utworzyć system ze starszymi dodatkami Service Pack lub łatkami, aby odpowiadał systemowi, który został użyty do zbudowania pliku binarnego 3 lata temu, będziesz zadowolony, że dodałeś bin do SCM.

Jedynym czasem, kiedy musisz się martwić dodaniem kompilacji do SCM, jest to, że robisz to automatycznie w ramach procesu serwera kompilacji - nie rób tego. Wypełnisz swój SCM kompilacjami, które nie przyniosą ci żadnych korzyści. Zamiast tego dodawaj je tylko po wydaniu. W ten sposób wiesz dokładnie, co ma klient i możesz odtworzyć wszelkie zgłoszone przez klienta problemy z plikami binarnymi, których używają, a nie tymi, które przebudowałeś (używając, powiedzmy, najnowszych aktualizacji kompilatora lub systemu operacyjnego).

— gbjbaanb
źródło

1

@ MarnenLaibow-Koser najwyraźniej od dawna nie pracujesz w branży. Środowiska kompilacji zmieniają się z czasem, więc chociaż możesz przebudować stare, istnieje szansa, że będziesz musiał spędzić dni na ponownym tworzeniu env przy użyciu odpowiednich starych narzędzi i zestawów SDK. Które mam nadzieję, że masz

— wersję

1

Wyobrażam sobie, że byłbyś w stanie zbudować stary plik binarny VC6, który został skompilowany na komputerze XP przy użyciu starego zestawu SDK, którego firma Microsoft nie uważa za odpowiedni do wydania. Jeśli ktoś poprosi o ten plik binarny, łatwo go po prostu pobrać z tego samego miejsca, gdzie jest przechowywana cała reszta. Koszt zarządzania, który jest ogromny w porównaniu z bólem związanym z koniecznością odbudowy, a koszt przechowywania go ze źródłem jest niewielki. Byłem tam (z aplikacją VB6 wykonaną za pomocą zewnętrznego kontrolera, gdy klient zgłosił błąd - uzyskanie pliku binarnego i uruchomienie go było o wiele łatwiejsze niż przebudowanie, co okazało się niemożliwe)

— gbjbaanb

1

@ gjbaanb Przyznaję również, że znajdujesz się w innej sytuacji ode mnie w inny sposób: wszystkie moje zewnętrzne zależności to OSS, więc nie mogą odejść tylko dlatego, że niektóre firmy nie uznają już za stosowne ich uwolnienie.

— Marnen Laibow-Koser

1

Chodzi mi o to, że SCM można zapisać wszystko, więc nie ma potrzeby, aby nie przechowywać binarny oddzielnie od jego źródła. Jest wygodny i łatwy i gwarantuje, że wiesz, co będzie później. Nie ma to jednak wady. Każde wydanie jest zsynchronizowane tylko z jednym konkretnym zatwierdzeniem źródłowym. Nie widzę problemu, z wyjątkiem tego, że niektórzy uważają, że SCM oznacza tylko tekst kodu źródłowego. Nie, używaj go do przechowywania prawie wszystkiego (czasem włączając narzędzia do budowania lub biblioteki, jeśli nie są ogromne), życie staje się znacznie łatwiejsze.

— gbjbaanb

1

@gjbaanb Chodzi mi o to, że się mylisz. :) Jasne, VCS mogą przechowywać wszystko, ale nie są dobrze skonfigurowane do przechowywania plików, które żyją tylko dla jednego zatwierdzenia (w końcu nie chcesz, aby twoja r500 była wbudowana w repo w r550; będzie to po prostu mylące) . Podstawowym problemem związanym z przechowywaniem artefaktów kompilacji w repozytorium nie jest to, że są one binarne , ale że pochodzą z danych i nie będą synchronizowane ze swoim źródłem w tym samym repozytorium. Te same argumenty, których używam, dotyczyłyby wygenerowanych plików tekstowych.

— Marnen Laibow-Koser

5

Nie trzymam plików binarnych wersji pod kontrolą wersji. Zamiast tego publikuję je w dobrze określonej lokalizacji, aby inne narzędzia mogły je sprawdzić i wykorzystać. Dużo pracuję w Javie, więc oznacza to, że publikuję Jarsa w lokalnych repozytoriach Maven. Jednak nie używam tych narzędzi do śledzenia zmian w poszczególnych wydaniach. W końcu są to pliki binarne i nie ma tak naprawdę wiele do śledzenia poza liczbą plików.

Aby śledzić zmiany między wydaniami, oznaczyłem lub oznaczyłem wydania w moim systemie kontroli wersji numerem wersji. Ale tak naprawdę służy to wyłącznie do śledzenia plików źródłowych, a nie plików binarnych. Pliki binarne są artefaktami kompilacji i nie muszą być pod kontrolą wersji.

— Jeremy Heiler
źródło

1

Najlepszym rozwiązaniem jest wyłączne korzystanie z systemu CI w przypadku wszystkich kompilacji istotnych z punktu widzenia organizacji (wydania, wersje kandydackie itp.).

To systematycznie wiąże wydane pliki binarne z zawartością repozytorium bez konieczności faktycznego przechowywania plików binarnych w repozytorium.

Na przykład, jeśli używasz SVN, użyj schematu organizacyjnego dla głównych gałęzi; rób codzienne prace rozwojowe w / trunk i utwórz tag / dla każdej wersji, gdy będzie gotowa.

Skonfiguruj system CI, aby budował z tagów, a także z pnia, i poproś, aby zapisał dane wyjściowe w katalogu sieci, którego struktura odzwierciedla strukturę najwyższego poziomu repozytorium:

/ builds / trunk / [rev] [date] [build_id] /
/ builds / tags / release_0_1_3beta4 / [rev] [date] [build_id] /

System kompilacji będzie musiał traktować katalog / builds / trunk / jak bufor cykliczny, przechowując ostatnie n kompilacji, usuwając stare kompilacje.

Z kolei katalog / builds / tags / jest sklepem stałym. Same artefakty kompilacji są przechowywane w katalogach z nazwami wygenerowanymi zgodnie z następującym schematem:

[rev] [data] [build_id]

gdzie [rev] jest identyfikatorem wersji SVN, [data] jest datą w formacie RRRRMMDD, a [id_budowy] jest trzycyfrowym unikalnym licznikiem, rosnącym od pierwszego kompilacji, czyniąc każdy katalog kompilacji niepowtarzalnym.

Proces opisany powyżej zapewnia następujące korzyści:

Artefakty budowania są systematycznie powiązane ze źródłem, które je wygenerowało, dzięki czemu można bardzo łatwo znaleźć źródło dla konkretnego artefaktu budowania (i odwrotnie).
Stanowi to podstawę do dalszej automatyzacji wydania. Na przykład automatyczne generowanie dokumentów wydania itp.

— William Payne
źródło