MCET-SEC 4: Build server

Świetnie, świetnie! Zdecydowałem się przyjrzeć Dockerowi podczas tworzenia mojego wydajnego zestawu narzędzi dla firm korzystających z Windowsa. Docker to pierwsze co usłyszałem jako odzew od moich programistów w CODEFUSION. Zapytali mnie – „Czy będziemy korzystać z kontenerów?”. „Po co?” odpowiedziałem. Nie dlatego, że byłem uprzedzony, po prostu uważam, że są inne sposoby, z których moglibyśmy skorzystać. Nie mam żadnego doświadczenia z kontenerami. Od zawsze korzystam z Windowsa. Wiem, że Microsoft bardzo promuje Dockera ale myślałem, że nie mam czasu, aby zaglębiać się w nową technologię. Wtedy zacząłem ustawiać wszystko na Windowsie. Postawienie repozytoriów z funkcją pull request, które bazowały na Gogu to była bułka z masłem. Za to stawianie TesLinka wręcz przeciwnie. Następnie przyszedł czas na aktualizacje servera do buildów. To powinno być łatwe zadanie. Od kiedy napisałem ”Continous Integration in .NET” w 2011 staram się być na bieżąco z wszystkimi nowinkami o ciągłej integracji. Wczoraj jednak rozmawiałem o MCET-SEC z przyjacielem, którego opinia wiele dla mnie znaczy i opowiedział mi jakie rozwiązania są stosowane w jego firmie – Docker i Kubernetes. Pomyślałem: w porządku pora na naukę. Pluralsight strzeż się. Nadchodzę żeby nauczyć się Dockera i Kubernetesa.

Jednakże w między czasie moi programiści potrzebują nowy server do buildowania. Ten, którego używamy teraz jest troche przerdzewiały. Nasz C3PO(tak, nazywamy servery po sławnych robotach i wiemy, że to nie pasuje do poważnej firmy ale i tak będziemy to robić ;)) jest prawie dziesięcioletnim WindowsServer 2008 R2 VM. Został początkowo założony w vanilli tak jak to powinno być( staraliśmy się go nie zaśmiecić i nie instalować nic co nie było niezbędne do procesu buildowania, aby ochronić go przed zewnętrznymi wpływami). Niestety dziesięć lat w IT to dużo czasu. Stworzyliśmy bardzo wiele projektów przez te dziesięć lat i nasz C3PO nosi piętno tej pracy. Pora go odrestaurować.

Servery buildowe dorosły od kiedy napisałem swoją książkę. W przeszłości w większości przypadków tworzyło się dedykowane maszyny,  na których działało oprogramowanie, które robiło jedną prostą rzecz. Sprawdzało(albo było powiadamiane o fakcie) czy cokolwiek nowego nie pojawiło się w repozytorium i utrzymywało działający proces. Wyglądało to bardzo podobnie do tego co widać na obrazku poniżej.

CI_graph_by_CODEFUSION

Dzisiaj sam proces wygląda podobnie jednakże „server” przenoszony jest do chmury. Nadal mamy samodzielny server do buildów ale jak grzyby po deszczu pojawiają się serwisy korzystające z chmury. Spośród starych rozwiązań mamy:

1. Jenkins

2. TeamCity

3. Travis CI

4. Bamboo

Pojawia się także dużo rozwiązań bazujących na SaaS(subskrybcji), które polegają na udostępnianiu klientom gotowych serverów czekających na użycie. Wybitnym przykładem jest Buddy. Wspominam o nim nie tylko dlatego, że jest to produkt polski. Zasługuje na szczególną uwagę ze względu na to jak perfekcyjnym jest rozwiązaniem CI/CD. Działają natywnie w chmurze. Potrafią ustawić wszystko w kilka minut. Jeśli twoje oprogramowanie jest tak nowoczesne jak ich servery to korzystanie z Buddyego to będzie magia. Jeśli nie, no cóz, masz problem.

Co mam na myśli? Chodzi mi o to, że co jeśli oprogramowanie, które buildujesz nie jest nowoczesną aplikacją bazującą na mikroserwisach? Co jeśli budujesz i utrzymujesz aplikacje desktopową, która po części korzysta ze starych bibliotek C++ albo WPF? Co jeśli utrzymujesz serwisy WCF’owe dla swoich klientów i ciągle masz działający zestaw testujących SOAPUi . Co jeśli budujesz aplikacje mobilne? Używasz PHP i potrzebujesz statyczny analizator kodu i maszynę do deployu? W takich sytuacjach Buddy nie wystarcza. Będziesz potrzebował utrzymywać własne servery, które zadbają o ciągłą integrację. My tak działamy. Tak ja działałem.

Postawiłem najnowszy server Jenkinsa na świeżej maszynie. Użyłem ostatniego wypuszczonego instalatora Windowsa i skorzystałem z MSI. Instalacja przebiegła nawet łatwiej niż dziewięć lat temu. Skorzystałem z kilku dodatków, których potrzebowałem. Konfiguracja LDAP była troszkę specyficzna( filtr wyszukiwania użytkownika jest ={0} i nie =%s – powinni dać medal temu kto w ogóle skonfiguruje LDAP). Konfiguracja SSL’a nic się nie zmieniła, od kiedy robiłem to ostatni raz. Nadal musisz mieć jks w stylu javy i edytować plik jenkins.xml żeby dodać odpowiednie parametry do konsoli dla Jenkinsa.

Ostatnia rzecz, którą zrobiłem było zainstalowanie dysku SSD dla buildów. To była jedna z głównych próśb moich developerów – budowanie musi przebiegać SZYBKO. Oczywiście mają rację. Czas spędzony na czekaniu aż server CI odpowie jest zmarnowany. Stworzyłem więc VHD na serverze. Włożyłem SSD i odpaliłem na niM CI. Następnie skonfigurowałem główny katalog w pliku Jenkinsa config.xml w następujący sposób:

<workspaceDir>e:/jenkins/jobs/${ITEM_FULL_NAME}</workspaceDir>
<buildsDir>${ITEM_ROOTDIR}/builds</buildsDir>

Nowiutki server do CI już działa!

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *