Obowiązki Build Script i Build Server

Potrzebuję wyjaśnień na temat obowiązków skryptu kompilacji i serwera kompilacji.

Czytałem kilka artykułów w sieci o ciągłej integracji i kompilacjach. Włącznie z

Rozmawiałem z moim doradcą na temat procesu kompilacji naszego oprogramowania. Ponieważ jest bardzo doświadczony, ufam jego oświadczeniom, ale byłem zdezorientowany.

Jak rozumiem, z moich badań (i proszę o poprawienie mnie tutaj, ponieważ o to pytam) ideał powinien wyglądać następująco:

każdy projekt ma swój skrypt kompilacji
ten skrypt buduje projekt
ten skrypt upewnia się, że zależności zostały zbudowane wcześniej

Ponieważ zależności mogą być innym projektem, z własnym skryptem kompilacji narasta hierarchia drzewiasta. Może istnieć skrypt najwyższej kompilacji, który buduje wszystkie projekty i aplikacje.

Jednak obowiązkami Build Server są:

sprawdź repozytorium
uruchom kompilację
testy wyzwalające i inne narzędzia zapewniania jakości
udostępnić artefakt

Może to zostać uruchomione ręcznie, co noc lub po każdej zmianie repozytorium

Cele mojego doradcy są, tak jak je rozumiem, że jeden skrypt kompilacji jest sposobem na nieelastyczny i niemożliwy do utrzymania (poza tym, że utworzenie go dla naszej starszej bazy kodu zajęłoby bardzo dużo czasu). Ponadto serwer kompilacji powinien utrzymywać zależności, na przykład aby używać starszych zależności podczas tworzenia nowych awarii. Szczególnie, Antponieważ był to konkretny temat, nie jest w stanie zbudować różnego rodzaju technologii, które są używane w bazie kodu, i nie jest w stanie utrzymać zależności.

Czy możesz opracować cele i wyjaśnić obowiązki?

version-control continuous-integration builds

— Angelo.Hannes
źródło

O ile jest to dobre pytanie, na które odpowiemy (odpowiem później, kiedy będę miał czas i jeszcze nie otrzymałem odpowiedzi): naprawdę powinieneś wrócić i uzyskać wyjaśnienie od swojego doradcy. Pomieszanie po rozmowie z kimś, kto oceni twoje wyniki, jest przepisem na katastrofę i wskazuje na to, że nie komunikują się one odpowiednio z tobą (lub nie aktywnie słuchasz, ale nie wydaje się, żeby tak było tutaj).

— Steven Evers,

@ Angelo.Hannes Myślę, że osiągnąłeś wszystkie najważniejsze punkty. Czy możesz wyjaśnić bardziej szczegółowo, co Cię dezorientuje?

— M. Dudley,

@ SteveEvers Cóż, podobnie jak kilka wstępów do tego tematu, chciałem najpierw poszerzyć swoją wiedzę na ten temat. Z pewnością podejmę ten temat ponownie. Dlatego naprawdę doceniłbym twoją odpowiedź.

— Angelo.Hannes

@ M.Dudley Jak powiedziałem, nie jestem pewien, które obowiązki idą gdzie. I czy skrypt kompilacji dla całego oprogramowania jest właściwą drogą.

— Angelo.Hannes

Te rzeczy są ortogonalne:

Skryptu build jest mechanizm, który po wywołaniu na świeżo sprawdzonej-out drzewie źródłowym, daje kompletną budowę wymaganych celów i zależnościami. Może to być po prostu „zrób wszystko”, jeśli masz plik makefile lub odpowiednie wywołanie MSBuild, Ant, Maven lub Scons. Jeśli masz złożoną hierarchię zależności lub powiązanych projektów, „skrypt kompilacji” może być plikiem najwyższego poziomu, który wywołuje kolejno każdy z nich, sprawdzając sukces w miarę postępów.

Skrypt kompilacji jest tylko jednym z wielu możliwych skryptów - kasa, kompilacja, testowanie, pakiet - ale możesz mieć wszechstronny mechanizm kontrolowany przez parametry wiersza poleceń - zależy to od twojego środowiska.

Kompilacja serwera , czy raczej serwer ciągłej integracji , jest mechanizm automatyzacji odpowiedzialny za planowanie / wyzwalania, monitorowania i raportowania w kasie -> Build -> test -> Pakiet -> etap -> rurociąg wdrożenia. Możesz użyć cron / Task Scheduler, jeśli nie masz nic bardziej zaawansowanego, ale istnieje wiele doskonałych narzędzi, takich jak Jenkins, Cruise Control, TeamCity itp.

Ważne jest, aby można było wywołać kompilację bez użycia serwera CI, w przypadku, gdy jest on zajęty / offline / nieosiągalny / w inny sposób niedostępny, dlatego logika, aby uzyskać kompilację / test / cokolwiek zrobione, musi znajdować się poza System CI, ale jest przez niego wywoływany, parametryzowany według gałęzi / typu kompilacji / wersji / architektury itp.

— JBRWilkinson
źródło