W ostatniej dekadzie słowo „Continuous” było odmieniane przez wszystkie przypadki. Magiczne, nieokreślone coś, Święty Graal, dzięki któremu firma potroi swoje zyski, wydajność pracowników wzrośnie o 1600%, krowy będą dawać więcej mleka, a przychód z młyna zwiększy się do 5000 sztuk złota tygodniowo.
Poniższy artykuł w zwięzły sposób przedstawia, czym tak naprawdę są Continuous Integration, Delivery i Deployment, jakie przynoszą korzyści i jak w prosty sposób developer może je wdrożyć do swojego procesu.
Autorem tekstu jest Aleksander Kuś z firmy Buddy.
Buddy to wyjątkowe narzędzie CI/CD, powstałe z myślą o wygodnym rozwoju oprogramowania i bezproblemowej automatyzacji procesów.
I, co ciekawe, Buddy powstaje w Polsce!
Uwaga: ten post jest częścią inicjatywy “Tydzień z Continuous Integration na devstyle.pl“, przygotowanej wraz z firmą Buddy. TUTAJ możesz zapoznać się z wszystkimi proponowanymi treściami… a na końcu tekstu czeka na Ciebie niespodzianka!
Ale po kolei… :)
Krok 1: Continuous Integration
Podstawową zasadą Continuous Integration jest jak najczęstsze wdrażanie zmian do głównej linii kodu oraz ich natychmiastowe testowanie. Praktyka ta znacząco przyśpiesza debugowanie i ogranicza konflikty przy merdżowaniu zmian, dzięki czemu developerzy mogą szybciej dostarczać software.
Dokładne pokrycie kodu źródłowego testami to punkt wyjścia do dalszej automatyzacji. Testy jednostkowe, integracyjne, E2E, przeglądarkowe – wszystko to pozwala wyłapać i zdebugować więcej błędów przed wdrożeniem na produkcję (i znacząco ogranicza przyrost siwych włosów w czasie pracy). Zazwyczaj testy odpalane są na build serwerze po wcześniejszej instalacji infrastruktury CI i dokładnym oskryptowaniu całego procesu przez zespół DevOps-owy.
W tym miejscu dochodzimy do ściany, od której odbija się wiele polskich firm IT: kosztów.
Kosztów serwera, narzędzi, szkoleń z obsługi, wreszcie kosztów wdrożenia procesu przez specjalistów: czasu potrzebnego na zaznajomienie się z dokumentacją, pisania skryptów, testowania i późniejszego maintenance. To nie jest kwestia kilku godzin, to jest kwestia kilku tygodni, a w przypadku większych firm – miesięcy. Żaden CEO nie wyda lekką ręką parunastu tysięcy złotych na coś, co w teorii powinno poprawić jakość pracy, nie mając pewności, że rzeczywiście tak będzie.
I tu wchodzi Buddy, cały na biało:
W Buddym cały proces można samodzielnie skonfigurować w 10 minut. Bez czytania dokumentacji, bez pisania skryptów, bez zatrudniania dedykowanego developera. Był to nasz główny cel podczas projektowania aplikacji – uprościć procedury do absolutnego minimum. Zamiast skryptów oddajemy do dyspozycji użytkownika gotowe akcje (buildy, testy, deploye) opakowane w maksymalnie przyjazne UI/UX.
Tak wygląda gotowy pipeline CI:
Pierwsza akcja odpala testy po każdym pushu do repozytorium. Druga akcja wysyła powiadomienie na kanał slackowy, w przypadku kiedy testy nie przejdą. Konfiguracja jest bardzo prosta i zajmuje dosłownie kilka minut.
- Wybieramy swojego providera i podpinamy repozytorium:
- Dodajemy nowy pipeline, wybieramy branch lub wildcard, który chcemy testować, i ustawiamy trigger mode na tryb automatyczny (on push):
- Wybieramy odpowiedni język lub framework i definiujemy testy (w tym przypadku Node.js):
Po pushu do repozytorium Buddy automatycznie odpala kontener dockerowy ze zdefiniowanym środowiskiem i testuje najnowsze zmiany. Jeżeli wszystko przejdzie bez problemów, oznacza pipeline na zielono (success). Jeżeli testy się wysypią – na czerwono.
Środowisko aplikacji można łatwo przygotować, wybierając obraz dockerowy w odpowiedniej wersji, a brakujące komponenty doinstalować w zakładce Environment. Całość jest cache’owana razem z zależnościami, co znacząco przyśpiesza działanie builda.
Więcej na temat CI posłuchasz w DevTalk z Rafałem, CTO w firmie Buddy!
Po zautomatyzowaniu testów przychodzi kolej na następny etap: Continuous Delivery.
Krok 2: Continuous Delivery
Zanim zagłębimy się w szczegóły, słowo wyjaśnienia, czym różni się Continuous Delivery od Continuous Deployment (przejdziemy do niego w ostatnim kroku). Oba podejścia polegają na automatyzacji deploymentu. Dzięki temu możemy szybciej uzyskać feedback od klienta i wdrożyć potrzebne zmiany. Warunkiem release’u jest stabilność builda – dlatego właśnie tak ważne są testy. Różnica jest taka, że w Delivery release musi zostać zatwierdzony manualnie, a w Deployment odbywa się on automatycznie.
Tutaj przykładowy proces Continuous Delivery. Jak widać, deploy na produkcję wymaga ręcznego potwierdzenia:
Dla porównania: tak wygląda proces Continuous Deployment. Pełna automatyzacja!
Wróćmy jednak do Continuous Delivery. Poniżej zobaczysz pipeline w Buddym, który pokrywa cały proces wdrażania aplikacji na LIVE. Testy odbywają się automatycznie, ale już sam deploy musi zostać potwierdzony manualnie akcją Wait for approval:
Release aplikacji odbywa się za pomocą dedykowanych akcji, które uploadują pliki na SFTP i na Amazon S3. Na końcu akcja SSH uruchamia skrypty na serwerze, np. restartuje aplikację albo migruje bazy danych.
Konfiguracja kolejnych kroków jest bardzo łatwa. Przykładowo, jeśli chcemy zrobić deploy na serwer SFTP, wyszukujemy go na liście, wpisujemy dane autoryzacyjne, ścieżkę docelową na serwerze i… tyle – Buddy automatycznie zuploaduje zmiany na serwer po pushu.
Sam mechanizm deploya oparty jest na changesetach. Oznacza to, że wysyłane są tylko zmiany wprowadzone od ostatniego wdrożenia. Dzięki temu proces jest bardzo szybki, bo nie trzeba za każdym razem uploadować całego repozytorium na serwer. W przypadku dużych repozytoriów może to skrócić czas deploya z kilkudziesięciu minut do kilkunastu sekund!
Dla przykładu: cotygodniowy update naszej aplikacji na LIVE ma praktycznie zerowy downtime i jest niezauważalny dla naszych klientów. Dodatkowo, gdyby wystąpiły problemy ze stroną lub aplikacją, można szybko cofnąć zmiany do poprzedniej rewizji – Buddy automatycznie przywróci wcześniejszą wersję plików na serwerze bez potrzeby ręcznego kopiowania i usuwania.
Narzędzie wspiera deployment praktycznie do każdego stacku. Możemy deployować na serwer (FTP/SFTP/FTPS) lub na platformy cloudowe przez dedykowane integracje (AWS S3, Elastic Beanstalk, Google Cloud, Microsoft Azure, DigitalOcean i in.). Fani Dockera znajdą również pełny zestaw narzędzi do budowania i zarządzania obrazami dockerowymi – od lokalnego developmentu po orkiestrację wielu kontenerów na Kubernetesie.
Poniżej przykładowe akcje z kilkudziesięciu dostępnych integracji:
Krok 3: Continuous Deployment
Ostatnim etapem automatyzacji jest Continuous Deployment, developerska nirwana, w której każda zmiana w kodzie jest automatycznie releasowana na produkcję – oczywiście po bardzo dokładnym wcześniejszym przetestowaniu.
Google, Facebook, Netflix – wszyscy giganci branży całkowicie automatyzują procesy. W jaki sposób do nich dołączyć? Czy pełna automatyzacja jest w ogóle możliwa w przypadku mniejszych firm i freelancerów? Jak najbardziej, jeśli tylko spełnimy kilka warunków. Najważniejszy z nich to utrzymywanie developowanej aplikacji w takim kształcie, żeby można ją było w każdym momencie wdrożyć na serwer produkcyjny. Innymi słowy – główna linia kodu (master branch) powinna zawsze odzwierciedlać stan na LIVE serwerze.
Tutaj z pomocą przychodzi Git i praca na branchach: tworząc osobne pipeline’y dla developmentu, testów integracyjnych i deploymentu na produkcję, możemy cały proces rozpisać i zautomatyzować.
- Pierwszy pipeline pełni funkcję build serwera – zmiany są automatycznie testowane po spushowaniu do brancha developerskiego.
- Drugi pipeline dwa razy dziennie zaciąga zmiany na serwer stage’owy i odpala testy integracyjne.
- Trzeci pipeline automatycznie merdżuje zmiany ze Stage’a i wykonuje deploy na Produkcję.
Krok po kroku ku świetności
W teorii wszystko brzmi wspaniale. Jako twórcy narzędzi CI/CD jesteśmy jednak świadomi, że rzeczywistość wygląda inaczej: im mniejszy projekt, tym więcej osób pomija testy, wykorzystując tylko deployment. Nie uważamy, że tak powinno być, ale doskonale rozumiemy ten stan rzeczy: pokrywanie testami aplikacji jest czasochłonne, a nikt nie będzie nam płacił za pisanie testów pod stronę statyczną.
Najważniejsze jednak, żeby w ogóle zacząć: krok po kroku automatyzować taski i na bieżąco poprawiać workflow, dodając kolejne akcje do pipeline’a. Testować nowe rozwiązania, wdrażać team i stopniowo, pomalutku kierować się w stronę majaczącego na horyzoncie Świętego Graala.
Powodzenia!
Niespodzianka!
Tekst powstał przy współpracy z firmą Buddy (ale to nie jest ta niespodzianka :) ). Jak widać, Polacy są w stanie stworzyć produkt, który spokojnie może konkurować z największymi graczami na rynku! (to też nie niespodzianka).
Specjalnie dla Czytelników devstyle mamy świetne bonusy od ekipy Buddy!
Po pierwsze: 2x dłuższy trial na Buddy – pełny miesiąc zamiast standardowych 14 dni.
Po drugie: 20% rabatu dożywotnio na dowolny plan po skończeniu triala.
Yay!
Żeby aktywować bonusy, wystarczy zalogować się do serwisu linkiem poniżej i wysłać maila z hasłem devstyle na support@buddy.works lub na livechat w aplikacji. Promocja trwa do końca kwietnia.
A jeśli jeszcze Ci mało, to na koniec zapraszamy do obejrzenia webinaru, w którym Rafał, CTO w Buddy, pokazuje jak stworzyć pipeline dla Twojej aplikacji :)
