Serwer buildów, po co to komu?

Ręczna robota

Jak wygląda u Ciebie proces testowania i wrzucania aplikacji na serwer? Kompilujesz. Uruchamiasz w IDE unit testy, żeby sprawdzić czy to co dodałeś niczego nie popsuło. Włączasz na chwilę aplikację żeby przeklikać czy wygląda ok. Jak trzeba wrzucić nową wersję to albo spakowanie katalogu bin i wysłanie gdzie trzeba, albo kliknięcie Publish np. w Visual Studio. Jakieś 20-30min roboty jak wszystko idzie bez problemów.

Jest to 20-30min, które poświęcasz na patrzenie na listę wszystkich testów, a potem przeklikiwanie się przez katalogi zamiast skupić się na pisaniu kodu. Jeśli wszystko było zrobione jak trzeba to jest to 20 min., które właściwie zmarnowałeś. W końcu w tym procesie obchodzą Cię tylko sytuacje kiedy coś jednak przestanie działać. Może dałoby się to jakoś zoptymalizować? A myślałeś o automatyzacji tych zadań?

A teraz wchodzę ja – automat

Tutaj z pomocą przychodzą tytułowe rozwiązania, tzw. serwery buildów. Są to aplikacje, często działające na osobnej maszynie, które pozwalają Ci zautomatyzować proces testowania i wdrażania projektu.

W tym wpisie nie będę pokazywał jak konkretnie zainstalować i skonfigurować serwer buildów. Bardziej chcę rzucić Ci kilka haseł. Powiedzieć, że takie rzeczy istnieją. I w konsekwencji zachęcić do dalszego zagłębienia się w temat.

Serwery automatyzujące powtarzalną i nie wymagającą udziału człowieka pracę są ważnym elementem Continuous Integration (polskie tłumaczenie to „ciągła integracja” ale brzmi słabo i jest dosyć rzadko używane). Continuous Integration jest podejściem, w którym zmiany w kodzie są na bieżąco włączane do głównego repozytorium. Po pierwsze dzięki temu każdy członek zespołu może pracować na aktualnym kodzie – nie ma sytuacji gdzie po tygodniu bez żadnych ruchów w repo dostajemy na twarz tonę zmian od drugiej osoby, bo przez ten czas, przed zamknięciem zadania na 100%, niczego nie wrzucała „żeby przypadkiem nie popsuć produkcyjnego kodu”. Po drugie, przynajmniej w teorii, zespół może bardzo łatwo wydać nową wersję programu ponieważ w głównym repozytorium kod jest aktualny i jednocześnie przetestowany.

Praca praca

Zazwyczaj działanie serwera ciągłej integracji wygląda tak:

• nasłuchuje on zmian w repozytorium (zazwyczaj repozytorium GITa)
• w przypadku zmian pobiera aktualny kod
• uruchamia kompilację/budowanie nowego kodu
• uruchamia testy, metryki itd.
• przygotowuje paczkę z najnowszą wersją albo wdraża najnowszą wersję na środowisko produkcyjne

W mojej aktualnej pracy serwer buildów automatycznie pobiera zmiany, kompiluje, uruchamia unit testy, uruchamia UI testy. Dodatkowo ma możliwość ręcznego wdrożenia aplikacji na testowe serwery albo utworzenia paczki, którą wysyłamy klientowi.

Jeśli chodzi o ostatni punkt, czyli automatyczne wdrażanie najnowszej wersji to jest to opcja dosyć ryzykowna i trzeba mieć naprawdę dobrze zorganizowane testy i kontrolę jakości żeby móc coś takiego włączyć.

Codzienna praca z tymi narzędziami wygląda tak, że piszesz kod, uruchamiasz niektóre testy, które uważasz, że mogą pokazać ewidentne błędy, commitujesz zmiany i w oczekiwaniu na rezultat automatycznego builda i testów możesz zająć się kolejnym zdaniem. Po jakimś czasie albo dostaniesz powiadomienie, albo wystarczy, że wejdziesz na stronę serwera i sprawdzisz czy wszystko poszło ok.

Co tutaj mamy?

Mówię tak o tych serwerach i mówię, ale jakie właściwie konkretne rozwiązania są dostępne? Z tych, które ja znam i z którymi miałem do czynienia są dwa:

Jenkins

Oparty na Javie i przez to działający zarówno na Windowsie jak i Linuxie. Z dwóch, które tu wymieniam jest tym prostszym narzędziem. Dzięki dużej ilości wtyczek, sporemu community i przyjaznemu interfejsowi można go bez problemu skonfigurować nie mając wcześniej styczności z takimi rozwiązaniami.

Dodatkowym atutem Jenkinsa jest to, że jest open source i jest darmowy również do użytku komercyjnego.

Przykładowy zrzut ekranu z widoczną listą zadań uruchamianych w Jenkinsie

TeamCity

TeamCity jest produktem firmy JetBrains. Jest to rozwiązanie płatne jednak posiada również darmową wersję, która ma ograniczoną ilość agentów czy możliwych do dodania etapów (buildów). Tak samo jak Jenkins może działać na wielu różnych systemach operacyjnych. TeamCity jest bardziej rozbudowane i posiada więcej funkcji jednak jednocześnie próg wejścia jest większy niż w przypadku tego pierwszego. TeamCity jest dosyć często wybierane przez większe firmy.

Przykładowy widok listy buildów w TeamCity

Na koniec

Na rynku jest dostępnych oczywiście więcej rozwiązań poza dwoma pokazanymi powyżej. Uznałem jednak, że nie będę podawał przykładów, których nie znam.

We wpisie starałem się w kilku słowach powiedzieć co to są za narzędzia te serwery buildów (zwane też serwerami continuous integration, w skrócie serwerami CI).  Polecam zainteresować się tematem. Zwłaszcza jeśli planujesz pracować jako ktoś więcej niż klepacz kodu ;) Są to rozwiązania raczej przeznaczone do grupowych czy firmowych projektów ale nic nie stoi na przeszkodzie żeby nie spróbować uruchomić takich automatów dla domowego projektu.