Jaki jest cel dedykowanej maszyny do kompilacji?

Ze względu na szereg okoliczności prowadzących do złego wdrożenia ostatniego cyklu kompilacji, prowadziłem kampanię w naszym biurze, aby wykonać wszystkie przyszłe wdrożenia przy użyciu dedykowanej maszyny do kompilacji, a mój szef zaakceptował tę propozycję.

Jednak zamiast oddać do użytku prawdziwą maszynę w naszym biurze, musimy dzielić tę samą maszynę z kilkoma innymi grupami - i mamy problem z opuszczeniem mojego biura ze wszystkimi niezbędnymi informacjami, a następnie zejściem schodami po schodach w innym biurze tylko po to, by wykonać prostą kompilację, zastanawiam się, dlaczego w ogóle zaproponowałem to.

Pomysł posiadania oddzielnej maszyny do kompilacji polegał pierwotnie na oddzieleniu mojego kodu napisanego lokalnie od kodu kilku innych programistów i oddzieleniu wszelkich porwanych plików, które miałem na moim komputerze, od wdrożenia. Miało to również rozwiązać rosnące obawy związane z naszym systemem zarządzania plikami ClearCase, który często nie pozwala mi wdrożyć pewnych działań kompilacji, chyba że dołączę także inne działanie, od którego „zależy”.

Teraz, gdy faktycznie kontynuuję ten proces, zastanawiam się, czy źle zrozumiałem cały cel korzystania z maszyny do kompilacji - a ponieważ używamy tej maszyny tylko do wdrażania kodu w naszych środowiskach testowych, testowych i produkcyjnych oraz nie w przypadku naszych osobistych wdrożeń testowania programistów, nie jestem pewien, czy w ogóle służy to celowi.

Więc jaki jest rzeczywisty powód używania maszyny do kompilacji i czy w ogóle nie byłem w stanie prawidłowo jej używać?

Zwykle nie miałbyś tylko dedykowanej maszyny do budowania, ale także uruchamiałeś serwer kompilacji na tej maszynie. Dedykowana maszyna do budowania oferuje tę zaletę, że nigdy nie blokuje pracy programisty i nie wdraża ze scentralizowanej maszyny.

Serwer kompilacji oferuje znacznie więcej. Serwer kompilacji pozwala na CI (ciągłą integrację), co oznacza, że ​​będzie automatycznie opierał się na każdym wypychaniu do twojego VCS (jak git), może nawet przeprowadzać testy jednostkowe, jeśli je masz i pozwala na „wdrożenie jednym kliknięciem”. Serwery kompilacji mogą powiadamiać Cię pocztą, jeśli kompilacje lub testy zakończą się niepowodzeniem. Oferują dane historyczne i trendy dotyczące tego, co się stało.

Dostęp do serwerów kompilacji może ogólnie uzyskiwać dostęp wielu użytkowników lub zespołów jednocześnie, korzystając z interfejsu GUI działającego w przeglądarce.

W świecie Java jednym z najczęściej używanych serwerów kompilacji jest Jenkins. Jenkins doskonale działa również z kompilacjami C ++ (ponieważ wydaje się, że używasz tych dwóch języków). Jenkins nazywa się serwerem automatyzacji, ponieważ może wykonywać wszelkiego rodzaju zadania, które nie muszą być związane z programowaniem i budowaniem.

Oprócz odpowiedzi Traubenfuchsa podałeś w innym pytaniu o przyczynie maszyny do kompilacji.

Tylko dlatego, że oprogramowanie opiera się na twoim komputerze, nie oznacza to, że będzie opierać się na cudzym. Być może korzystasz z losowych plików, które akurat znajdują się na twoim komputerze (i mogą nawet nie być pod kontrolą wersji). Być może polegasz na jakiejś zapomnianej aplikacji lub bibliotece, która jest wywoływana z niejasnego skryptu kompilacji.

Jeśli masz dedykowaną maszynę do kompilacji, powinieneś wiedzieć, co jest na niej zainstalowane. Powinno to być dobrze udokumentowane. Jeśli kiedykolwiek zajdzie potrzeba przebudowania oprogramowania, być może lata później, wystarczy stworzyć nową maszynę do kompilacji z zainstalowanymi na niej udokumentowanymi materiałami.

Głównym powodem posiadania dedykowanej maszyny kompilacji jest uzyskanie spójnych kompilacji niezależnie od tego, kto ją wykonuje. Stacje robocze programistów rzadko są identyczne (czytaj: nigdy). Trudno wiedzieć, że każda kompilacja korzysta z tych samych dokładnych wersji zależności i kompilatorów itp. Jednym z najgorszych problemów z kompilacjami stacji roboczych jest to, że programiści mogą budować z kodu, który nie jest sprawdzany w kontroli wersji.

Nie jest jasne, jakiej platformy / języka używasz, ale najlepiej mieć serwer kompilacji, który pobiera bezpośrednio z kontroli źródła. Oznacza to, że gdy wymagana jest kompilacja, pobierze źródło z danej wersji repozytorium i automatycznie go skompiluje. Wymaga to użycia automatycznych narzędzi kompilacji do skryptu kompilacji. Jeśli tego nie masz, powinien to być krok nr 1.

Pamiętaj, że nie ma nic złego w budowaniu lokalnie na potrzeby rozwoju. Zdecydowanie powinieneś pracować na lokalnych testach jednostkowych, analizie jakości kodu i doskonaleniu skryptów kompilacji. W przeciwnym razie zmarnujesz dużo czasu. Dane wyjściowe serwera kompilacji dotyczą wszystkiego, co chcesz potencjalnie przenieść do produkcji. Wszystkie działania związane z kontrolą jakości, takie jak testy integracji i akceptacji, powinny być wykonywane tylko z kompilacjami z serwera kompilacji.

W innych odpowiedziach dość poprawnie zaznaczono, że należy zautomatyzować kompilację, co oznacza, że ​​nie trzeba chodzić do innego biura. Pozwól mi jednak zaproponować pewną liczbę kroków, które możesz podjąć, aby usprawnić proces kompilacji:

• Po pierwsze, skonfiguruj zdalny dostęp do serwera kompilacji! Jeśli budujesz ręcznie, wpisując polecenie „make”, oznacza to, że nie musisz już iść do innego biura, aby wpisać „make”, możesz po prostu SSH na serwerze kompilacji i wpisać „make”. Jeśli jeszcze nie używasz make lub podobnego systemu kompilacji, weź taki system kompilacji do użycia.
• Po drugie, zainstaluj środowisko ciągłej integracji, które automatycznie pobiera najnowsze zmiany z systemu kontroli wersji (masz system kontroli wersji, prawda? Jeśli nie, to byłby dodatkowy krok) i buduje je. Polecam Jenkins. Skonfiguruj Jenkins, aby uruchamiał również testy jednostkowe i testy integracyjne na poziomie systemu (masz oba, prawda? Jeśli nie, utwórz je, zaczynając od testów jednostkowych, a kończąc na testach integracyjnych na poziomie systemu).
• Po trzecie, jeśli problematyczne jest współdzielenie tego samego komputera z innymi zespołami (na przykład jeśli masz różne opinie na temat systemu operacyjnego, wersji i goryczy, których powinieneś użyć), rozważ zastosowanie wirtualizacji. Dobry serwer może dziś obsługiwać ogromną liczbę maszyn wirtualnych. Być może możesz skonfigurować maszynę 32-bitową i maszynę 64-bitową, aby wiedzieć, że kompilacja działa na obu architekturach.
• Wreszcie może to nie być konieczne: jeśli absolutnie musisz mieć dedykowany komputer, na przykład jeśli wydajność aplikacji ma ogromne znaczenie, a inne kompilacje / testy uruchomione w tym samym czasie mają zbyt duży wpływ na wyniki, zainstaluj dedykowany serwer sprzętowy niż tylko ty używasz. Jednak na najnowszych serwerach, które mogą mieć nawet 40 rdzeni procesorów wirtualnych lub więcej, stosunkowo proste jest utworzenie kilku maszyn wirtualnych, które nie mają dostępu do tych samych rdzeni procesorów.

Uważam, że współużytkowana maszyna jest znacznie lepsza niż kompilacje ręczne. Mój obecny projekt wykorzystuje teraz maszynę wirtualną, ale z powodu potrzeby testów wydajności integracji na poziomie systemu przechodzimy na dedykowany serwer z 40 rdzeniami wirtualnego procesora, którego testy wydajności wymagają 17.

... zamiast oddać do użytku rzeczywistą maszynę w naszym biurze, musimy udostępnić jedną maszynę kilku innym grupom ...

Mówisz, że to źle.

Masz teraz wspólny serwer kompilacji, przez który budowane są wszystkie kompilacje - twoje i innych zespołów. Spójność kompilacji? Czek.

... kłopot związany z opuszczeniem mojego biura ze wszystkimi niezbędnymi informacjami, a następnie zejściem po schodach do innego biura tylko po to, aby wykonać prostą kompilację, sprawia, że ​​zastanawiam się, dlaczego w ogóle zaproponowałem to.

Nadal wykonujesz kompilację ręcznie i to nie jest dobre.

Potrzebujesz procesu serwera, do którego wysyłasz / ustawiasz w kolejce żądania kompilacji, które mają zostać wykonane w Twoim imieniu, i aby proces ten odesłał ci wynik (y).

Oprócz innych istotnych odpowiedzi brzmi to tak, jakbyś uruchamiał swoje kompilacje bezpośrednio na danym komputerze.

W przypadku niezawodnego systemu kompilacji, szczególnie podczas udostępniania maszyny kompilacji innym użytkownikom, uruchamianie kompilacji na maszynie wirtualnej jest normalne. Dzięki temu inni użytkownicy nie będą mogli zmienić zachowania twoich kompilacji, instalując własne wersje aplikacji lub bibliotek, od których zależy Twój kod. Ogromną zaletą tego jest to, że można łatwo wykonać kopię zapasową maszyny wirtualnej, a także klonować ją na dowolnym komputerze (w tym na własnej maszynie programistycznej).

Zapewnia scentralizowaną, neutralną lokalizację do wykonywania kompilacji, niezależnie od konfiguracji IDE, systemu operacyjnego i bibliotek poszczególnych programistów.

Dzięki dedykowanej maszynie do kompilacji możesz ją przebudować za każdym razem, gdy wypychany jest kod do repozytorium. Gdy ktoś złamie kompilację, proces może natychmiast wysłać ostrzeżenie, aby problem mógł zostać natychmiast rozwiązany.

Oprócz uczynienia wszystkiego bardziej powtarzalnym i niezawodnym oraz zapewnienia, że ​​repozytorium nie jest pełne zepsutych śmieci z czającymi się problemami zależności, ułatwia życie programistom, ponieważ wszystko, co muszą zrobić, aby kompilacja działała na ich komputerze, to kopiowanie czegokolwiek odbywa się na maszynie kompilacji.