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 utworzeniem 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.

pl-PL: strefy lądowania to środowisko do hostowania obciążeń, które jest wstępnie przygotowane 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 pomyślnych stref docelowych przy jednoczesnym spełnieniu wymagań dotyczących jakości, zabezpieczeń, operacji i ładu.

Infrastruktura chmurowa to dane wyjściowe wykonywania kodu. Dobrze ustrukturyzowany, przetestowany i zweryfikowany kod tworzy realną 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 do opracowywania i refaktoryzacji strefy startowej w ramach równoległych działań rozwojowych.

Cykl programowania opartego na testach

Na poniższym diagramie przedstawiono cykl programowania opartego na testach dla stref docelowych platformy Azure:

1. Utwórz test. Zdefiniuj test w celu sprawdzenia, czy zostały spełnione kryteria akceptacji funkcji. Zautomatyzuj test podczas opracowywania, aby zmniejszyć ilość ręcznego wysiłku testowego, zwłaszcza w przypadku wdrożeń w skali przedsiębiorstwa.

2. 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 prace 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.

3. 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ół platformy w chmurze doda kod tylko w celu spełnienia żądanej funkcji. Jednak jakość kodu i konserwacja są wspólnym wysiłkiem. W miarę wypełniania nowych żądań funkcji zespół ds. platformy w chmurze powinien spróbować ulepszyć 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.

4. Wdróż strefę lądowania. Po zrealizowaniu żądania funkcji przez kod źródłowy, wdróż zmodyfikowaną strefę lądowania u dostawcy chmury w kontrolowanym środowisku testowym lub w środowisku piaskownicy.

5. 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 uważana za kompletną, a kryteria akceptacji są uznawane za spełnione.

Cykl TDD powtarza poprzednie podstawowe kroki do momentu spełnienia pełnej definicji wykonanej. Kiedy wszystkie funkcje wartości dodanej i kryteria akceptacji przechodzą powiązane testy, strefa wdrożeniowa jest gotowa na wsparcie kolejnej fali planu wdrożenia chmury.

Cykl, który sprawia, że TDD jest skutecznym podejściem, jest często określany jako test czerwono-zielony. W tym podejściu zespół platformy w chmurze zaczyna od nieudanego testu, zwanego również czerwonym testem, na podstawie definicji ukończenia oraz ustalonych kryteriów akceptacji. Dla każdej funkcji lub kryteriów akceptacji zespół platformy w chmurze wykonuje zadania programistyczne do momentu ukończenia testu lub uzyskania zielonego testu.

Celem TDD jest lepsze projektowanie, a nie tworzenie zestawu testów. Testy są cennym artefaktem umożliwiającym ukończenie procesu.

Definicja ukończenia

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 niespełnionych oczekiwań i luk w środowisku chmurowym. Zanim zespół ds. platformy w chmurze refaktoryzuje lub rozszerzy wszystkie strefy docelowe, powinni dążyć do jasności co do definicji gotowej (DoD) dla każdej strefy docelowej.

DoD to prosta umowa między zespołem platformy chmurowej a innymi zespołami, których to dotyczy, definiująca oczekiwane wartości dodane funkcji do uwzględnienia w pracach nad rozwojem strefy lądowania. DoD to często zestaw wymagań zgodny z krótkoterminowym planem przyjmowania technologii chmurowych.

W miarę jak zespoły przyjmują więcej obciążeń i funkcji w chmurze, DoD oraz kryteria akceptacji stają się bardziej złożone. W dojrzałych procesach oczekiwane cechy mają własne kryteria akceptacji, aby zapewnić większą przejrzystość. Gdy wszystkie funkcje dodane wartości spełniają kryteria akceptacji, strefa docelowa jest wystarczająco skonfigurowana, aby umożliwić powodzenie bieżącej fali wdrożenia lub wydania.

Przykład prostego DoD (Departamentu Obrony)

W przypadku początkowej migracji, dla Departamentu Obrony może to być zbyt proste. Poniższy przykład to prosty plik DoD:

Początkowa strefa docelowa będzie hostować 10 obciążeń na potrzeby początkowego uczenia się. Te obciążenia nie mają kluczowego wpływu na firmę i nie mają dostępu do poufnych danych. W przyszłości te obciążenia prawdopodobnie zostaną wprowadzone do produkcji, ale nie oczekuje się zmiany ich krytyczności i wrażliwości.

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, przechowywania i sieci w celu hostowania obciążeń dopasowanych do odkrywania zasobów cyfrowych.
• 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 ds. wdrażania chmury.

Ostatni punkt nie jest kryterium cech ani akceptacji, ale wskaźnik, że będzie wymagana większa liczba rozszerzeń i powinien zostać zbadany z innymi zespołami na wczesnym etapie.

Bardziej złożone przykłady DoD (Departamentu Obrony)

Metodologia zarządzania w Cloud Adoption Framework oferuje narracyjną podróż przez naturalną dojrzałość zespołu ds. zarządzania. W tej podróży osadzone są kilka przykładów kryteriów DoD i kryteriów akceptacji w formie oświadczeń polityki.

• początkowe oświadczenia polityki. Przykład początkowej usługi DoD opartej na zasadach firmy, które regulują wymagania dotyczące wdrażania na wczesnym etapie.

• Przyrostowe ulepszenia rozszerzające zarządzanie tożsamościami. Przykład polityk korporacyjnych regulujących DoD w celu spełnienia wymagań dotyczących rozszerzenia zarządzania tożsamościami dla strefy lądowania.

• ulepszenia przyrostowe w celu rozszerzenia wymagań dotyczących zabezpieczeń. Przykład polityk korporacyjnych dotyczących DoD w celu spełnienia wymagań bezpieczeństwa zgodnych z referencyjnym planem wdrożenia chmury.

• Ulepszenia przyrostowe w celu rozszerzenia zarządzania działalnością. Przykład zasad korporacyjnych, regulujących działania Departamentu Obrony, mających na celu spełnienie podstawowych wymagań dotyczących zarządzania operacjami.

• Stopniowe ulepszenia, aby rozszerzyć zarządzanie kosztami. Przykład polityk korporacyjnych regulujących działania DoD w celu spełnienia wymagań dotyczących zarządzania kosztami.

Powyższe przykłady to podstawowe przykłady, które ułatwiają opracowywanie usługi DoD dla stref docelowych.

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 zgodnie z cyklami TDD.

• usługa Azure Resource Manager zapewnia spójną platformę dla procesów kompilacji i wdrażania. Platforma usługi Resource Manager może wdrażać strefy docelowe na podstawie definicji kodu źródłowego.

• szablony usługi Azure Resource Manager (ARM) zapewniają 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 Azure zapewniają szablony kodu źródłowego, które przyspieszają wdrażanie środowisk docelowych i obciążeń.

• usługa Azure Policy udostępnia podstawowy mechanizm testowania kryteriów akceptacji w DoD. Usługa 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. Usługa Azure Policy obejmuje wbudowane definicje zasad, które mogą spełniać indywidualne kryteria akceptacji w ramach DoD (Departamentu Obrony). To podejście zapewnia mechanizm czerwonych testów przed zmodyfikowaniem strefy docelowej.

  Usługa Azure Policy obejmuje również wbudowane inicjatywy zasad, których można użyć do testowania i wymuszania pełnego DoD dla strefy docelowej. Możesz dodać wszystkie kryteria akceptacji do inicjatywy zasad, która jest przypisana do całej subskrypcji. Gdy strefa docelowa dla wdrożeń spełnia wymagania DoD, usługa Azure Policy może wymusić kryteria testowania, aby uniknąć zmian kodu, które spowodują niepowodzenie testu w przyszłych wersjach.

  Projektowanie i przeglądanie przepływów pracy Azure Policy as Code w ramach podejścia opartego na TDD.

• usługa Azure Resource Graph udostępnia język zapytań umożliwiający tworzenie 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 elementami zawartości obciążenia a bazowym środowiskiem chmury.

  Usługa 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 narzędzia Terraform.
• Wdrażaj strefy docelowe przy użyciu Bicep.
• Zarządzanie strefami docelowymi przy użyciuAzOps , moduł 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.

Następne kroki

• zagadnienia dotyczące zabezpieczeń dla platform DevOps
• opcje implementacji strefy lądowania