Jeśli Twoja firma dopiero wprowadza narzędzia DevOps lub CI/CD, przydatne może być zapoznanie się z najczęstszymi błędami, aby ich nie powtarzać i nie nadepnąć na czyjąś prowizję.
Zespół przetłumaczył artykuł .
Brak przygotowania do zmiany kultury i procesów
Jeśli spojrzysz na diagram cykliczny jasne jest, że w praktykach DevOps testowanie jest czynnością ciągłą, fundamentalną częścią każdego pojedynczego wdrożenia.
Wykres nieskończonego cyklu DevOps
Testowanie i zapewnianie jakości podczas opracowywania i dostarczania są istotną częścią wszystkiego, co robią programiści. Wymaga to zmiany sposobu myślenia, aby uwzględnić testowanie w każdym zadaniu.
Testowanie staje się częścią codziennej pracy każdego członka zespołu. Przejście na ciągłe testowanie nie jest łatwe, trzeba się na to przygotować.
Brak informacji zwrotnej
Skuteczność DevOps zależy od stałego feedbacku. Ciągłe doskonalenie jest niemożliwe, jeśli nie ma miejsca na współpracę i komunikację.
Firmom, które nie organizują spotkań retrospektywnych, trudno jest wdrożyć kulturę ciągłego feedbacku w CI/CD. Na koniec każdej iteracji odbywają się spotkania retrospektywne, podczas których członkowie zespołu omawiają, co poszło dobrze, a co źle. Spotkania retrospektywne są podstawą Scrum/Agile, ale są również niezbędne w DevOps.
Dzieje się tak, ponieważ spotkania retrospektywne kształtują nawyk wymiany informacji zwrotnych i opinii. Jednym z najważniejszych punktów na początku jest zorganizowanie cyklicznych spotkań retro, tak aby stały się zrozumiałe i znane całemu zespołowi.
Jeśli chodzi o jakość oprogramowania, wszyscy członkowie zespołu są odpowiedzialni za jego utrzymanie. Na przykład programiści mogą pisać testy jednostkowe, a także pisać kod z myślą o testowalności, pomagając od samego początku zmniejszyć ryzyko.
Jednym z prostych sposobów odzwierciedlenia zmiany w myśleniu o testowaniu jest wezwanie testerów, a nie testerów kontroli jakości, ale testera oprogramowania lub inżyniera jakości. Ta zmiana może wydawać się zbyt prosta lub nawet głupia. Jednak nazywanie kogoś „osobą zajmującą się zapewnieniem jakości oprogramowania” daje błędne wyobrażenie o tym, kto jest odpowiedzialny za jakość produktu. W praktykach Agile, CI/CD i DevOps za jakość oprogramowania odpowiada każdy.
Kolejnym ważnym punktem jest zrozumienie, co jakość oznacza dla całego zespołu i każdego z jego członków, organizacji i interesariuszy.
Nieporozumienie dotyczące ukończenia etapu
Jeśli jakość jest procesem ciągłym i ogólnym, potrzebne jest wspólne zrozumienie zakończenia etapu. Po czym poznajesz, że etap się skończył? Co się stanie, gdy krok zostanie oznaczony jako ukończony na tablicy Trello lub innej tablicy Kanban?
Definicja wykonania (DoD) to potężne narzędzie w kontekście CD DevOps/CI. Pomaga lepiej zrozumieć standardy jakości tego, co i jak buduje zespół.
Zespół programistów musi zdecydować, co oznacza „Gotowe”. Muszą usiąść i sporządzić listę cech, które muszą zostać spełnione na każdym etapie, aby można było uznać je za zakończone.
DoD czyni proces bardziej przejrzystym i ułatwia wdrożenie CI/CD, jeśli jest zrozumiały dla wszystkich członków zespołu i obustronnie uzgodniony.
Brak realistycznych, jasno określonych celów
To jedna z najczęściej cytowanych rad, ale warto ją powtarzać. Aby odnieść sukces w jakimkolwiek większym przedsięwzięciu, w tym CI/CD lub DevOps, musisz wyznaczyć realistyczne cele i mierzyć ich wydajność. Co chcesz osiągnąć za pomocą CI/CD? Czy pozwala to na szybsze publikacje i lepszą jakość?
Wszelkie wyznaczone cele muszą być nie tylko przejrzyste i realistyczne, ale także spójne 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 wiąże się to z dodatkowymi korzyściami dla użytkowników.
Ponadto nie zawsze trzeba wdrażać zarówno CD, jak i CI. Na przykład firmy podlegające ścisłym regulacjom, takie jak banki i kliniki medyczne, mogą współpracować wyłącznie z IK.
CI stanowi dobry punkt wyjścia dla każdej firmy wdrażającej DevOps. Po jego wdrożeniu podejście firm do dostarczania oprogramowania znacząco się zmienia. Kiedy już opanujesz CI, możesz pomyśleć o usprawnieniu całego procesu, zwiększeniu szybkości wdrażania i innych zmianach.
Dla wielu organizacji sama CI wystarczy, a CD powinno być wdrażane tylko wtedy, gdy wnosi wartość dodaną.
Brak odpowiednich dashboardów i wskaźników
Po ustaleniu celów zespół programistów może utworzyć pulpit nawigacyjny do pomiaru wskaźników KPI. Przed jego opracowaniem warto ocenić parametry, które będą monitorowane.
Różne raporty i aplikacje są przydatne dla różnych członków zespołu. Scrum Mastera bardziej interesuje status i zasięg. Natomiast kadra kierownicza wyższego szczebla może być zainteresowana wskaźnikiem wypalenia specjalistów.
Niektóre zespoły używają również pulpitów nawigacyjnych z czerwonymi, żółtymi i zielonymi wskaźnikami do oceny statusu CI/CD i zrozumienia, czy robią wszystko dobrze, czy też wystąpił błąd. Czerwony oznacza, że musisz zwracać uwagę na to, co się dzieje.
Jeśli jednak dashboardy nie są ustandaryzowane, mogą wprowadzać w błąd. Przeanalizuj, jakich danych potrzebują wszyscy, a następnie utwórz ujednolicony opis ich znaczenia. Dowiedz się, co ma większy sens dla interesariuszy: grafika, tekst czy liczby.
Żadnych testów manualnych
Automatyzacja testów stanowi podstawę dobrego potoku CI/CD. Jednak automatyczne testowanie na wszystkich etapach nie oznacza, że nie należy przeprowadzać testów ręcznych.
Aby zbudować skuteczny potok CI/CD, potrzebujesz również testów ręcznych. Zawsze będą pewne aspekty testowania, które wymagają analizy przez człowieka.
Warto rozważyć włączenie testów ręcznych do swojego potoku. Po zakończeniu ręcznego testowania niektórych przypadków testowych można przejść do fazy wdrożenia.
Nie próbuj ulepszać testów
Skuteczny rurociąg CI/CD wymaga dostępu do odpowiednich narzędzi, czy to do zarządzania testami, czy do integracji i ciągłego monitorowania.
Celem jest stworzenie silnej kultury zorientowanej na jakość , monitorowanie interakcji z klientami po wdrożeniu i śledzenie ulepszeń.
Oto kilka praktycznych wskazówek, które możesz łatwo wdrożyć:
- Upewnij się, że Twoje testy są łatwe do napisania i wystarczająco elastyczne, aby nie zepsuć się podczas refaktoryzacji kodu.
- Zespoły programistyczne powinny zostać włączone w proces testowania - zobacz listę problemów i żądań użytkowników, które są ważne do testowania podczas potoków CI.
- Być może nie masz pełnego zasięgu testów, ale zawsze upewnij się, że testowane są przepływy ważne dla UX i doświadczenia klienta.
Ostatni, ale nie najmniej ważny punkt
Przejście na CI/CD zwykle odbywa się oddolnie, ale ostatecznie jest to transformacja wymagająca wsparcia ze strony kierownictwa, czasu i zasobów ze strony firmy. W końcu CI/CD to zestaw umiejętności, procesów, narzędzi i restrukturyzacji kulturowej; takie zmiany można wprowadzać jedynie systematycznie.
Co jeszcze przeczytać na ten temat:
- .
- .
- .
Źródło: www.habr.com