Automatyzacja testów i proces dostarczania

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, dostarczania i wdrażania. Te praktyki są zwykle tworzone w tej kolejności, a każda z nich rozszerza poprzednią.

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 jest często nazywane potokiem. Pozostała część tej jednostki koncentruje 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ć, jak się wpisuje w pipeline 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 łańcuchu dostaw:

Przeprowadź analizę tej ścieżki krok po kroku:

• Instancja potoku uruchamia się po zatwierdzeniu zmian w kodzie lub infrastrukturze w repozytorium kodu, prawdopodobnie przy użyciu pull requesta.

• Następnie testy jednostkowe są uruchamiane, często po których następuje integracja lub kompleksowe testy. Wyniki są przekazywane do dewelopera, który otworzył pull request.

• Na tym etapie kod w repozytorium jest często skanowany pod kątem wpisów tajnych, luk w zabezpieczeniach i błędó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. Recenzent może zostać powiadomiony o nowym wdrożeniu, aby mógł zbadać rozwiązanie przedprodukcyjne. Następnie recenzent zatwierdza lub odmawia wdrożenia do środowiska produkcyjnego, co rozpoczyna ostatnią część procesu wdrażania, która dostarcza kod do środowiska produkcyjnego.

W tym pipeline można zauważyć podział między integracją a wdrożeniem. Wyróżnione znaczniki wskazują niektóre logiczne miejsca, w których można zatrzymać potok za pomocą dołączonej logiki i automatyzacji, a nawet potencjalnie nawet interwencji człowieka.

Narzędzia do ciągłej integracji i dostarczania: Azure Pipelines i GitHub Actions

Aby korzystać z ciągłej integracji i ciągłego dostarczania, potrzebne są odpowiednie narzędzia. Microsoft oferuje dwie opcje ciągłej integracji/ciągłego wdrażania pierwszej strony na potrzeby kompilowania i wdrażania w Azure: Azure Pipelines (część Azure DevOps) i GitHub Actions. Obie metody mogą automatyzować kompilowanie i spójne testowanie kodu, a oba mogą być wdrażane w Azure usługach, maszynach wirtualnych i innych obiektach docelowych w chmurze i lokalnie. Wiele zespołów przyjmuje GitHub Actions, gdy ich kod źródłowy już istnieje w GitHub, podczas gdy Azure Pipelines pozostaje zdecydowanym wyborem dla zespołów ustandaryzowanych na Azure DevOps.

W pozostałej części tej lekcji skupiono się na Azure Pipelines, ale GitHub Actions używa podobnych koncepcji wysokiego poziomu, mimo że terminologia się różni. W GitHub Actions przepływy pracy zawierają zadania i kroki, akcje stanowią pakiety automatyzacji wielokrotnego użytku, uruchamiacze wykonują pracę, a środowiska mogą chronić wdrożenia.

Dane wejściowe potoku (kod lub konfiguracje) znajdują się w systemie kontroli wersji, takim jak GitHub lub inny dostawca usługi Git.

Azure Pipelines działa na zasobach obliczeniowych, takich jak maszyny wirtualne lub kontenery, i oferuje agentów kompilacji hostowanych przez Microsoft, działających na systemach Windows, Linux i macOS. Możesz również zarejestrować własnych agentów, gdy potrzebujesz pełnej kontroli nad środowiskiem kompilacji. 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 Azure Pipelines.

Potoki są definiowane przy użyciu składni YAML, przechowywanej wraz z kodem w repozytorium Git. Potoki YAML to zalecane podejście do nowych projektów. Klasyczny interfejs użytkownika w Azure DevOps jest również dostępny dla starszych potoków, ale większość nowych funkcji (w tym zadań kontenera i wiele zaawansowanych funkcji) jest dostępna tylko w języku YAML. Potoki udostępniają również szablony, których można użyć do łatwego tworzenia potoków, takich jak szablon obrazu platformy Docker lub projektu Node.js. Możesz również użyć ponownie istniejącego pliku YAML.

Podstawowe kroki konfigurowania rury to:

1. Skonfiguruj Azure Pipelines do korzystania z repozytorium Git.
2. Zdefiniuj kompilację, edytując plik azure-pipelines.yml (lub w przypadku starszych potoków przy użyciu edytora klasycznego).
3. Prześlij kod do repozytorium kontroli wersji. Ta akcja uruchamia rurę do budowania i testowania Twojego kodu.

Po zaktualizowaniu, skompilowaniu i przetestowaniu kodu można wdrożyć go w dowolnym miejscu docelowym.

konstrukcja potoku 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 element pracy, który można zaplanować do uruchomienia. Wszystkie kroki zadania są uruchamiane kolejno. Te kroki mogą być dowolnym potrzebnym działaniem, w tym budowaniem lub kompilowaniem oprogramowania, przygotowywaniem przykładowych danych do testowania, wykonywaniem określonych testów itp.

• Etapy: etap to logiczne grupowanie powiązanych zadań.

Każdy pipeline ma co najmniej jeden etap. Użyj wielu etapów, aby podzielić przepływ pracy na główne części i oznaczyć miejsca, w których można zatrzymać przepływ i przeprowadzić kontrole.

Pipeliny mogą być zarówno proste, jak i złożone, w zależności od potrzeb. Aby zapoznać się z samouczkami dotyczącymi tworzenia i używania potoków, zobacz ścieżkę szkoleniową Tworzenie aplikacji z Azure DevOps.

Śledzenie środowiska

Istnieje jeszcze jeden aspekt potoków związanych z niezawodnością, o którym warto wspomnieć. Możesz skonstruować swoje potoki w taki sposób, aby możliwe było skorelowanie procesów działających w środowisku produkcyjnym z konkretną instancją budowania. W idealnym przypadku powinno być możliwe śledzenie kompilacji z powrotem do określonego żądania ściągnięcia lub zmiany kodu. Ta możliwość śledzenia jest bezcenna podczas zdarzenia, a następnie podczas przeglądu po zdarzeniu podczas próby zidentyfikowania, która zmiana przyczyniła się do wystąpienia problemu. Niektóre systemy CI/CD (np. Azure Pipelines i GitHub Actions) sprawiają, że ta korelacja jest prosta, podczas gdy inne wymagają ręcznego zbudowania potoku, który propaguje identyfikator kompilacji przez każdy etap.