5 typowych pułapek CI / CD - i jak ich uniknąć

Devops może być jednym z najbardziej niebezpiecznych terminów w tworzeniu oprogramowania, ale większość z nas zgadza się, że pięć działań sprawia, że ​​devops jest tym, czym jest: ciągła integracja, ciągłe dostarczanie, infrastruktura chmury, automatyzacja testów i zarządzanie konfiguracją. Jeśli robisz te pięć rzeczy, robisz devops. Jasne jest, że wszystkie pięć jest ważnych, aby uzyskać rację, ale zbyt łatwo popełnić błąd. W szczególności ciągła integracja i ciągłe dostarczanie (CI / CD) mogą być najtrudniejszymi krokami DevOps do opanowania.

Ciągła integracja (CI) to proces, w którym programiści i testerzy wspólnie weryfikują nowy kod. Tradycyjnie programiści pisali kod i integrowali go raz w miesiącu do testów. To było nieefektywne - błąd w kodzie sprzed czterech tygodni mógł zmusić programistów do poprawienia kodu napisanego tydzień temu. Aby przezwyciężyć ten problem, CI zależy od automatyzacji w celu ciągłej integracji i testowania kodu. Zespoły Scrumowe używające kodu CI co najmniej codziennie, podczas gdy większość z nich zatwierdza kod dla każdej wprowadzonej zmiany.

Ciągłe dostarczanie (CD) to proces ciągłego tworzenia artefaktów do wydania. Niektóre firmy udostępniają oprogramowanie użytkownikom raz lub nawet kilka razy dziennie, podczas gdy inne udostępniają oprogramowanie w wolniejszym tempie z powodów rynkowych. Tak czy inaczej, zdolność do wydania jest testowana w sposób ciągły. Ciągłe wdrażanie jest możliwe dzięki środowiskom chmurowym. Serwery są skonfigurowane w taki sposób, aby można było wdrażać w środowisku produkcyjnym bez wyłączania i ręcznej aktualizacji serwerów.

Dlatego CI / CD jest procesem ciągłego rozwoju, testowania i dostarczania nowego kodu. Niektóre firmy, takie jak Facebook i Netflix, używają CI / CD do wydawania 10 lub więcej wydań tygodniowo. Inne firmy mają trudności z osiągnięciem tego tempa, ponieważ ulegają jednej lub kilku z pięciu pułapek, które omówię dalej.

Pułapka CI / CD nr 1: Najpierw automatyzacja niewłaściwych procesów

Ta pułapka ma tendencję do atakowania organizacji, które przechodzą od rozwoju wodospadu do DevOps. Nowe organizacje mają tę zaletę, że wdrażają CI / CD od podstaw. Istniejące firmy muszą stopniowo przechodzić od rozwoju ręcznego do wysoce zautomatyzowanego. Pełne przejście może zająć kilka miesięcy, co oznacza, że ​​musisz iteracyjnie wdrażać CI / CD.

Gdy zapytasz „Czy należy to teraz zautomatyzować?” przejrzyj następującą listę kontrolną:

  1. Jak często powtarza się proces lub scenariusz?
  2. Jak długo to trwa?
  3. Jacy ludzie i zależności zasobów są zaangażowani w ten proces? Czy powodują opóźnienia w CI / CD?
  4. Czy proces jest podatny na błędy, jeśli nie jest zautomatyzowany?
  5. Jaka jest pilna potrzeba zautomatyzowania tego procesu?

Korzystając z tej listy kontrolnej, możesz ustalić priorytety kroków w implementacji CI / CD. Przede wszystkim zautomatyzuj proces kompilacji kodu. Idealnie byłoby, gdybyś integrował kod kilka razy dziennie (1). Proces ten trwa ręcznie od kilku minut do kilku godzin (2). To zatrzymuje wyjście, dopóki kompilator nie zakończy zadania (3). Jest również podatny na błędy ludzkie (4), a ponieważ CI / CD to marzenie bez automatycznej integracji, jest to pilne (5).

Możemy uruchomić tę samą listę kontrolną podczas testowania. Przechodząc na CI / CD, możesz się zastanawiać: czy powinniśmy najpierw zautomatyzować testy funkcjonalne czy testy interfejsu użytkownika? Oba będą powtarzane co najmniej raz dziennie (1). Oba mogą zająć od dwóch do trzech godzin w przypadku średniej wielkości aplikacji (2). Ale obejmują wiele zależności (3). Jeśli automatyzujesz testy funkcjonalne, może nie być konieczne częste aktualizowanie skryptu automatyzacji. Z drugiej strony interfejs użytkownika często się zmienia i dlatego wymaga częstych zmian skryptów. Chociaż oba są podatne na błędy (4), powinieneś nadać priorytet testom funkcjonalnym przed testowaniem interfejsu użytkownika, aby jak najlepiej wykorzystać swoje zasoby (5).

Zróbmy to jeszcze raz z procesem konfigurowania środowisk. Ten scenariusz powtarza się tylko często, jeśli jesteś w trakcie szaleństwa rekrutacyjnego lub doświadczasz dużej rezygnacji z pracy (1). Jest to dość czasochłonny proces, który może zająć kilka godzin, jeśli nie dni (2). Nowi członkowie zespołu nie mogą nic zrobić bez otoczenia, więc wyraźnie widać zależność i opóźnienie (3). Nie powiedziałbym, że proces jest podatny na błędy (4), więc czy nadal jest pilny (5)? Skłaniam się ku tak, ale nadal priorytetowo traktuję integrację i testy funkcjonalne.

Nie ma czegoś takiego jak nadmierna automatyzacja. Gdybyś miał nieograniczone zasoby, zautomatyzowałbyś wszystko, co możliwe. To powiedziawszy, nie możesz osiągnąć całkowitej automatyzacji testów. Czasami możesz podzielić zadania na mniejsze segmenty i zautomatyzować je w łatkach. Czasami wystarczy po prostu szczegółowo udokumentować proces i wykonać go ręcznie.

Pułapka CI / CD nr 2: Mylące ciągłe wdrażanie w celu ciągłego dostarczania

Ciągłe wdrażanie to koncepcja, zgodnie z którą każda zmiana wprowadzona w bazie kodu zostanie wdrożona niemal natychmiast w środowisku produkcyjnym, jeśli wyniki potoku się powiodą. Jest to przerażające dla większości organizacji, ponieważ szybkie zmiany produktów mogą odstraszyć użytkowników.

Firmy uważają, że jeśli nie praktykują ciągłego wdrażania, to nie robią płyt CD. Nie potrafią odróżnić ciągłego wdrażania od ciągłego dostarczania.

Ciągłe dostarczanie to koncepcja, zgodnie z którą każda zmiana w bazie kodu przechodzi przez potok do momentu wdrożenia w środowiskach nieprodukcyjnych. Zespół natychmiast znajduje i rozwiązuje problemy, a nie później, kiedy planuje wydać bazę kodu.

Baza kodu jest zawsze na poziomie jakości, który jest bezpieczny do wydania. Kiedy wypuścić bazę kodu do produkcji, to decyzja biznesowa.

Podczas gdy ciągłe wdrażanie niepokoi większość organizacji, ciągłe dostarczanie rezonuje z nimi. Ciągła dostawa daje im kontrolę nad wprowadzaniem produktu, funkcjonalnością i czynnikami ryzyka. Jest czas na testy alfa, dla klientów beta, dla pierwszych użytkowników i tak dalej.

Pułapka nr 3 w zakresie CI / CD: Brak sensownych pulpitów nawigacyjnych i wskaźników

W implementacjach CI / CD zespół scrum może stworzyć dashboard, zanim członkowie dowiedzą się, co muszą śledzić. W rezultacie zespół pada ofiarą błędu logicznego: „To są wskaźniki, które posiadamy, więc muszą być ważne”. Zamiast tego przeprowadź ocenę progresywną przed zaprojektowaniem dashboardu.

Różni członkowie organizacji IT, a nawet różni członkowie zespołu scrum, mają różne priorytety. Na przykład ludzie w centrum obsługi sieci (NOC) uwielbiają czerwone, żółte i zielone wskaźniki. Takie tablice wskaźników sygnalizacji świetlnej pozwalają personelowi NOC na rozróżnianie problemów bez czytania gęstego tekstu lub obciążania ich zdolności analitycznych. Sygnalizacja świetlna ułatwia zarządzanie setkami serwerów.

Możesz ulec pokusie, aby użyć tablicy rozdzielczej sygnalizacji świetlnej do CI / CD. Zielony, jesteśmy na dobrej drodze. Żółty, zboczyliśmy z kursu, ale mamy plan, aby to rozwiązać. Czerwony, zboczyliśmy z kursu i prawdopodobnie musimy zmienić nasze cele.

Ten pulpit nawigacyjny jest prawdopodobnie przydatny dla mistrza scrum, ale co z wiceprezesem ds. Rozwoju lub dyrektorem technicznym? Jeśli zespół scrumowy ma przed sobą 350 godzin pracy na dwutygodniowy sprint, a jego 10 członków odpowiada za 35 godzin każdy, otrzymaliby odpowiednią liczbę punktów fabularnych. Kierownictwo wyższego szczebla może być mniej zainteresowane statusem punktów fabularnych, a bardziej zainteresowane wskaźnikiem „wypalenia”: szybkością wykonania zadania. Czy członkowie zespołu dźwigają swoje ciężary? Jak szybko? Czy z czasem się poprawiają?

Niestety, wskaźniki wypalenia mogą być mylące, jeśli różni interesariusze nie rozumieją uzgodnionych nawyków zespołu scrumowego. Niektóre zespoły szybko tracą punkty. Inni czekają do końca sprintu, aby spalić otwarte punkty. Pulpit powinien to uwzględniać.      

Jeśli potrafisz ocenić, jakich danych chcą wszyscy użytkownicy, i ustalić standardową narrację opisującą znaczenie tych danych, możesz zaprojektować przydatny pulpit nawigacyjny. Ale nie miej obsesji na punkcie treści kosztem wyglądu. Zapytaj interesariuszy, jak chcą, aby wyglądał. Czy wykresy, tekst lub liczby byłyby najlepsze?

Są to kwestie, które należy zbadać w ocenie progresywnej. Pokazują, jak trudne jest stworzenie użytecznej tablicy rozdzielczej CI / CD - i uszczęśliwienie wszystkich. Zbyt często najbardziej głośny członek zespołu przejmuje proces, a inni czują się sfrustrowani, że pulpit nawigacyjny spełnia preferencje tylko jednej osoby. Posłuchaj wszystkich.  

Pułapka CI / CD nr 4: Brak koordynacji między ciągłą integracją a ciągłym dostarczaniem

Ta pułapka prowadzi nas z powrotem do naszej zgodnej definicji devops, która zakłada, że ​​ciągła integracja i ciągłe dostarczanie to dwa różne elementy. CI zasila CD. Wdrożenie przyzwoitego potoku ciągłej integracji i pełnego systemu ciągłego dostarczania zajmuje miesiące i wymaga współpracy. Zapewnienie jakości, zespół devops, inżynierowie operacyjni, mistrzowie scrumu - wszyscy muszą wnieść swój wkład. Być może najtrudniejszym aspektem CI / CD jest raczej czynnik ludzki niż jakiekolwiek techniczne wyzwanie, które omówiliśmy. Tak jak nie możesz zaprogramować zdrowych relacji między dwojgiem ludzi, nie możesz zautomatyzować współpracy i komunikacji.

Aby ocenić ten poziom koordynacji, porównaj swój proces CI / CD z najlepszymi w branży. Firmy takie jak Netflix mogą zakończyć integrację, testy i dostawę w ciągu dwóch do trzech godzin. Stworzyli system, który przekazuje kod z ręki do ręki bez niezdecydowania i dyskusji. Nie, nie jest to w 100 procentach zautomatyzowane, ponieważ jest to niemożliwe przy obecnej technologii.

Pułapka CI / CD nr 5: Równoważenie częstotliwości wykonywania zadań ciągłej integracji i wykorzystania zasobów

Zadania ciągłej integracji mają być uruchamiane przy każdej zmianie wprowadzanej w kodzie. Udane prace pozwalają na zmiany, podczas gdy niepowodzenia odrzucają zmiany. Zachęca to programistów do sprawdzania mniejszych fragmentów kodu, uruchamiając więcej kompilacji w ciągu jednego dnia. Jednak niepotrzebne prace związane z ciągłą integracją pochłaniają zasoby, co marnuje czas i pieniądze.

Ponieważ proces ten wiąże się z dużym wykorzystaniem zasobów (procesor, moc, czas), oprogramowanie powinno zostać podzielone na mniejsze komponenty, aby utworzyć szybciej działające potoki. Lub zadania ciągłej integracji powinny być zaprojektowane tak, aby wsadowe zameldowania były najpierw testowane lokalnie. Celem jest znalezienie równowagi między częstotliwością wykonywania zadań ciągłej integracji a wykorzystaniem zasobów.

Miej cel w zasięgu wzroku

Zagłębiając się w pułapki CI / CD - wraz z całą jego ezoteryczną terminologią - łatwo stracić z oczu, dlaczego to ma znaczenie. Ostatecznie CI / CD jest niezbędne, ponieważ spełnia cele biznesowe.

Kierownicy ds. Technologii wiedzą, że ciągła ewolucja, szybkie poprawki i wyniki jakościowe tworzą i zatrzymują klientów. Wiedzą, że nieudana premiera zaprasza do recenzji w App Store, a odzyskanie wysokich recenzji jest trudniejsze niż ich utrzymanie. Devops może zapewnić Twojemu zespołowi lepsze doświadczenie zawodowe, ale nie dlatego firmy wdrażają DevOps.

Mówiąc najprościej, pułapki CI / CD są warte przeanalizowania, ponieważ w grę wchodzą miliardy dolarów. Chociaż nie sugeruję dodawania paska giełdowego ani narzędzia do śledzenia recenzji w App Store do pulpitu CI / CD, zachęcam do pozostania tego świadomym. Wiele zależy od szczegółów CI / CD.

Zubin Irani jest współzałożycielem i dyrektorem generalnym cPrime, firmy konsultingowej oferującej pełen zakres usług, która wdraża zwinne transformacje i dostarcza zwinne rozwiązania dla ponad 50 firm z listy Fortune 100 i wielu największych pracodawców w Dolinie Krzemowej.

New Tech Forum to miejsce, w którym można badać i omawiać pojawiające się technologie dla przedsiębiorstw na niespotykaną dotąd skalę i dogłębnie. Wybór jest subiektywny, oparty na naszym wyborze technologii, które uważamy za ważne i najbardziej interesujące dla czytelników. nie przyjmuje marketingowych materiałów reklamowych do publikacji i zastrzega sobie prawo do edycji wszystkich przesłanych treści. Wszelkie zapytania należy kierować na adres [email protected]