Automatyzacja testów i potok dostarczania
- 5 min
Wiesz już o ciągłym wdrażaniu i dostarczaniu oprogramowania i usług, ale te dwa są faktycznie częścią triady. Metodyki DevOps mają na celu osiągnięcie ciągłej integracji, wdrażania i dostarczania.
Teraz nadszedł czas, aby utworzyć kopię zapasową i omówić pierwszą z następujących kwestii: integracja. Jest to część procesu opracowywania następująca przed wdrożeniem. Metodyka DevOps zaleca stosowanie rozwiązań programistycznych, w ramach których członkowie zespołu często integrują kod we współużytkowanym repozytorium zawierającym pojedynczą, główną bazę kodu. Celem jest, aby każdy współtworzył kod, który zostanie dostarczony, w przeciwieństwie do pracy nad własną kopią i scalania wszystkiego w całość na ostatnią chwilę.
Testowanie automatyczne może następnie zweryfikować integrację każdego członka zespołu. Testowanie ułatwia określenie, czy kod jest „zdrowy” po każdej zmianie i wprowadzeniu dodatkowych elementów. Testowanie jest częścią tego, co nazywamy potokiem. Omówimy potoki za chwilę, ponieważ w tej lekcji skupimy się na zintegrowanych potokach testowania i dostarczania.
Potok ciągłego dostarczania
Aby zrozumieć rolę zautomatyzowanego testowania w modelu ciągłego wdrażania, należy sprawdzić, gdzie pasuje do potoku dostarczania. Potok ciągłego dostarczania to implementacja zestawu kroków, przez które przechodzi kod w toku wprowadzania zmian w ramach procesu opracowywania przed wdrożeniem go w środowisku produkcyjnym. Oto graficzna reprezentacja przykładowych kroków w uproszczonym potoku dostarczania:
Przejdźmy przez ten potok krok po kroku.
Wystąpienie potoku zaczyna się od zatwierdzenia zmian w kodzie lub infrastrukturze w repozytorium kodu, prawdopodobnie przy użyciu żądania ściągnięcia.
Następnie testy jednostkowe są uruchamiane — na przykład integracja lub kompleksowe testy — i w idealnym przypadku te wyniki testów są przekazywane z powrotem do strony żądającej.
Być może w tym momencie kod w repozytorium jest skanowany pod kątem wpisów tajnych, luk w zabezpieczeniach i aspektów konfiguracji.
Gdy wszystkie kontrole zostaną zakończone pomyślnie, kod jest kompilowany i przygotowywany do wdrożenia.
Następnie kod jest wdrażany w środowisku testowym. Użytkownik może otrzymać powiadomienie o nowym wdrożeniu, aby przyjrzeć się rozwiązaniu w fazie przedprodukcyjnej. Ta osoba może wtedy zatwierdzić lub odrzucić wdrożenie do środowiska produkcyjnego, co rozpoczyna ostatnią część procesu wdrażania, która publikuje kod w środowisku produkcyjnym.
W tym potoku można zanotować podział między integracją a wdrożeniem. Czerwone znaczniki wskazują niektóre logiczne miejsca, w których można zatrzymać potok za pomocą zawartej logiki i automatyzacji, a nawet interwencji człowieka.
Narzędzia do ciągłej integracji i dostarczania: Azure Pipelines
Aby korzystać z ciągłej integracji i ciągłego dostarczania, potrzebne są odpowiednie narzędzia. Usługa Azure Pipelines jest częścią usługi Azure DevOps Services, która pozwala na zautomatyzowane kompilowanie i spójne testowanie kodu. Usługa Azure Pipelines pozwala też na wdrożenie kodu w ramach usług platformy Azure, na maszynach wirtualnych i w innych miejscach docelowych zarówno w chmurze, jak i lokalnie.
Dane wejściowe potoku (nasz kod lub konfiguracje) znajdują się w systemie kontroli wersji, takim jak GitHub lub inny dostawca usługi Git.
Usługa Azure Pipelines działa w ramach zasobu obliczeniowego, takiego jak maszyna wirtualna lub kontener, i oferuje agentów kompilacji uruchomionych w systemach Windows, Linux i macOS. Oferuje również integrację z wtyczkami do testowania, zabezpieczeń i jakości kodu. Na koniec można go łatwo rozszerzać, dzięki czemu możesz wprowadzić własną automatyzację do usługi Azure Pipelines.
Potoki definiuje się przy użyciu składni YAML lub za pośrednictwem klasycznego interfejsu użytkownika w witrynie Azure Portal. W przypadku pliku YAML można przechowywać ten plik razem z kodem. Potoki udostępniają również szablony, których można użyć do łatwego tworzenia potoków; na przykład potok, który kompiluje obraz platformy Docker lub projekt Node.js. Możesz również użyć ponownie istniejącego pliku YAML.
Niezależnie od tego, czy używasz pliku YAML, czy interfejsu klasycznego, oto podstawowe kroki:
- Konfigurowanie usługi Azure Pipelines pod kątem użycia repozytorium Git.
- Zdefiniuj kompilację, edytując plik azure-pipelines.yml lub przy użyciu edytora klasycznego.
- Wypchnij kod do repozytorium kontroli wersji. Ta akcja wyzwala potok w celu skompilowania i przetestowania kodu.
Po zaktualizowaniu, skompilowaniu i przetestowaniu kodu można wdrożyć go w dowolnym miejscu docelowym.
Istnieją pewne funkcje (takie jak uruchamianie zadań kontenera), które są dostępne tylko w przypadku korzystania z języka YAML, a inne (takie jak grupy zadań), które są dostępne tylko przy użyciu interfejsu klasycznego.
Konstrukcja potoku platformy Azure
Potoki są zorganizowane za pomocą następujących elementów:
Zadania: zadanie to grupowanie zadań lub kroków uruchamianych na jednym agencie kompilacji. Zadanie to najmniejszy składnik pracy, którego uruchomienie można zaplanować. Wszystkie kroki zadania są uruchamiane kolejno. Te kroki mogą być dowolnym rodzajem akcji, w tym kompilowaniem/kompilowaniem oprogramowania, przygotowywaniem przykładowych danych do testowania, uruchamianiem określonych testów itd.
Etapy: etap to logiczne grupowanie powiązanych zadań.
Każdy potok ma co najmniej jeden etap. Użyj wielu etapów, aby podzielić potok na główne części i oznaczyć punkty w potoku, w których można go wstrzymać i wykonać sprawdzenia.
Potoki mogą być tak proste lub tak złożone, jak wymagają tego potrzeby. Istnieją doskonałe samouczki dotyczące budowy i używania potoków w ścieżce nauczania Tworzenie aplikacji za pomocą usługi Azure DevOps.
Śledzenie środowiska
Istnieje jeszcze jeden aspekt potoków związanych z niezawodnością, o których warto wspomnieć. Potoki można skonstruować w taki sposób, aby można było skorelować działanie w środowisku produkcyjnym z konkretnym wystąpieniem kompilacji. W idealnym przypadku powinno być możliwe śledzenie kompilacji z powrotem do określonego żądania ściągnięcia lub zmiany kodu. Może to być niezwykle przydatne podczas zdarzenia lub później podczas przeglądu po zdarzeniu, gdy próbujesz zidentyfikować, która zmiana przyczyniła się do problemu. Niektóre systemy ciągłej integracji/ciągłego wdrażania (takie jak Azure Pipelines) ułatwiają to wykonywanie, podczas gdy inne wymagają ręcznego konstruowania potoku, który propaguje jakiś "identyfikator kompilacji" przez wszystkie etapy.