Jeśli Twoja firma dopiero wprowadza DevOps lub narzędzia CI/CD, warto zapoznać się z najczęściej popełnianymi błędami, aby ich nie powtarzać i nie natrafić na te same pułapki.
Zespół przetłumaczyła artykuł .
Brak gotowości na zmianę kultury i procesów
Patrząc na cykliczny diagram , widać, że w praktykach DevOps testowanie jest ciągłym zadaniem, podstawowym elementem każdego pojedynczego wdrożenia.
Nieskończony cykliczny diagram DevOps
Testowanie i zapewnienie jakości w procesie tworzenia i dostarczania są nieodłączną 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. Przejście na ciągłe testowanie nie jest łatwe, trzeba być na to gotowym.
Brak informacji zwrotnej
Skuteczność DevOps zależy od ciągłej informacji zwrotnej. 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 wprowadzić kulturę ciągłej informacji zwrotnej w CI/CD. Spotkania retrospektywne odbywają się na koniec każdej iteracji, na których uczestnicy grupy omawiają, co poszło dobrze, a co źle. Spotkania retrospektywne są fundamentem Scrum/Agile, ale są też niezbędne dla DevOps.
Ma to związek z tym, że spotkania retrospektywne uczą nawyku wymiany informacji zwrotnej i opinii. Jednym z najważniejszych punktów na starcie jest organizacja powtarzających się spotkań retro, aby stały się one zrozumiałe i naturalne dla całego zespołu.
Kiedy mowa o jakości oprogramowania, każdy członek zespołu ponosi odpowiedzialność za jej utrzymanie. Na przykład programiści mogą pisać testy jednostkowe, a także pisać kod z myślą o 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, a testerami oprogramowania lub inżynierami ds. jakości. Ta zmiana może wydawać się zbyt prosta lub nawet głupia. Jednak gdy kogoś nazywa się „specjalistą ds. zapewnienia jakości oprogramowania”, może to wprowadzać błędne wyobrażenie o tym, kto ponosi odpowiedzialność za jakość produktu. W praktykach Agile, CI/CD i DevOps wszyscy są odpowiedzialni za jakość oprogramowania.
Kolejnym ważnym punktem jest zrozumienie, co oznacza jakość dla całego zespołu i każdego jego członka, organizacji oraz interesariuszy.
Błędne zrozumienie zakończenia etapu
Jeśli jakość to ciągły i wspólny proces, to konieczne jest wspólne zrozumienie zakończenia etapu. Jak można zrozumieć, że etap jest zakończony? Co się dzieje, kiedy etap jest oznaczony jako ukończony na tablicy Trello lub innej tablicy Kanban?
Definicja zakoń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ół deweloperów powinien ustalić, co oznacza „Gotowe”. Muszą usiąść i stworzyć listę cech, które mają być spełnione na każdym etapie, aby można było go uznać za zakończony.
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 wzajemnie uzgodniony.
Brak realistycznych, jasno określonych celów
To jedna z najczęściej cytowanych rad, ale warto ją powtórzyć. Dla sukcesu jakiegokolwiek poważnego przedsięwzięcia, w tym wdrożenia CI/CD lub DevOps, należy ustalić realistyczne cele i mierzyć wydajność w odniesieniu do nich. Co chcesz osiągnąć dzięki CI/CD? Umożliwia to szybsze wydawanie wersji z lepszą jakością?
Wszystkie wyznaczone cele powinny być nie tylko przejrzyste i realistyczne, ale także odpowiadać bieżącej 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 wydawania wersji szybciej, jeśli nie przynosi to dodatkowych korzyści dla użytkowników.
Ponadto 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 dobrą punktem wyjścia dla każdej firmy wdrażającej DevOps. Wdrożenie CI znacznie zmienia podejścia do dostarczania oprogramowania w przedsiębiorstwie. Po opanowaniu CI możesz zastanowić się nad poprawą całego procesu, zwiększeniem szybkości wydania i innymi zmianami.
Dla wielu organizacji wystarczające jest samo CI, a CD powinno być wdrażane tylko wtedy, gdy przynosi dodatkowe korzyści.
Brak odpowiednich paneli monitorowania i metryk
Gdy tylko ustalisz cele, zespół deweloperski może stworzyć panel monitorowania do pomiaru KPI. Przed jego opracowaniem warto ocenić parametry, 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. Natomiast wyższe kierownictwo może być zainteresowane szybkością wypalenia specjalistów.
Niektóre zespoły korzystają również z pulpitów nawigacyjnych z czerwonymi, żółtymi i zielonymi wskaźnikami do oceny statusu CI/CD, aby zrozumieć, czy wszystko robią poprawnie, czy 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. Przeanalizuj, jakie dane są potrzebne wszystkim, a następnie stwórz ustandaryzowany opis tego, co one oznaczają. Dowiedz się, co ma większy sens dla interesariuszy: wykresy, tekst czy liczby.
Brak ręcznych testów
Automatyzacja testów kładzie fundamenty dla dobrego pipeline'u CI/CD. Ale automatyczne testowanie na wszystkich etapach nie oznacza, że nie powinieneś przeprowadzać testów manualnych.
Aby zbudować efektywny pipeline CI/CD, potrzebne są również testy manualne. Zawsze będą pewne aspekty testowania, które wymagają analizy przez człowieka.
Warto pomyśleć o integracji wysiłków związanych z testowaniem manualnym w pipeline. Po zakończeniu ręcznych testów niektórych przypadków testowych możesz przejść do etapu wdrażania.
Nie próbuj poprawiać testów
Efektywny pipeline CI/CD wymaga dostępu do odpowiednich narzędzi, niezależnie od tego, czy chodzi o zarządzanie testami, integrację czy ciągły monitoring.
Budowanie silnej kultury skoncentrowanej na jakości ma na celu , monitorowanie interakcji z klientami po wdrożeniu i śledzenie usprawnień.
Oto kilka praktycznych wskazówek, które możesz łatwo wdrożyć:
- Upewnij się, że testy są łatwe do napisania i wystarczająco elastyczne, aby nie psuły się przy refaktoryzacji kodu.
- Zespoły programistyczne powinny być zaangażowane w proces testowania — widzieć listę problemów i próśb użytkowników, które są ważne do weryfikacji podczas pipeline'ów CI.
- Możesz nie mieć pełnego pokrycia testami, ale zawsze dbaj, aby strumienie kluczowe dla UX i interakcji z klientami były testowane.
Ostatni, ale nie mniej ważny punkt
Przejście do CI/CD zazwyczaj jest inicjowane oddolnie, ale w końcu jest to transformacja, która wymaga zaangażowania kierownictwa, czasu i zasobów ze strony firmy. W końcu CI/CD to zestaw umiejętności, procesów, narzędzi oraz przekształcenie kulturowe, które można wprowadzić tylko systemowo.
Co jeszcze przeczytać na ten temat:
- .
- .
- .
Źródło: habr.com
