Programowanie oparte na testach dla stref docelowych platformy Azure
Programowanie oparte na testach (TDD) to proces tworzenia oprogramowania i metodyki DevOps, który poprawia jakość nowych funkcji i ulepszeń rozwiązań opartych na kodzie. Funkcja TDD tworzy przypadki testów jednostkowych przed opracowaniem rzeczywistego kodu i testuje kod względem przypadków testowych. Takie podejście jest sprzeczne z tworzeniem kodu najpierw i tworzeniem przypadków testowych później.
Strefa docelowa to środowisko do hostowania obciążeń, które są wstępnie aprowidowane za pomocą kodu. Strefy docelowe obejmują podstawowe możliwości, które korzystają ze zdefiniowanego zestawu usług w chmurze i najlepszych rozwiązań. W tym artykule opisano podejście, które używa TDD do wdrażania udanych stref docelowych przy jednoczesnym spełnieniu wymagań dotyczących jakości, zabezpieczeń, operacji i ładu.
Infrastruktura chmury to dane wyjściowe wykonywania kodu. Dobrze ustrukturyzowany, przetestowany i zweryfikowany kod tworzy opłacalną strefę docelową. Infrastruktura oparta na chmurze i jego podstawowy kod źródłowy mogą użyć tego podejścia, aby zapewnić wysoką jakość stref docelowych i spełnić podstawowe wymagania.
Użyj tego podejścia, aby spełnić proste żądania funkcji podczas wczesnego opracowywania. W dalszej części cyklu życia wdrażania chmury można użyć tego procesu, aby spełnić wymagania dotyczące zabezpieczeń, operacji, ładu lub zgodności. Ten proces jest szczególnie przydatny w przypadku tworzenia i refaktoryzacji stref docelowych w ramach równoległego programowania.
Cykl programowania sterowany testami
Na poniższym diagramie przedstawiono cykl programowania opartego na testach dla stref docelowych platformy Azure:
Utwórz test. Zdefiniuj test, aby sprawdzić, czy kryteria akceptacji funkcji zostały spełnione. Zautomatyzuj test podczas opracowywania, aby zmniejszyć ilość ręcznego nakładu pracy testowej, szczególnie w przypadku wdrożeń w skali przedsiębiorstwa.
Przetestuj strefę docelową. Uruchom nowy test i wszystkie istniejące testy. Jeśli wymagana funkcja nie jest uwzględniona w ofertach dostawcy usług w chmurze i nie została udostępniona przez wcześniejsze wysiłki programistyczne, test powinien zakończyć się niepowodzeniem. Uruchamianie istniejących testów pomaga sprawdzić, czy nowa funkcja lub test nie zmniejsza niezawodności istniejących funkcji strefy docelowej.
Rozwiń i refaktoryzuj strefę docelową. Dodaj lub zmodyfikuj kod źródłowy, aby spełnić żądaną funkcję dodawania wartości i poprawić ogólną jakość bazy kodu.
Aby spełnić kryteria TDD, zespół ds. platformy w chmurze doda kod tylko do spełnienia żądanej funkcji. Jednak jakość kodu i konserwacja są wspólne. W miarę wypełniania nowych żądań funkcji zespół ds. platformy w chmurze powinien spróbować poprawić kod, usuwając duplikaty i wyjaśniając kod. Uruchamianie testów między tworzeniem nowego kodu a refaktoryzowaniem kodu źródłowego jest zdecydowanie zalecane.
Wdróż strefę docelową. Gdy kod źródłowy spełnia żądanie funkcji, wdróż zmodyfikowaną strefę docelową u dostawcy chmury w kontrolowanym środowisku testowania lub piaskownicy.
Przetestuj strefę docelową. Ponownie przetestuj strefę docelową, aby sprawdzić, czy nowy kod spełnia kryteria akceptacji żądanej funkcji. Po zakończeniu wszystkich testów funkcja jest uznawana za ukończoną, a kryteria akceptacji są uznawane za spełnione.
Cykl TDD powtarza poprzednie podstawowe kroki, aż spełni pełną definicję wykonania. Gdy wszystkie funkcje dodane wartości i kryteria akceptacji przechodzą skojarzone testy, strefa docelowa jest gotowa do obsługi następnej fali planu wdrożenia chmury.
Cykl, który sprawia, że TDD skuteczny jest często określany jako czerwony/zielony test. W tym podejściu zespół ds. platformy w chmurze rozpoczyna się od testu, który zakończył się niepowodzeniem lub czerwony test, na podstawie definicji wykonanej i zdefiniowanych kryteriów akceptacji. Dla każdej funkcji lub kryteriów akceptacji zespół platformy w chmurze wykonuje zadania programistyczne do momentu ukończenia testu lub ma zielony test.
Celem TDD jest lepsze projektowanie, a nie tworzenie zestawu testów. Testy są cennym artefaktem do ukończenia procesu.
Definicja gotowości
Powodzenie może być subiektywną miarą, która zapewnia zespołowi platformy w chmurze niewielkie informacje umożliwiające podejmowanie działań podczas opracowywania lub refaktoryzacji strefy docelowej. Brak jasności może prowadzić do nieodebranych oczekiwań i luk w zabezpieczeniach w środowisku chmury. Zanim zespół ds. platformy w chmurze refaktoryzuje lub rozszerzy wszystkie strefy docelowe, powinny szukać jasności w zakresie definicji gotowej (DoD) dla każdej strefy docelowej.
DoD to prosta umowa między zespołem platformy w chmurze a innymi zespołami, których dotyczy problem, który definiuje oczekiwane funkcje dodane do wartości, które mają zostać uwzględnione w wysiłkach programistycznych strefy docelowej. DoD jest często listą kontrolną zgodną z krótkoterminowym planem wdrażania chmury.
Ponieważ zespoły przyjmują więcej obciążeń i funkcji w chmurze, doD i kryteria akceptacji stają się bardziej złożone. W dojrzałych procesach oczekiwane funkcje mają własne kryteria akceptacji, aby zapewnić większą przejrzystość. Gdy wszystkie funkcje dodane przez wartość spełniają kryteria akceptacji, strefa docelowa jest wystarczająco skonfigurowana, aby umożliwić powodzenie bieżącej fali wdrożenia lub wydania.
Prosty przykład doD
W przypadku początkowego nakładu pracy nad migracją doD może być nadmiernie proste. Poniższy przykład to prosty kod DoD:
Początkowa strefa docelowa będzie hostować 10 obciążeń na potrzeby uczenia początkowego. Te obciążenia nie mają krytycznego wpływu na firmę i nie mają dostępu do poufnych danych. W przyszłości te obciążenia prawdopodobnie zostaną wydane do środowiska produkcyjnego, ale nie oczekuje się, że zmieni się krytyczność i wrażliwość.
Aby obsługiwać te obciążenia, zespół wdrożeniowy ds. chmury musi spełnić następujące kryteria:
- Segmentacja sieci w celu dopasowania do proponowanego projektu sieci. To środowisko powinno być siecią obwodową z dostępem do publicznego Internetu.
- Dostęp do zasobów obliczeniowych, magazynu i sieci w celu hostowania obciążeń dopasowanych do odnajdywania majątku cyfrowego.
- Schemat nazewnictwa i tagowania w celu ułatwienia użycia.
- Podczas wdrażania tymczasowy dostęp do zespołu wdrożeniowego ds. chmury w celu zmiany konfiguracji usługi.
- Przed wydaniem produkcyjnym integracja z dostawcą tożsamości firmowej w celu zarządzania bieżącą tożsamością i dostępem do zarządzania operacjami. W tym czasie należy odwołać dostęp zespołu wdrożeniowego ds. chmury.
Ostatnim punktem nie jest kryterium funkcji ani akceptacji, ale wskaźnik, że będzie wymagana większa liczba rozszerzeń i powinna być wcześniej eksplorowana z innymi zespołami.
Bardziej złożone przykłady doD
Metodologia ładów w Cloud Adoption Framework zapewnia narrację poprzez naturalną dojrzałość zespołu ds. ładu. Osadzona w tej podróży to kilka przykładów kryteriów dod i akceptacji w formie instrukcji zasad.
Początkowe instrukcje zasad. Przykład początkowej usługi DoD opartej na zasadach firmy, które regulują wymagania dotyczące wdrażania na wczesnym etapie.
Ulepszenia przyrostowe w celu rozszerzenia zarządzania tożsamościami. Przykład zasad firmy zarządzających usługą DoD w celu spełnienia wymagań w celu rozszerzenia zarządzania tożsamościami dla strefy docelowej.
Ulepszenia przyrostowe w celu rozszerzenia wymagań dotyczących zabezpieczeń. Przykład zasad firmy zarządzających usługą DoD w celu spełnienia wymagań dotyczących zabezpieczeń dostosowanych do planu wdrażania chmury referencyjnej.
Ulepszenia przyrostowe w celu rozszerzenia zarządzania operacjami. Przykład zasad firmy zarządzających usługą DoD w celu spełnienia podstawowych wymagań dotyczących zarządzania operacjami.
Ulepszenia przyrostowe w celu rozszerzenia zarządzania kosztami. Przykład zasad firmy zarządzających usługą DoD w celu spełnienia wymagań dotyczących zarządzania kosztami.
Powyższe przykłady to podstawowe przykłady, które ułatwiają tworzenie witryny DoD dla stref docelowych. Możesz uzyskać przykładowe zasady dla każdej z pięciu dziedzin utrzymania ładu w chmurze.
Narzędzia i funkcje platformy Azure do obsługi TDD strefy docelowej
Na poniższym diagramie przedstawiono dostępne narzędzia programistyczne oparte na testach na platformie Azure:
Te narzędzia i funkcje platformy Azure można łatwo zintegrować z funkcją TDD na potrzeby tworzenia strefy docelowej. Narzędzia służą konkretnym celom, ułatwiając opracowywanie, testowanie i wdrażanie stref docelowych w sposób wyrównany do cykli TDD.
Usługa Azure Resource Manager zapewnia spójną platformę do procesów kompilacji i wdrażania. Platforma Resource Manager może wdrażać strefy docelowe na podstawie definicji kodu źródłowego.
Szablony usługi Azure Resource Manager (ARM) udostępniają podstawowy kod źródłowy dla środowisk wdrożonych na platformie Azure. Niektóre narzędzia innych firm, takie jak Terraform, udostępniają własne szablony usługi ARM do przesyłania do usługi Azure Resource Manager.
Szablony szybkiego startu platformy Azure udostępniają szablony kodu źródłowego, które pomagają przyspieszyć wdrażanie strefy docelowej i obciążenia.
Azure Policy zapewnia podstawowy mechanizm testowania kryteriów akceptacji w usłudze DoD. Azure Policy może również zapewnić automatyczne wykrywanie, ochronę i rozwiązywanie problemów, gdy wdrożenia odbiegają od zasad ładu.
W cyklu TDD można utworzyć definicję zasad, aby przetestować pojedyncze kryteria akceptacji. Azure Policy zawiera wbudowane definicje zasad, które mogą spełniać poszczególne kryteria akceptacji w doD. Takie podejście zapewnia mechanizm dla czerwonych testów przed zmodyfikowaniem strefy docelowej.
Azure Policy zawiera również wbudowane inicjatywy zasad, których można użyć do testowania i wymuszania pełnego identyfikatora DoD dla strefy docelowej. Wszystkie kryteria akceptacji można dodać do inicjatywy zasad przypisanej do całej subskrypcji. Gdy strefa docelowa spełnia usługę DoD, Azure Policy może wymusić kryteria testu, aby uniknąć zmian kodu, które spowodują niepowodzenie testu w przyszłych wersjach.
Projektowanie i przeglądanie Azure Policy jako przepływów pracy kodu w ramach podejścia TDD.
Usługa Azure Blueprints grupuje zasady i inne narzędzia wdrażania do powtarzalnego pakietu, który można przypisać do wielu stref docelowych. Strategie są przydatne w przypadku wielu wysiłków związanych z wdrażaniem, które współużytkują typowe rozwiązania DoD, które mogą być aktualizowane w czasie. Usługa Azure Blueprints może również pomóc we wdrożeniu podczas kolejnych wysiłków związanych z rozszerzaniem i refaktoryzowaniem stref docelowych.
Usługa Azure Blueprints udostępnia różne przykłady strategii, w tym zasady testowania i szablonów do wdrożenia. Te przykłady strategii mogą przyspieszyć prace programistyczne, wdrożeniowe i testowe w cyklach TDD.
Usługa Azure Resource Graph udostępnia język zapytań do tworzenia testów opartych na danych na podstawie informacji o zasobach wdrożonych w strefie docelowej. W dalszej części planu wdrożenia to narzędzie może również definiować złożone testy na podstawie interakcji między zasobami obciążenia a bazowym środowiskiem chmury.
Resource Graph zawiera zaawansowane przykłady zapytań, których można użyć do zrozumienia sposobu wdrażania obciążeń w strefie docelowej na potrzeby zaawansowanych scenariuszy testowania.
W zależności od preferowanego podejścia można również użyć następujących narzędzi:
- Wdrażanie stref docelowych przy użyciu programu Terraform.
- Wdrażanie stref docelowych przy użyciu Bicep.
- Zarządzanie strefami docelowymi przy użyciu modułu AzOps, modułu programu PowerShell, który wypycha szablony zasobów i pliki Bicep na wszystkich poziomach zakresu platformy Azure oraz ściąga i eksportuje hierarchie zasobów platformy Azure.