Argumenty ponownie rejestrują pliki binarne podczas sprawdzania w SCM

Pracuję dla firmy, która głównie tworzy aplikacje Java i staram się przekonać wszystkich, aby przestali rejestrować pliki binarne (zależności i produkty końcowe) w SCM.

Wiedzą, że to zła praktyka, ale myślą, że „to działa” i nie jest to tak naprawdę problemem, nawet jeśli wiele osób wie o Maven i innych narzędziach do budowania oprócz Anta. Zarówno premierzy, jak i programiści (około 50 osób) są gotowi wysłuchać wszelkich argumentów przeciwko, a nawet przyznają, że jest to marnowanie miejsca na kopie zapasowe, ale chcę być naprawdę przekonujący, ponieważ zmiana nawyków wymagałaby dużego wysiłku. Jakich argumentów używasz do poparcia zmiany?

Edycja: W porządku, warto rozróżnić pliki, które prawie się nie zmieniają, takie jak zależności, i pliki generowane. Mimo to interesują mnie powody tego drugiego.

Przestrzeń dyskowa jest tania, więc nie jest to zbyt przekonujący argument za tym, dlaczego powinieneś lub nie powinieneś sprawdzać plików.

Zamiast tego możesz odwołać się do celu SCM. Każdy plik śledzony przez SCM reprezentuje pewną potrzebę zarządzania równoległymi, rozproszonymi zmianami, które wprowadza Twój zespół. Nic z tego nie jest widoczne, dopóki dwóch członków zespołu nie spróbuje zmienić tego samego pliku. Rozwiązaniem tych zmian jest właśnie to, czym jest SCM, zapobieganie przypadkowemu nadpisaniu pracy innego dewelopera i, miejmy nadzieję, automatyzacja procesu scalania tych zmian.

Scalanie plików binarnych jest zwykle prawdziwym wyzwaniem, ponieważ ogólne narzędzie do scalania nie może zgadnąć, jak powinien działać scalony plik binarny. Nie może wiedzieć wystarczająco dużo o tym, jak działają indeksy lub wskaźniki przesunięcia w pliku, chyba że jest specjalnie zaprojektowany do rozpoznawania tego konkretnego typu pliku.

Oznacza to, że to deweloper musi ręcznie połączyć plik binarny, a następnie poinformować SCM, że plik został tak scalony. Ponieważ robi to deweloper, scalanie może nie obejmować wszystkich zmian obu poprzednich meldowań, a ponieważ plik jest binarny, nie ma automatycznego sposobu na sprawdzenie scalenia.

W przypadku formatów binarnych, które naprawdę reprezentują źródła projektu, takie jak zasoby sztuki, jest to niefortunny, ale konieczny krok. Jednak wyniki kompilacji nie są źródłami. Nie ma potrzeby ich łączenia, ponieważ źródła można łączyć, a wynikową kompilację można zregenerować. Śledzenie i zarządzanie tymi zmianami to 100% marnotrawstwa. Marnuje zasoby SCM, choć nie strasznie dużo, ale marnuje także czas programisty, aby ominąć fałszywe niepowodzenia scalania. Czas programisty jest bardzo drogi, a wszystko, co go marnuje, to rak.

Z drugiej strony istnieje szczególny przypadek, w którym wyniki kompilacji powinny być archiwizowane. Każda wersja projektu, która kiedykolwiek została wysłana lub wdrożona, powinna prawdopodobnie zostać zachowana na czas nieokreślony. Posiadanie dokładnej kopii bajt po bajcie rzeczywistej kompilacji, z którą ma problemy klient, może znacznie ułatwić obsługę tego klienta, ponieważ będziesz miał dokładnie taką wersję, jaką on ma.

Ta kopia zapasowa prawdopodobnie nie powinna znajdować się w tym samym repozytorium, co kod źródłowy, ponieważ będą one ogólnie przestrzegać różnych harmonogramów i będą mieć zasadniczo różne struktury.

Zależności, nawet w formie binarnej, powinny być rejestrowane, aby gdy ktoś inny zburzył projekt, po prostu działał. Głównym problemem nie jest typ pliku, ale sposób jego tworzenia. Zasadą, której używam, jest to, że jeśli można go wygenerować przy użyciu innego pliku, nie jest on rejestrowany - oznacza to automatycznie wygenerowaną dokumentację, pliki binarne, które tworzę itd.

Jedną z głównych zalet korzystania z SCM jest to, że można zrekonstruować system z dowolnej przeszłości. Dlatego nie ma sensu przechowywanie ostatecznej wersji w SCM, ponieważ możesz po prostu sprawdzić numer wersji i go zbudować.

Wspominasz o zależnościach ... Twój SCM powinien być skonfigurowany tak, abyś mógł zrobić czystą kasę na nowej maszynie (ze środowiskiem programistycznym), wciśnij build i powinieneś być w stanie zbudować swój system bez potrzeby instalowania czegokolwiek innego. Dlatego utrzymywanie zależności binarnych w SCM jest dobrym pomysłem. Biblioteki rzadko się zmieniają, więc nie zajmują dużo miejsca.

Prawie nikt tego nie robi.

Wydaje się, że nadmiarowe obejmuje zarówno pliki źródłowe, jak i obiektowe (pliki źródłowe są oczywiście wymagane). Oprócz tego, że są niepotrzebne, pliki obiektowe mogą zajmować dużo miejsca. Jeśli Twoja firma korzysta z rozproszonego SCM (Git, Hg, Bzr), te pliki binarne muszą zostać skopiowane i zapisane wśród wszystkich programistów.