Jeśli Twoja firma dopiero wdraża DevOps lub narzędzia CI/CD, poznanie najczęstszych błędów może okazać się przydatne, aby ich nie powtarzać i nie stąpać po cudzych grzędach.
Zespół przetłumaczył artykuł .
Brak gotowości do zmiany kultury i procesów
Patrząc na cykliczny diagram , widać, że w praktykach DevOps testowanie jest ciągłym zadaniem, fundamentalną częścią każdego wdrożenia.
Nieskończony cykliczny diagram DevOps
Testowanie i zapewnienie jakości w procesie rozwoju i dostarczania są integralną częścią wszystkiego, co robią programiści. Wymaga to zmiany myślenia, aby włączyć testowanie do każdego zadania.
Testowanie staje się częścią codziennej pracy każdego członka zespołu. Przechodzenie na ciągłe testowanie nie jest łatwe, należy być na to gotowym.
Brak informacji zwrotnej
Efektywność DevOps zależy od stałej informacji zwrotnej. Ciągłe doskonalenie jest niemożliwe bez miejsca na współpracę i komunikację.
Firmy, które nie organizują spotkań retrospektywnych, mają trudności z wprowadzeniem kultury ciągłej informacji zwrotnej w CI/CD. Spotkania retrospektywne odbywają się na końcu każdej iteracji, na których członkowie zespołu omawiają, co poszło dobrze, a co źle. Spotkania retrospektywne stanowią fundament Scrum/Agile, ale są również niezbędne dla DevOps.
Wynika to z tego, że spotkania retrospektywne wprowadzają nawyk wymiany opinii i feedbacku. Jednym z najważniejszych elementów na początku jest organizacja cyklicznych spotkań retro, aby stały się one zrozumiałe i naturalne dla całego zespołu.
Jeśli chodzi o jakość oprogramowania, za jej utrzymanie odpowiadają wszyscy członkowie zespołu. Na przykład, programiści mogą pisać testy jednostkowe oraz pisać kod z uwzględnieniem testowalności, co pomaga zredukować ryzyko od samego początku.
Jednym ze sposobów na odzwierciedlenie zmiany w postrzeganiu testowania jest nazywanie testerów nie QA, ale testerami oprogramowania lub inżynierami jakości. Ta zmiana może wydawać się zbyt prosta lub wręcz głupia. Jednak nazywanie kogoś "specjalistą ds. zapewnienia jakości oprogramowania" wprowadza błędne wyobrażenie o tym, kto jest odpowiedzialny za jakość produktu. W praktykach Agile, CI/CD i DevOps wszyscy ponoszą odpowiedzialność za jakość oprogramowania.
Innym ważnym aspektem jest zrozumienie, co oznacza jakość dla całego zespołu oraz każdego jego członka, organizacji i interesariuszy.
Błędne zrozumienie zakończenia etapu
Ponieważ jakość to ciągły i wspólny proces, potrzebne jest wspólne zrozumienie zakończenia etapu. Jak rozpoznać, że etap został zakończony? Co się dzieje, gdy etap jest oznaczony jako ukończony na tablicy Trello lub innej tablicy kanban?
Definicja ukończonego etapu (DoD) jest potężnym narzędziem w kontekście CD DevOps/CI. Pomaga lepiej zrozumieć standardy jakości tego, co i jak buduje zespół.
Zespół deweloperski musi ustalić, co oznacza 'Gotowe'. Muszą usiąść i stworzyć listę cech, które powinny być spełnione na każdym etapie, aby projekt mógł być uznany za zakończony.
DoD sprawia, że proces staje się bardziej przejrzysty i ułatwia wprowadzenie CI/CD, o ile jest zrozumiały dla wszystkich członków zespołu i wzajemnie uzgodniony.
Brak realistycznych, jasno określonych celów
To jedna z najczęściej cytowanych rad, ale warto ją powtórzyć. Dla sukcesu wszelkich poważnych przedsięwzięć, w tym wprowadzenia CI/CD lub DevOps, należy ustalić realne cele i mierzyć wydajność w odniesieniu do nich. Co chcesz osiągnąć dzięki CI/CD? Czy pozwala to na szybsze wydawanie wersji o lepszej jakości?
Wszystkie postawione cele muszą być nie tylko przejrzyste i realistyczne, ale także zgodne z bieżącą działalnością firmy. Na przykład, jak często twoi klienci potrzebują nowych poprawek lub wersji? Nie ma potrzeby przeciążania procesów i szybszego wydawania wersji, jeśli nie przynosi to dodatkowych korzyści dla użytkowników.
Nie zawsze musisz wdrażać zarówno CD, jak i CI. Na przykład firmy z wysokim stopniem regulacji, takie jak banki i kliniki medyczne, mogą działać tylko z CI.
CI jest doskonałym punktem wyjścia dla każdej firmy wprowadzającej DevOps. Jego wdrożenie w firmie znacząco zmienia podejścia do dostarczania oprogramowania. Po opanowaniu CI można pomyśleć o poprawie całego procesu, zwiększeniu prędkości wdrożeń i innych zmianach.
Dla wielu organizacji wystarczy jedno CI, a CD należy wdrożyć tylko wtedy, gdy przynosi dodatkowe korzyści.
Brak odpowiednich paneli monitorowania i metryk
Gdy już ustalisz cele, zespół programistów może stworzyć panel monitorowania do pomiaru KPI. Przed jego opracowaniem warto przeprowadzić ocenę parametrów, które będą śledzone.
Różne raporty i aplikacje są przydatne dla różnych członków zespołu. Scrum Masterzy bardziej interesują się statusem i zasięgiem, podczas gdy najwyższe kierownictwo może być zainteresowane szybkością wypalenia specjalistów.
Niektóre zespoły korzystają z pulpitów nawigacyjnych z czerwonymi, żółtymi i zielonymi wskaźnikami do oceny statusu CI/CD, aby sprawdzić, czy wszystko przebiega prawidłowo lub wystąpił błąd. Czerwony oznacza, że należy zwrócić uwagę na to, co się dzieje.
Jednakże, jeśli panele informacyjne nie są ustandaryzowane, mogą wprowadzać w błąd. Zbadaj, jakie dane są potrzebne wszystkim, a następnie stwórz ustandaryzowany opis ich znaczenia. Dowiedz się, co ma więcej sensu dla interesariuszy: wykresy, tekst czy liczby.
Brak ręcznych testów
Automatyzacja testowania stanowi fundament dobrego procesu CI/CD. Jednak automatyzacja testowania na każdym etapie nie oznacza, że nie powinieneś przeprowadzać testów ręcznych.
Aby zbudować skuteczny proces CI/CD, potrzebne są także testy ręczne. Zawsze będą pewne aspekty testowania, które wymagają analizy przez człowieka.
Warto rozważyć połączenie wysiłków związanych z testowaniem ręcznym w procesie. Po zakończeniu ręcznego testowania niektórych przypadków testowych, możesz przejść do etapu wdrażania.
Nie próbuj poprawiać testów
Skuteczny pipeline CI/CD wymaga dostępu do odpowiednich narzędzi, czy to zarządzania testami, czy integracji i stałego monitorowania.
Tworzenie silnej kultury skupionej na jakości dąży do , monitorowania interakcji z klientami po wdrożeniu i śledzenia ulepszeń.
Oto kilka praktycznych wskazówek, które można łatwo wdrożyć:
- Upewnij się, że testy są łatwe do napisania i wystarczająco elastyczne, aby nie psuły się podczas refaktoryzacji kodu.
- Zespoły programistyczne powinny być zaangażowane w proces testowania — widzieć listę problemów i zapytań użytkowników, które są ważne do sprawdzenia w czasie pipeline'ów CI.
- Możesz nie mieć pełnego pokrycia testami, ale zawsze dbaj o to, aby strumienie istotne dla UX i interakcji z klientami były przetestowane.
Ostatni, ale nie mniej ważny punkt
Przejście do CI/CD zazwyczaj inicjują pracownicy na niższych szczeblach, ale ostatecznie jest to transformacja, która wymaga zaangażowania kierownictwa, a także czasu i zasobów ze strony firmy. CI/CD to zestaw umiejętności, procesów, narzędzi oraz zmiana kulturowa, którą można wprowadzić tylko systemowo.
Co jeszcze przeczytać na ten temat:
- .
- .
- .
Źródło: habr.com
