Jak NIE stosować nowych narzędzi do ciągłej integracji: spis treści
Zwinna integracja ciągła - krótka historia
Testowanie kontraktów to hasło pojawiające się w wielu dyskusjach, wywiadach i negocjacjach, które dotarły nawet do świadomości biznesowej. Stosowanie kontraktów gwarantuje, że zarówno frontend, jak i backend mówią tym samym językiem, co w rezultacie pomaga programistom dzielić między sobą oczekiwany projekt API.
Być może niektórzy z Was pamiętają, że w jednym z naszych projektów zdecydowaliśmy się użyć testów kontraktowych. Chcieliśmy sprawdzić, czy jest to dobre narzędzie do zarządzania umowami między zespołami frontendowymi i backendowymi. Mój poprzedni post(Consumer Driven Contract Testing) opisywał jak zrobiliśmy to z plikami PACT bez użycia PACT Brokera.
Rozwój był łatwy w utrzymaniu, ponieważ wszystko opierało się na zarządzanym przez Jenkinsa przesyłaniu kontraktów z FE do repozytorium BE.
Rok później zakończyliśmy kolejny projekt, ale był on nieco inny - korzystaliśmy z PACT Broker.
Nie będzie to post o samym PACT Brokerze. Ta lekcja pokazuje, że wybór odpowiedniego narzędzia powinien być przetestowany w konkretnym urządzeniu, ponieważ konsekwencje mogą spowodować drastyczne spowolnienie procesu rozwoju.
Przepływ
We wspomnianym poście napisałem, że PACT Broker może być lepszym rozwiązaniem niż nasze podejście git do udostępniania kontraktów PACT i integracji z CI.
Skonfigurowaliśmy PACT Broker i zaczęliśmy stosować go w naszym przepływie CI. Naszym celem było udostępnienie kontraktów nawet dla gałęzi, abyśmy mogli przetestować zmiany backendu i frontendu przed scaleniem ich do wersji master oddział.
Na początku byliśmy absolutnie pewni, że PACT Broker spełni nasze wymagania. Oferuje on tagowanie snapshotów, którymi chcieliśmy oznaczać gałęzie. Teoretycznie było to idealne rozwiązanie.
Nasze tagi były oparte na nazwie gałęzi - frontend developer generował gałąź zaczynającą się od pact po którym następuje ukośnik i nazwa zadania (tj. pact/JIRA_TASK-12), a następnie po przygotowaniu kontraktu został on wypełniony przez Jenkinsa do brokera z tagiem.
Po tym, jak skrypt Jenkinsa utworzył gałąź na backendowym repo, zadanie gradle pobrało oznaczony kontrakt z PACT Broker, dzięki czemu programista BE mógł zaimplementować odpowiednie API.
Przed scaleniem wykonano zadanie Jenkinsa, które sprawdzało, czy testy kontraktu działają. Jeśli tak, gałęzie BE i FE były scalane.
Niektóre rzeczy mogą wyglądać na prostsze niż są w rzeczywistości...
Wszystko było w porządku, dopóki w gitlab nie pojawiły się dwa żądania scalenia.
Kiedy aplikacja była intensywnie rozwijana, doświadczyliśmy ogromnego przestoju, ponieważ było wiele zmian w tym samym pliku PACT (ale w różnych kontraktach). Było to frustrujące dla nas wszystkich, ponieważ spędzaliśmy zbyt dużo czasu na utrzymywaniu problemów z kontraktami na CI.
Co się stało? Wyobraźmy sobie, że istnieją dwie funkcje, które wymagają zmian w tym samym pliku PACT, ale w różnych kontraktach na zasoby.
- Istnieją dwie gałęzie frontendu (
pact/TASK_1orazpact/TASK_2), które realizują różne kontrakty. - Są one przesyłane do brokera z odpowiednimi znacznikami (
pact/TASK_1orazpact/TASK_2) - Programiści backendu (na własną rękę
pact/TASK_1orazpact/TASK_2) opracowują zmiany, a po zakończeniu pracy otwierają prośby o scalenie. pact/TASK_1gałąź została sprawdzona i scalona (wszystkie zadania jenkins zakończyły się sukcesem) z gałęziąmaster.pact/TASK-2jest również w porządku (wszystkie zadania jenkinsa zakończyły się sukcesem), więc jest on scalany zmaster.
Co jest nie tak z przepływem integracji narzędzi Agile?
Aktualny master gałąź nie zostanie pomyślnie zbudowana, ponieważ najnowszy scalony kontrakt (z pact/TASK-2) nie została uznana za zawierającą zmiany w stosunku do pierwszej (pact/TASK-1), ale baza kodu zawierała zmiany dla obu funkcji.
Nie jest możliwe ponowne bazowanie kontraktów w PACT Broker, więc nie byliśmy w stanie tego łatwo naprawić! Jedynym sposobem na rozwiązanie tego problemu było wygenerowanie nowego tagu ze wszystkimi zmianami i ustawienie go dla backendu na master.
Szybkie rozwiązanie
Nie mieliśmy czasu na poprawki przepływu. Wszystko było w porządku w bazie kodu. Oba kontrakty były w porządku. Wszystko było poprawnie zbudowane na obu gałęziach. Jedynym problemem było to, że przepływ nie uwzględniał przypadku brzegowego, który doprowadził nas do ogromnego spowolnienia.
Dostawa została spowolniona, ponieważ musieliśmy ręcznie naprawić błąd.
Nie mogliśmy sobie pozwolić na opóźnienia, więc potrzebowaliśmy szybkiego rozwiązania. Na szczęście oba zespoły znajdowały się w jednym biurze i zgodziliśmy się wyłączyć kontrolę. Kontynuowaliśmy pisanie paktów i przeprowadzanie testów lokalnie.
Wnioski
Nasze obserwacje doprowadziły nas do następujących wniosków:
- Błędy w przepływach CI mogą mieć poważny wpływ na rozwój.
- Jeśli zamierzasz przygotować nowy przepływ CI i chcesz przetestować nowe narzędzie/rozwiązanie, zastanów się, czy masz wystarczająco dużo czasu na jego przywrócenie.
- Mieć plan powrotu.
- Dokładnie sprawdź funkcje narzędzia, którego chcesz użyć. W naszym przypadku PACT wraz z spring-cloud-contract okazały się dojrzałe, ale PACT Broker już nie - napotkaliśmy wiele mniejszych problemów, o których nie wspomniałem, np. problemy z adresami URL, które nie działały dla klienta REST.
Chcesz porozmawiać z naszymi ekspertami o narzędziach ciągłej integracji w Agile lub rozwiązaniach technologicznych dla Twojej firmy?
P: Czym są testy kontraktowe?
Testowanie kontraktów to metoda, która gwarantuje, że zarówno kod frontendowy, jak i backendowy mówią tym samym językiem, poprzez tworzenie kontraktów, które definiują oczekiwany projekt API.
P: Dlaczego warto korzystać z testów kontraktowych w ramach zwinnej ciągłej integracji?
Testowanie kontraktowe pomaga zarządzać kontraktami między zespołami frontendowymi i backendowymi i może ułatwić utrzymanie rozwoju.
P: Czym jest PACT Broker?
PACT Broker to narzędzie, które umożliwia udostępnianie kontraktów PACT i integrację z CI (Continuous Integration) w celu testowania kontraktów.
