Udostępnij za pośrednictwem

Programowanie oparte na testach dla stref docelowych platformy Azure

  • Artykuł

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.

Strefa docelowa to środowisko do hostowania obciążeń, które są wstępnie aprowidowane za pośrednictwem 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 w przypadku opracowywania i refaktoryzacji stref docelowych w ramach równoległego opracowywania.

Cykl programowania opartego na testach

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

Diagram procesu 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ółużytkowane. 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ę docelową. Po spełnieniu żądania funkcji przez kod źródłowy wdróż zmodyfikowaną strefę docelową u dostawcy chmury w kontrolowanym środowisku testowania lub 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, dopóki nie spełniają pełnej definicji wykonanej. 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ół platformy w chmurze rozpoczyna się od testu, który zakończył się niepowodzeniem lub czerwonym testem, 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 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 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, powinien szukać jasności co do 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, definiując oczekiwane funkcje dodane do wartości, które mają zostać uwzględnione w wysiłkach programistycznych strefy docelowej. DoD to często lista kontrolna zgodna z krótkoterminowym planem wdrażania chmury.

W miarę jak zespoły wdrażają więcej obciążeń i funkcji w chmurze, doD i 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

W przypadku początkowej migracji dodek może być nadmiernie prosty. 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ą wydane w środowisku produkcyjnym, ale nie oczekuje się, że zmiany będą krytyczne i wrażliwe.

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

Metodologia ład w przewodniku Cloud Adoption Framework zapewnia narrację przez 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.

Powyższe przykłady to podstawowe przykłady, które ułatwiają opracowywanie usługi 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:

Diagram przedstawiający 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ę do 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) 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 ułatwiają przyspieszenie wdrażania strefy docelowej i obciążenia.

  • Usługa Azure Policy udostępnia podstawowy mechanizm testowania kryteriów akceptacji w usłudze 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 zawiera wbudowane definicje zasad, które mogą spełniać indywidualne kryteria akceptacji w usłudze DoD. 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 identyfikatora DoD dla strefy docelowej. Możesz dodać wszystkie kryteria akceptacji do inicjatywy zasad przypisanej do całej subskrypcji. Gdy strefa docelowa 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 usługi Azure Policy jako przepływów pracy kodu w ramach podejścia 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:

Następne kroki