Jak zachować wydane pliki binarne pod kontrolą wersji?

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.

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.

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)

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

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.

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:

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

2. Stanowi to podstawę do dalszej automatyzacji wydania. Na przykład automatyczne generowanie dokumentów wydania itp.