Jeśli naszym celem jest szybki rozwój oprogramowania i częste dostarczanie działających buildów na produkcję, trzeba zautomatyzować przynajmniej część procesu testowania i dostarczania. W idealnym przypadku oznacza to wdrożenie potoków CI/CD dla projektów, wraz z zestawami testów, które wychwytują błędy zanim klienci zobaczą oprogramowanie, oraz skryptami implementującymi poszczególne kroki w cyklu życia.

Ciągła integracja (CI) to metodologia automatyzacji budowania oprogramowania, pakowania i testowania w spójny sposób. CI pomaga dać zespołowi pewność, że zmiany, które sprawdzają w kontroli wersji kodu źródłowego nie spowodują przerwania kompilacji lub wprowadzenia błędów do oprogramowania. Punktem końcowym CI jest zazwyczaj zakończony check-in do głównej gałęzi repozytorium oprogramowania.

Zobacz również:

• IBM prezentuje modele fundamentalne generatywnej AI
• Technologie, które miały być wieczne, a zostały zapomniane

Z kolei continuous delivery (CD) automatyzuje dostarczanie przetestowanego oprogramowania do środowisk infrastrukturalnych. Nie oznacza to zwykle wrzucenia go bezpośrednio na produkcję celem sprawdzenia, czy klienci się skarżą. Zazwyczaj organizacje zaczynają od wypchnięcia kompilacji do środowiska deweloperskiego. Po tym, jak deweloperzy sami obrobią nowy build i wypuszczą go, zazwyczaj trafia on do środowiska testowego, gdzie jest używany przez szerszą grupę użytkowników (czasami tylko oddelegowani wewnętrzni testerzy, czasami większa grupa użytkowników zapisanych na beta testy lub „dog-fooding”) i ściśle monitorowany. Wreszcie, jeśli wszystko idzie dobrze, testerzy podpisują się i przesuwają nową wersję do środowiska produkcyjnego.

Na każdym etapie CD istnieją opcje szybkiego powrotu do starszej wersji i generowania zgłoszeń błędów, które deweloperzy mogą uwzględnić w nowej wersji. Celem nie jest wypchnięcie wielu buildów na produkcję, ale raczej ciągłe poprawianie i ulepszanie oprogramowania bez wprowadzania regresji. Innym terminem dla tych praktyk jest „devops”.

Dlaczego warto hostować CI/CD w chmurze?

Hosting platformy CI/CD we własnym centrum danych wybierają zwłaszcza firmy, które upoważniają do hostowania swoich aplikacji i danych wewnątrz firewalla. Wadą takiego rozwiązania jest potrzeba posiadania zespołu do utrzymania infrastruktury i inwestycji w serwery.

Zazwyczaj lepszą opcją jest hosting w chmurze. Jego koszt jest niewielki, a ten wydatek operacyjny jest równoważony przez świadczone usługi: onboarding, utrzymanie infrastruktury, utrzymanie bezpieczeństwa, wsparcie i utrzymanie oprogramowania CI/CD. Hosting oprogramowania CI/CD w chmurze często ułatwia i przyspiesza interakcję rurociągów z repozytoriami kodu źródłowego, jeśli one również znajdują się w chmurze. Jeśli nasi deweloperzy i testerzy są rozproszeni geograficznie, hostowanie repozytoriów w chmurze często daje deweloperom lepsze doświadczenie niż hosting w zdalnych serwerach za firewallami.

Możliwe jest również wdrożenie CI/CD na hybrydzie serwerów lokalnych i chmurowych. Kilka z najnowszych ofert CI/CD działa w kontenerach na klastrach Kubernetes, które mogą działaś jednocześnie on premise i w chmurze. W hybrydowym scenariuszu wdrożenia można umieścić każdy komponent tam, gdzie ma to największy sens, biorąc pod uwagę fizyczną lokalizację samych deweloperów i lokalizacje sieciowe innych serwerów w infrastrukturze rozwojowej.

CI/CD musi integrować się z repozytoriami organizacji

Repozytoria są niezbędne dla CI i CD. Poza byciem punktem końcowym procesu check-in i testowania, repozytoria oprogramowania są preferowanym miejscem do przechowywania skryptów i plików konfiguracyjnych CI i CD. Owszem, wiele platform CI/CD może przechowywać skrypty i inne pliki wewnętrznie, ale zazwyczaj lepiej jest mieć je w kontroli wersji poza narzędziem.

Prawie wszystkie narzędzia CI/CD mogą współdziałać z Gitem. Niektóre integrują się również bezpośrednio z GitHub, GitHub Enterprise, GitLab i/lub Bitbucket. Kilka z nich obsługuje również Subversion i/lub Mercurial.

Narzędzia CI/CD muszą wspierać języki programowania i narzędzia używane w firmie

Każdy język programowania lub grupa języków (języki JVM, języki skompilowane LLVM, języki .NET i tak dalej) ma swoje własne narzędzia do budowania i testowania. Aby być użytecznym dla Ciebie, narzędzie CI / CD musi wspierać wszystkie języki, które są częścią danego projektu. W przeciwnym razie może być konieczne napisanie jednego lub więcej pluginów do narzędzia.

Obrazy Docker stają się coraz ważniejsze dla rozproszonych, modułowych i mikroserwisowych wdrożeń oprogramowania. Dobrze jest, jeśli wybrane narzędzie CI/CD radzi sobie z obrazami Dockera, w tym tworzy obraz z twojego kodu źródłowego, binariów i warunków wstępnych oraz wdraża obraz do określonego środowiska. Jeśli tego zabraknie, być może trzeba będzie napisać wtyczki lub skrypty, aby zaimplementować potrzebne funkcje Dockera. Podobnie, narzędzie CI/CD powinno wspierać Kubernetes i inne systemy orkiestracji kontenerów, których używamy w swoich środowiskach.

Czy programiści w naszej firmie rozumieją CI/CD i narzędzia, które chcemy zastosować?

Zasady CI i CD mogą wydawać się oczywiste, ale diabeł tkwi w szczegółach. Różne narzędzia CI/CD mają różny poziom wsparcia i dokumentacji: książki, dokumentacja techniczna i fora dyskusyjne.

Wybierz różne narzędzia CI/CD dla różnych projektów

Błędem jest założenie, że jedna platforma będzie optymalna dla wszystkich projektów tworzenia oprogramowania. Większość sklepów używa wielu języków programowania i środowisk, a nie każda platforma CI/CD będzie dobrze wspierać wszystkie z nich.

Lepiej podobierać platformy CI/CD pod kątem naszych poszczególnych projektów, zamiast szukać jednej, kompromisowej platformy. Ogólne zasady CI i CD przenoszą się z jednej platformy na drugą, nawet jeśli napisane dla nich skrypty nie zawsze są przenośne. Owszem, dodatkowy czas na zapoznanie się z każdą nową platformą kosztuje zespół devops, jest to jednak najprawdopodobniej mniej kosztowne niż konieczność szerokiego dostosowania narzędzia CI/CD.

Planuj przyszłe migracje CI/CD

Podobnie, nie zakładajmy, że dana platforma CI/CD będzie służyć potrzebom naszych projektów na zawsze. Lepiej zabezpieczyć się, na przykład poprzez przechowywanie skryptów w repozytoriach, a nie w narzędziu CI/CD.

Preferuj bezserwerowe CI/CD wszędzie tam, gdzie to możliwe

Ogólnie rzecz biorąc, wdrożenia kontenerów w chmurze są tańsze niż wdrożenia instancji serwera w chmurze, a wdrożenia chmury bezserwerowej są tańsze niż wdrożenia kontenerów. Bezserwerowość oznacza, że kontener uruchamiający interesujący nas proces jest inicjowany w razie potrzeby, zazwyczaj w odpowiedzi na zdarzenie. W przypadku CI/CD, zdarzeniem wyzwalającym jest zazwyczaj sprawdzenie kodu w określonej gałęzi repozytorium; Webhook repozytorium uruchamia wtedy proces bezserwerowy. Gdy proces się zakończy, zasoby są zwalniane.

Jedną z niewielu platform CI/CD, która może uruchomić proces bezserwerowy jest Serverless CI/CD, część Serverless Framework Pro, rozszerzonej wersji open source Serverless Framework. Serverless CI/CD jest zoptymalizowany do wdrażania aplikacji bezserwerowych i obecnie działa tylko na AWS. Będziesz musiał określić, czy obsługuje twoją aplikację wystarczająco dobrze, aby użyć.

Gdzie znajdują się nasze zasoby w chmurze?

Aby zoptymalizować opartą na chmurze konfigurację CI/CD (lub dowolnej aplikacji w chmurze), pomaga, jeśli wszystkie nasze zasoby są „blisko” siebie. „Blisko” w tym kontekście częściowo odnosi się do lokalizacji geograficznej, a częściowo do lokalizacji sieciowej. Na przykład, jeśli nasza baza danych znajduje się w Australii, a aplikacja jest w Ameryce Północnej, spowoduje to duże opóźnienie za każdym razem, gdy aplikacja musi odczytać lub zapisać dane. W mniejszej skali, jeśli nasza aplikacja i baza danych znajdują się w tej samej strefie dostępności (AZ), opóźnienie między nimi zostanie zminimalizowane. Jeśli znajdują się w różnych strefach w tym samym regionie, opóźnienie będzie wyższe, ale nie tak wysokie, jak gdyby były w różnych regionach.

Podobnie, jeśli nasza baza danych znajduje się na Google Cloud Platform w Wirginii, a aplikacja jest na Microsoft Azure w Wirginii, opóźnienie będzie wyższe niż gdyby oba były na tym samym dostawcy chmury w tym samym AZ. Wszystko to dotyczy również repozytorium (które jest zasadniczo bazą danych), oprogramowania CI / CD, rzeczywistej aplikacji oraz programistów i testerów. Lepiej, jeśli wszyscy są „w pobliżu”, chociaż efekty opóźnienia nie są tak rażące w tej sytuacji, jak w przypadku, powiedzmy, interaktywnej gry w czasie rzeczywistym.

Jeśli programiści mogą niezawodnie i bez zauważalnego czasu oczekiwania wrzucać zatwierdzenia (commits) do głównego repozytorium, to zazwyczaj będą zadowoleni. Podobnie, jeśli użytkownicy i testerzy są wystarczająco blisko aplikacji, aby uzyskać milisekundowe czasy reakcji, będą również zadowoleni. Dla oprogramowania CI/CD kluczem są niezawodne połączenia z punktami wdrożenia. Małe opóźnienia mogą być tolerowane, o ile nie powodują time-outów lub upuszczonych pakietów.

Zrób proof of concept zanim się zaangażujesz

Po zakończeniu wdrożenia CI/CD będzie krytyczną częścią naszej infrastruktury.

Ważne jest, aby wykonać rygorystyczny proof of concept przed rozpoczęciem rozwijania rurociągów CI/CD. Przed rozpoczęciem fazy CD należy przetestować część CI.

Skróty pochodzą od polskiej redakcji.

Źródło: Infoworld