Jak skonfigurować ciągłą integrację
Dowiedz się, jak w 5 krokach wdrożyć ciągłą integrację i zautomatyzowane testowanie.
Sten Pittet
Autor współpracujący
Ciągła integracja (CI) to najlepsza praktyka Agile i DevOps, w ramach której programiści wcześnie i często integrują zmiany kodu z gałęzią główną lub repozytorium kodu. Celem jest zmniejszenie ryzyka wystąpienia problemów z integracją poprzez czekanie ze scaleniem pracy wszystkich programistów do końca projektu lub sprintu. Proces ten automatyzuje wdrażanie, dzięki czemu pomaga zespołom spełnić wymagania biznesowe, poprawić jakość kodu i zwiększyć bezpieczeństwo.
Jedną z głównych korzyści z przyjęcia CI jest zaoszczędzenie czasu podczas cyklu tworzenia oprogramowania poprzez wczesne identyfikowanie i rozwiązywanie konfliktów. Jest to również świetny sposób na zmniejszenie ilości czasu spędzanego na naprawianiu błędów i regresji poprzez położenie większego nacisku na stworzenie dobrego zestawu testów. CI pomaga również w lepszym zrozumieniu bazy kodu i funkcji, które opracowujesz dla swoich klientów.
Pierwszy krok na drodze do ciągłej integracji: skonfigurowanie zautomatyzowanych testów.
Rozpoczęcie korzystania ze zautomatyzowanych testów
Zrozumienie różnych rodzajów testów
Jeśli chcesz w pełni wykorzystać możliwości CI, musisz zautomatyzować testy, aby można było je uruchamiać przy każdej zmianie wprowadzanej do głównego repozytorium. Testy trzeba przeprowadzać w każdej gałęzi repozytorium, a nie tylko w głównej. W ten sposób można wcześnie wychwycić problemy i zminimalizować zakłócenia w pracy zespołu.
Istnieje wiele rodzajów testów, ale nie musisz robić wszystkiego naraz, jeśli dopiero zaczynasz. Możesz zacząć od prostych testów jednostkowych i konsekwentnie pracować nad zwiększeniem pokrycia.
- Testy jednostkowe mają wąski zakres i zazwyczaj weryfikują zachowanie poszczególnych metod lub funkcji.
- Testy integracyjne pozwalają upewnić się, że wiele komponentów zachowuje się razem poprawnie. Mogą one obejmować kilka klas, a także testowanie integracji z innymi usługami.
- Testy akceptacyjne są podobne do testów integracyjnych, ale skupiają się na uzasadnieniach biznesowych, a nie na samych komponentach.
- Testy interfejsu użytkownika pozwolą upewnić się, że aplikacja działa poprawnie z perspektywy użytkownika.
Poznaj rozwiązanie
Tworzenie i obsługa oprogramowania za pomocą Open DevOps
Materiały pokrewne
Więcej o zautomatyzowanym testowaniu
Nie wszystkie testy są równe. Możesz zwizualizować kompromisy związane z ich poszczególnymi rodzajami, korzystając z piramidy testów opracowanej przez Mike'a Cohna.
Testy jednostkowe są szybkie i tanie do wdrożenia, ponieważ w większości przypadków sprawdzają małe fragmenty kodu. Z drugiej strony testy interfejsu użytkownika będą skomplikowane do wdrożenia, a ich przeprowadzenie zajmie sporo czasu, ponieważ często wymagają uruchomienia pełnego środowiska, jak również wielu usług emulujących zachowania przeglądarki lub urządzeń mobilnych. Z tego powodu warto ograniczyć liczbę złożonych testów interfejsu użytkownika i polegać na dobrych testach jednostkowych u podstaw — pozwalają one uzyskać szybką kompilację i błyskawicznie przekazywać informacje zwrotne programistom.
Automatyczne uruchamianie testów
Aby wdrożyć ciągłą integrację, należy uruchamiać testy w przypadku każdej zmiany wypychanej z powrotem do gałęzi głównej. Potrzebna jest do tego usługa, która może monitorować repozytorium i nowe wypchnięcia do bazy kodu. Istnieje wiele takich rozwiązań — zarówno lokalnych, jak i chmurowych. Przy wyborze serwera należy wziąć pod uwagę następujące kwestie:
- Gdzie jest hostowany Twój kod? Czy usługa CI ma dostęp do Twojej bazy kodu? Czy istnieją jakieś specjalne ograniczenia dotyczące tego, gdzie można umieścić kod?
- Jakiego systemu operacyjnego i jakich zasobów potrzebujesz dla swojej aplikacji? Czy środowisko Twojej aplikacji jest obsługiwane? Czy możesz zainstalować odpowiednie zależności, które pozwolą Ci stworzyć i przetestować oprogramowanie?
- Ile zasobów potrzebujesz do swoich testów? Niektóre aplikacje chmurowe mogą mieć ograniczenia dotyczące zasobów, z których można korzystać. Jeśli Twoje oprogramowanie zużywa dużo zasobów, być może warto umieścić serwer CI za zaporą sieciową.
- Ilu programistów wchodzi w skład Twojego zespołu? Kiedy zespół korzysta z procesu CI, każdego dnia wiele zmian jest wypychanych z powrotem do głównego repozytorium. Aby programiści mogli szybko uzyskiwać informacje zwrotne, musisz skrócić czas oczekiwania kompilacji, a także korzystać z usługi lub serwera, który zapewnia współbieżność.
W przeszłości zazwyczaj trzeba było zainstalować oddzielny serwer CI, taki jak Bamboo lub Jenkins, ale teraz można znaleźć rozwiązania chmurowe, które są znacznie prostsze do wdrożenia. Na przykład jeśli Twój kod jest hostowany w Bitbucket Cloud, możesz użyć funkcji Pipelines w swoim repozytorium, aby uruchamiać testy przy każdym wypchnięciu bez potrzeby konfigurowania oddzielnego serwera lub agentów kompilacji i bez ograniczeń dotyczących współbieżności.
image: node:4.6.0 pipelines: default: - step: script: - npm install - npm testPrzykład konfiguracji umożliwiającej testowanie repozytorium JavaScript za pomocą Bitbucket Pipelines.
Użyj pokrycia kodu, aby znaleźć nieprzetestowany kod
Kiedy wprowadzisz już zautomatyzowane testowanie, dobrym pomysłem jest połączenie go z narzędziem do obliczania pokrycia testami, które da Ci pojęcie o tym, jak duża część Twojej bazy kodu jest pokryta przez Twój zestaw testów.
Dobrze jest dążyć do pokrycia na poziomie powyżej 80%, ale trzeba uważać, żeby nie pomylić wysokiego procentu pokrycia z dobrym zestawem testów. Narzędzie do obliczania pokrycia kodu pomoże Ci znaleźć nieprzetestowany kod, ale ostatecznie to jakość Twoich testów zrobi różnicę.
Jeśli dopiero zaczynasz, nie spiesz się z osiągnięciem 100% pokrycia swojej bazy kodu. Zamiast tego skorzystaj z narzędzia do obliczania pokrycia testami, aby znaleźć krytyczne części aplikacji, w przypadku których nie wprowadzono jeszcze testów, i zacznij od nich.
Refaktoryzacja jest okazją do dodania testów
Jeśli zamierzasz wprowadzić znaczące zmiany w swojej aplikacji, zacznij od napisania testów akceptacyjnych dotyczących funkcji, które mogą zostać dotknięte tymi zmianami. Dzięki temu upewnisz się, że oryginalne zachowanie nie zmieniło się po refaktoryzacji kodu ani dodaniu nowych funkcji.
Czynniki krytyczne dla powodzenia przy wdrażaniu ciągłej integracji
Automatyzacja testów jest kluczową częścią CI, ale sama w sobie nie jest wystarczająca. Być może trzeba będzie zmienić kulturę zespołu, tak aby programiści nie pracowali przez wiele dni nad daną funkcją bez scalania swoich zmian z gałęzią główną, a także promować kulturę „zielonej kompilacji”.
Dokonuj integracji wcześnie i często
Niezależnie od tego, czy używasz modelu tworzenia oprogramowania opartego o gałąź główną, czy gałęzi funkcji, ważne jest, aby programiści integrowali swoje zmiany z głównym repozytorium tak szybko, jak to możliwe. Jeśli pozwolisz, żeby kod zbyt długo znajdował się w danej gałęzi lub na stacji roboczej programisty, narazisz się na ryzyko wystąpienia zbyt wielu konfliktów, na które trzeba będzie zwrócić uwagę, gdy zdecydujesz się scalić wszystko z gałęzią główną.
Poprzez wczesną integrację zmniejszasz zakres zmian, co ułatwia zrozumienie występujących konfliktów. Kolejną zaletą jest ułatwienie dzielenia się wiedzą pomiędzy programistami, ponieważ zmiany są bardziej przyswajalne.
Jeśli stwierdzisz, że wprowadzane zmiany mogą mieć wpływ na istniejącą funkcję, możesz użyć flag funkcji, aby wyłączyć zmiany na etapie produkcji do czasu zakończenia pracy.
Dbaj o to, by kompilacja przez cały czas była zielona
Jeśli programista uszkodzi kompilację gałęzi głównej, jej naprawienie staje się głównym priorytetem. Im więcej zmian dostanie się do kompilacji, gdy jest uszkodzona, tym trudniej będzie Ci zrozumieć przyczynę problemu — ponadto pojawia się ryzyko wystąpienia większej liczby awarii.
Warto poświęcić czas na dopracowanie zestawu testów, żeby upewnić się, że może on szybko skończyć się niepowodzeniem i jak najszybciej przekazać informacje zwrotne programiście, który wypchnął zmiany. Możesz podzielić testy tak, aby te szybkie (na przykład jednostkowe) były uruchamiane przed testami, które trwają długo. Jeśli Twój zestaw testów zawsze trwa długo, zanim skończy się niepowodzeniem, zmarnujesz dużo czasu programistów, ponieważ będą musieli przełączyć kontekst, aby wrócić do swojej poprzedniej pracy i ją naprawić.
Nie zapomnij ustawić powiadomień, aby upewnić się, że programiści są powiadamiani o uszkodzeniu kompilacji. Możesz również pójść o krok dalej, wyświetlając stan swoich gałęzi głównych na pulpicie, gdzie każdy może go zobaczyć.
Pisz testy jako część swoich historyjek
Wreszcie musisz upewnić się, że w przypadku każdej rozwijanej funkcji wykonywane są zautomatyzowane testy. Może się wydawać, że spowolnią one proces rozwoju, ale w rzeczywistości drastycznie zmniejszą ilość czasu, który Twój zespół spędza na naprawianiu regresji lub błędów wprowadzonych w każdej iteracji. Będzie można również bez obaw wprowadzać zmiany w bazie kodu, ponieważ zestaw testów pozwoli szybko sprawdzić, czy wszystkie wcześniej opracowane funkcje działają zgodnie z oczekiwaniami.
Aby napisać dobre testy, musisz upewnić się, że programiści zostaną wcześnie zaangażowani w definiowanie historyjek użytkownika. Jest to doskonały sposób, aby uzyskać lepsze wspólne zrozumienie wymagań biznesowych i ułatwić relacje z menedżerami produktów. Możesz nawet zacząć od napisania testów przed wdrożeniem kodu, który je wykona.
Pisz testy podczas naprawiania błędów
Niezależnie od tego, czy masz już istniejącą bazę kodu, czy dopiero zaczynasz ją tworzyć, w Twoich wydaniach z pewnością pojawią się błędy. Upewnij się, że w czasie ich naprawiania dodajesz testy, aby zapobiec ich ponownemu wystąpieniu.
CI umożliwi inżynierom QA skalowanie jakości
Kolejną rolą, która zmieni się wraz z wdrożeniem CI i automatyzacji, jest rola inżynierów QA. Nie muszą już testować ręcznie trywialnych możliwości aplikacji i mogą teraz poświęcić więcej czasu na dostarczanie narzędzi wspierających programistów, jak również pomagać im we wprowadzaniu właściwych strategii testowania.
Kiedy zaczniesz wdrażać ciągłą integrację, Twoi inżynierowie QA będą mogli skupić się na ułatwieniu testowania poprzez zastosowanie lepszych narzędzi i zestawów danych, jak również pomóc programistom w rozwoju umiejętności pisania kodu. W przypadku złożonych przypadków użycia nadal będą wymagane testy eksploracyjne, ale powinna to być mniej widoczna część ich pracy.
Konfiguracja ciągłej integracji w 5 krokach
Po zapoznaniu się z powyższymi informacjami masz już dobre pojęcie o koncepcji ciągłej integracji. Wszystko możemy sprowadzić do poniższych punktów:
- Zacznij pisać testy pod kątem krytycznych części bazy kodu.
- Wprowadź usługę CI, która będzie uruchamiać te testy automatycznie przy każdym wypchnięciu do głównego repozytorium.
- Upewnij się, że Twój zespół codziennie integruje zmiany.
- Napraw kompilację, gdy tylko ulegnie ona uszkodzeniu.
- Pisz testy w przypadku każdej nowej historyjki, którą wdrażasz.
Choć może się to wydawać proste, będzie wymagało prawdziwego zaangażowania ze strony Twojego zespołu. Na początku konieczne będzie zwolnienie tempa wydań. Trzeba też uzyskać od product ownerów zapewnienie, że nie będą naciskać na programistów, aby ci wysyłali nieprzetestowane funkcje.
Zalecamy zacząć od prostych testów, które pozwolą przyzwyczaić się do nowej rutyny. Następnie można przejść do wdrożenia bardziej złożonego zestawu testów, który może być trudny do zarządzania.
Do nauki ciągłej integracji możesz wykorzystać Bitbucket Pipelines. A jeśli chcesz utworzyć łańcuch narzędzi DevOps, zapoznaj się z platformą Open DevOps, która zawiera integracje z wiodącymi dostawcami i aplikacjami ze sklepu Marketplace.
Udostępnij ten artykuł
Następny temat
Zalecane lektury
Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.
Społeczność DevOps
Przeczytaj blog
