Jaki jest sens „serwera budowania”? [Zamknięte]

Nie pracowałem dla bardzo dużych organizacji i nigdy nie pracowałem dla firmy, która miała „serwer kompilacji”.

Jaki jest ich cel? Dlaczego programiści nie budują projektu na swoich lokalnych maszynach, czy też nie? Czy niektóre projekty są tak duże, że do zbudowania ich w rozsądnym czasie potrzebne są mocniejsze maszyny?

Jedynym miejscem, w którym widzę przydatny serwer kompilacji, jest ciągła integracja z serwerem kompilacji, które stale buduje to, co jest przypisane do repozytorium. Czy po prostu nie pracowałem nad wystarczająco dużymi projektami?

Niech ktoś mnie oświeci: jaki jest cel serwera kompilacji?

Podany powód jest w rzeczywistości ogromną korzyścią. Kompilacje, które trafiają do kontroli jakości, powinny zawsze pochodzić tylko z systemu, który kompiluje się wyłącznie z repozytorium. W ten sposób pakiety kompilacji są odtwarzalne i identyfikowalne. Deweloperzy ręcznie budują kod dla czegokolwiek poza własnymi testami, co jest niebezpieczne. Zbyt duże ryzyko, że rzeczy nie zostaną sprawdzone, będą nieaktualne w związku ze zmianami innych osób itp.

Joel Spolsky w tej sprawie.

Budowanie serwerów jest ważne z kilku powodów.

• Izolują środowisko Lokalny programista Code Monkey mówi „Kompiluje się na moim komputerze”, gdy nie będzie się kompilował na Twoim. Może to oznaczać niezsynchronizowane zameldowania lub może oznaczać brak biblioteki zależnej. Jar hell nie jest tak zły jak .dll hell; tak czy inaczej, korzystanie z serwera kompilacji jest tanim zabezpieczeniem, że twoje kompilacje nie zawiodą w tajemniczy sposób lub przez pomyłkę nie zapakują niewłaściwych bibliotek.

• Skupiają zadania związane z kompilacjami. Obejmuje to aktualizację tagu kompilacji, tworzenie pakietów dystrybucyjnych, uruchamianie testów automatycznych, tworzenie i rozpowszechnianie raportów kompilacji. Kluczem jest automatyzacja.

• Koordynują (rozproszony) rozwój. W standardowym przypadku wielu programistów pracuje na tej samej bazie kodu. System kontroli wersji jest sercem tego rodzaju rozproszonego rozwoju, ale w zależności od narzędzia programiści mogą nie współdziałać ze sobą zbytnio ze sobą. Zamiast zmuszać programistów do ryzykowania złych kompilacji lub martwienia się o zbyt agresywne scalanie kodu, zaprojektuj proces kompilacji, w którym zautomatyzowana kompilacja może zobaczyć odpowiedni kod i przetwarza artefakty kompilacji w przewidywalny sposób. W ten sposób, gdy programista popełni problem, na przykład nie sprawdza nowej zależności pliku, może zostać szybko powiadomiony. Robiąc to w obszarze etapowym, możesz oflagować kod, który został zbudowany, aby programiści nie ściągali kodu, który mógłby zepsuć ich lokalną kompilację. PVCS zrobił to całkiem dobrze, wykorzystując ideę grup promocyjnych. Clearcase może to również zrobić przy użyciu etykiet, ale wymagałoby więcej administrowania procesem, niż wiele sklepów chce zapewnić.

Jaki jest ich cel?
Załaduj maszyny deweloperskie, zapewnij stabilne, odtwarzalne środowisko dla kompilacji.

Dlaczego programiści nie budują projektu na swoich lokalnych maszynach, czy też nie?
Ponieważ przy złożonym oprogramowaniu zdumiewająco wiele rzeczy może pójść nie tak po prostu „kompilując”. problemy, które faktycznie napotkałem:

• niekompletne sprawdzanie zależności różnego rodzaju, skutkujące brakiem aktualizacji plików binarnych.
• Po cichu publikowanie poleceń kończy się niepowodzeniem, komunikat o błędzie w dzienniku jest ignorowany.
• Kompiluj z uwzględnieniem lokalnych źródeł, które nie są jeszcze zobowiązane do kontroli źródła (na szczęście nie ma jeszcze żadnych okien z wiadomościami o „cholernych klientach”…).
• Próbując uniknąć powyższego problemu, budując z innego folderu, niektóre pliki zostały wybrane z niewłaściwego folderu.
• Folder docelowy, w którym są agregowane pliki binarne, zawiera dodatkowe przestarzałe pliki programistów, których nie należy uwzględniać w wersji

Mamy niesamowity wzrost stabilności, ponieważ wszystkie publiczne wydania zaczynają się od pobrania z kontroli źródła do pustego folderu. Wcześniej było wiele „zabawnych problemów”, które „zniknęły, kiedy Joe dał mi nową bibliotekę DLL”.

Czy niektóre projekty są tak duże, że do zbudowania ich w rozsądnym czasie potrzebne są mocniejsze maszyny?

Co to jest „rozsądne”? Jeśli uruchomię kompilację wsadową na moim komputerze lokalnym, jest wielu rzeczy, których nie mogę zrobić. Zamiast płacić programistom za ukończenie kompilacji, płać działowi IT za zakup prawdziwej maszyny do kompilacji.

Czy po prostu nie pracowałem nad wystarczająco dużymi projektami?

Rozmiar jest z pewnością jednym z czynników, ale nie jedynym.

Serwer kompilacji jest odrębną koncepcją dla serwera ciągłej integracji. Serwer CI istnieje, aby budować projekty po wprowadzeniu zmian. Z kolei serwer kompilacji istnieje, aby zbudować projekt (zazwyczaj wydanie, na podstawie oznaczonej wersji) w czystym środowisku. Zapewnia to, że żadne hacki programistów, poprawki, niezatwierdzone wersje konfiguracji / artefaktów lub niezatwierdzony kod nie trafią do opublikowanego kodu.

Serwer kompilacji jest używany do budowania kodu wszystkich użytkowników, gdy jest on wpisywany. Twój kod może kompilować się lokalnie, ale najprawdopodobniej nie będziesz mieć wszystkich zmian wprowadzanych przez wszystkich przez cały czas.

Aby dodać to, co już zostało powiedziane:

Były kolega pracował w zespole Microsoft Office i powiedział mi, że pełna kompilacja czasami zajmuje 9 godzin. To byłoby do niczego, gdybyś zrobił to na TWOJEJ maszynie, prawda?

Konieczne jest posiadanie „czystego” środowiska wolnego od artefaktów poprzednich wersji (i zmian konfiguracji), aby mieć pewność, że kompilacje i testy działają i nie zależą od artefaktów. Skutecznym sposobem izolacji jest utworzenie oddzielnego serwera kompilacji.

Zgadzam się z dotychczasowymi odpowiedziami w odniesieniu do stabilności, identyfikowalności i odtwarzalności. (Wiele „lat”, prawda?). Pracując TYLKO dla dużych firm (opieka zdrowotna, finanse) z WIELOMA serwerami kompilacji, dodam, że chodzi również o bezpieczeństwo. Widziałeś kiedyś film Biuro? Jeśli niezadowolony programista zbuduje aplikację bankową na swoim lokalnym komputerze i nikt inny jej nie obejrzy ani nie przetestuje ... BUM. Superman III.

Te maszyny są używane z kilku powodów, a wszystkie starają się pomóc Ci w zapewnieniu doskonałego produktu.

Jednym z zastosowań jest symulacja typowej konfiguracji użytkownika końcowego. Produkt może działać na Twoim komputerze ze wszystkimi narzędziami programistycznymi i bibliotekami skonfigurowanymi, ale użytkownik końcowy najprawdopodobniej nie będzie miał takiej samej konfiguracji jak Ty. W związku z tym inni programiści nie będą mieli dokładnie takiej samej konfiguracji jak Ty. Jeśli masz zakodowaną na stałe ścieżkę gdzieś w swoim kodzie, prawdopodobnie będzie ona działać na twoim komputerze, ale kiedy Dev El O'per spróbuje zbudować ten sam kod, to nie zadziała.

Mogą być również używane do monitorowania, kto ostatnio zepsuł produkt, z jaką aktualizacją i gdzie produkt się cofnął. Za każdym razem, gdy nowy kod jest wpisywany, serwer kompilacji buduje go, a jeśli się nie powiedzie, jasne jest, że coś jest nie tak, a winę ponosi użytkownik, który popełnił błąd jako ostatni.

Aby uzyskać spójną jakość i usunąć kompilację z komputera, aby wykryć błędy środowiska, a wszystkie pliki, o których zapomnisz sprawdzić w kontroli źródła, również będą wyświetlane jako błędy kompilacji.

Używam go również do tworzenia instalatorów, ponieważ zajmuje to dużo czasu na pulpicie z podpisywaniem kodu itp.

Używamy go, aby wiedzieć, że pudełka produkcyjne / testowe mają zainstalowane te same biblioteki i wersje tych bibliotek, co te, które są dostępne na serwerze kompilacji.

Chodzi o zarządzanie i testowanie dla nas. Dzięki serwerowi kompilacji zawsze wiemy, że możemy zbudować naszą główną linię „główną” na podstawie kontroli wersji. Możemy jednym kliknięciem stworzyć główną instalację i opublikować ją w Internecie. Możemy uruchomić wszystkie nasze testy jednostkowe za każdym razem, gdy kod jest sprawdzany, aby upewnić się, że działa. Zbierając wszystkie te zadania w jednej maszynie, ułatwia to ich wielokrotne wykonywanie.

Masz rację, że programiści mogli budować na swoich własnych maszynach.

Ale to niektóre z rzeczy, które kupuje nam nasz serwer kompilacji, a my nie jesteśmy wyrafinowanymi twórcami kompilacji:

• Problemy z kontrolą wersji (niektóre zostały wspomniane we wcześniejszych odpowiedziach)
• Wydajność. Twórcy nie muszą się zatrzymywać, aby tworzyć kompilacje lokalnie. Mogą go uruchomić na serwerze i przejść do następnego zadania. Jeśli kompilacje są duże, to jeszcze więcej czasu maszyna programisty nie jest zajęta. Dla tych, którzy wykonują ciągłą integrację i automatyczne testy, jeszcze lepiej.
• Centralizacja. Nasza maszyna do budowania ma skrypty, które tworzą kompilację, dystrybuują ją do środowisk UAT, a nawet do etapów produkcyjnych. Trzymanie ich w jednym miejscu zmniejsza kłopot z ich synchronizacją.
• Bezpieczeństwo. Nie robimy tutaj zbyt wiele, ale jestem pewien, że administrator systemu może sprawić, że narzędzia do migracji produkcyjnej będą dostępne tylko na serwerze kompilacji przez niektóre upoważnione podmioty.

Może jestem jedyny ...

Myślę, że wszyscy się z tym zgadzają

• użyj repozytorium plików
• budować z repozytorium (w czystym środowisku)
• użyj serwera ciągłego testowania (np. tempomatu), aby sprawdzić, czy coś nie działa po „poprawkach”

Ale nikogo nie obchodzą automatycznie budowane wersje. Kiedy coś się zepsuło w automatycznej kompilacji, ale już nie jest - kogo to obchodzi? To w toku. Ktoś to naprawił.

Jeśli chcesz zrobić wersję wydania, uruchom kompilację z repozytorium. I jestem prawie pewien, że chcesz oznaczyć wersję w repozytorium w tym czasie, a nie co sześć godzin, gdy serwer działa.

Więc może „serwer budowania” to tylko myląca nazwa, a tak naprawdę jest to „ciągły serwer testowy”. W przeciwnym razie brzmi to prawie bezużytecznie.

Serwer kompilacji daje ci coś w rodzaju drugiej opinii o twoim kodzie. Gdy to zrobisz, kod jest sprawdzany. Jeśli to działa, kod ma minimalną jakość.

Ponadto należy pamiętać, że kompilacja języków niskiego poziomu zajmuje znacznie więcej czasu niż języków wysokiego poziomu. Łatwo jest pomyśleć: „No cóż, mój projekt .Net kompiluje się w kilka sekund! O co chodzi?” Jakiś czas temu musiałem majstrować przy jakimś kodzie C i zapomniałem, ile czasu zajmuje kompilacja.

Serwer kompilacji jest używany do planowania zadań kompilacji (np. Nocne kompilacje) zwykle dużych projektów znajdujących się w repozytorium, które czasami mogą zająć więcej niż kilka godzin.

Serwer kompilacji daje również podstawę do depozytu, umożliwiając przechwycenie wszystkich części niezbędnych do odtworzenia kompilacji w przypadku, gdy inni mogą mieć prawa do przejęcia na własność.