Testgesteuerte Entwicklung für Azure-Zielzonen
Testgesteuerte Entwicklung (TDD) ist ein Softwareentwicklungs- und DevOps-Prozess, der die Qualität neuer Features und Verbesserungen in codebasierten Lösungen verbessert. TDD erstellt Komponententestfälle, bevor der eigentliche Code entwickelt wird, und testet den Code anhand der Testfälle. Dieser Ansatz ist dagegen, Code zuerst zu entwickeln und später Testfälle zu erstellen.
Eine Zielzone ist eine mittels Code vorab bereitgestellte Umgebung zum Hosten von Workloads. Zielzonen umfassen grundlegende Funktionen, die einen definierten Satz von Clouddiensten und bewährte Methoden verwenden. In diesem Artikel wird ein Ansatz beschrieben, der TDD verwendet, um erfolgreiche Landungszonen bereitzustellen, während die Qualitäts-, Sicherheits-, Betriebs- und Governanceanforderungen erfüllt werden.
Cloudinfrastruktur ist das Ergebnis der Codeausführung. Gut strukturierter, getesteter und überprüfter Code erzeugt eine lebensfähige Landezone. Cloudbasierte Infrastruktur und der zugrunde liegende Quellcode können diesen Ansatz verwenden, um sicherzustellen, dass Landezonen qualitativ hoch sind und die Kernanforderungen erfüllen.
Verwenden Sie diesen Ansatz, um einfache Featureanforderungen während der frühen Entwicklung zu erfüllen. Später im Lebenszyklus der Cloudakzeptanz können Sie diesen Prozess verwenden, um Sicherheits-, Betriebs-, Governance- oder Complianceanforderungen zu erfüllen. Der Prozess ist besonders nützlich für die Entwicklung und Umgestaltung von Landungszonen in parallelen Entwicklungsanstrengungen.
Testgesteuerter Entwicklungszyklus
Das folgende Diagramm zeigt den testgesteuerten Entwicklungszyklus für Azure-Landezonen:
Erstellen Sie einen Test. Definieren Sie einen Test, um zu überprüfen, ob die Akzeptanzkriterien für ein Feature erfüllt wurden. Automatisieren Sie den Test während der Entwicklung, um den manuellen Testaufwand zu reduzieren, insbesondere für Bereitstellungen im Unternehmen.
Testen Sie die Landungszone. Führen Sie den neuen Test und alle vorhandenen Tests aus. Wenn das erforderliche Feature nicht in den Angeboten des Cloud-Anbieters enthalten ist und noch nicht durch vorherige Entwicklungsbemühungen bereitgestellt wurde, sollte der Test fehlschlagen. Die Durchführung vorhandener Tests hilft zu überprüfen, ob Ihr neues Feature oder Ihr neuer Test die Zuverlässigkeit der vorhandenen Zielzonenfeatures beeinträchtigt.
Erweitern und umgestalten Sie die Landungszone. Fügen Sie Quellcode hinzu oder ändern Sie diesen, um die angeforderte Mehrwert-Funktion zu erfüllen und die allgemeine Qualität der Code-Basis zu verbessern.
Um die TDD-Kriterien zu erfüllen, fügt das Cloudplattformteam Code nur hinzu, um das angeforderte Feature zu erfüllen. Codequalität und -wartung sind jedoch gemeinsame Anstrengungen. Da sie neue Funktionsanforderungen erfüllen, sollte das Cloud-Plattform-Team versuchen, den Code zu verbessern, indem die Duplizierung entfernt und der Code klargestellt wird. Das Ausführen von Tests zwischen neuer Codeerstellung und Umgestaltung von Quellcode wird dringend empfohlen.
Stellen Sie die Zielzone bereit. Sobald der Quellcode die Featureanforderung erfüllt, stellen Sie die geänderte Landing Zone in einer kontrollierten Test- oder Sandkastenumgebung beim Cloud-Anbieter bereit.
Testen Sie die Landungszone. Testen Sie die Landungszone erneut, um zu überprüfen, ob der neue Code die Abnahmekriterien für die angeforderte Funktion erfüllt. Sobald alle Tests bestanden haben, gilt das Feature als abgeschlossen, und die Akzeptanzkriterien werden als erfüllt betrachtet.
Der TDD-Zyklus wird mit den obigen grundlegenden Schritten wiederholt, bis die Definition of Done (DoD) vollständig erfüllt ist. Wenn alle Mehrwertfunktionen und Akzeptanzkriterien ihre zugehörigen Tests bestehen, ist der Landebereich bereit, um die nächste Welle des Cloud-Einführungsplans zu unterstützen.
Der Zyklus, der für eine effektive testgesteuerte Entwicklung sorgt, wird oft als Rot/Grün-Test bezeichnet. Bei diesem Ansatz beginnt das Cloudplattformteam mit einem fehlerhaften Test (Rot-Test), basierend auf der Definition of Done und der definierten Akzeptanzkriterien. Für jedes Feature oder Akzeptanzkriterium schließt das Cloudplattformteam alle Entwicklungsaufgaben bis zum Bestehen des Tests (Grün-Test) ab.
Das Ziel von TDD besteht darin, ein besseres Design zu erreichen und nicht eine Reihe von Tests zu erstellen. Die Tests sind ein wertvolles Artefakte zum Abschließen des Prozesses.
Definition of Done
Erfolg kann ein subjektives Maß sein, das einem Cloudplattformteam während der Entwicklung oder Umgestaltung der Landezone wenig umsetzbare Informationen liefert. Mangelnde Klarheit kann zu verpassten Erwartungen und Sicherheitsrisiken in einer Cloudumgebung führen. Bevor das Cloudplattformteam eine Zielzone umgestaltet oder erweitert, sollte es sich Klarheit über die Definition of Done (DoD) für jede Zielzone verschaffen.
DoD ist eine einfache Vereinbarung zwischen dem Cloudplattformteam und anderen beteiligten Teams, in der die erwarteten Mehrwertfeatures definiert sind, die in die Entwicklung der Zielzone einbezogen werden sollen. Die Definition of Done ist häufig eine Prüfliste, die auf den kurzfristigen Cloudeinführungsplan ausgerichtet ist.
Wenn die Teams zusätzliche Workloads und Cloudfeatures einführen, werden die Definition of Done sowie die Akzeptanzkriterien zunehmend komplexer. Bei ausgereiften Prozessen haben die erwarteten Features jeweils ihre eigenen Akzeptanzkriterien, um mehr Klarheit zu schaffen. Wenn die wertsteigernden Funktionen alle die Akzeptanzkriterien erfüllen, ist die Landezone ausreichend konfiguriert, um den Erfolg der aktuellen Einführungswelle oder -freigabe sicherzustellen.
Einfaches DoD-Beispiel
Für einen anfänglichen Migrationsaufwand kann das DoD sehr einfach sein. Das folgende Beispiel veranschaulicht eine einfache DoD:
Die anfängliche Zielzone wird zum Hosten von 10 Workloads für erste Lernzwecke genutzt. Diese Workloads sind für das Unternehmen nicht kritisch und haben keinen Zugriff auf vertrauliche Daten. In Zukunft werden diese Workloads wahrscheinlich für die Produktion freigegeben, aber die Bedeutung und Vertraulichkeit werden sich nicht ändern.
Um diese Workloads zu unterstützen, muss das Cloud-Einführungsteam die folgenden Kriterien erfüllen:
- Netzwerksegmentierung zur Ausrichtung an den vorgeschlagenen Netzwerkentwurf. Diese Umgebung sollte ein Umkreisnetzwerk mit Zugriff auf das öffentliche Internet sein.
- Zugriff auf Compute-, Speicher- und Netzwerkressourcen zur Bewältigung der Workloads, die auf die Ermittlung digitaler Ressourcen ausgerichtet sind.
- Benennungs- und Taggingschema für die einfache Anwendung.
- Während der Einführung, temporärer Zugriff für das Cloud-Einführungsteam, um Dienstkonfigurationen zu ändern.
- Vor der Produktionsfreigabe: Integration mit dem Unternehmensidentitätsanbieter, um die fortlaufende Verwaltung von Identität und Zugriff für das Operations Management zu steuern. Zu diesem Zeitpunkt sollte der Zugriff des Cloudeinführungsteams widerrufen werden.
Der letzte Punkt ist kein Feature- oder Akzeptanzkriterium, sondern ein Indikator, dass mehr Erweiterungen erforderlich sind und frühzeitig mit anderen Teams untersucht werden sollten.
Komplexere DoD-Beispiele
Die Governancemethodik innerhalb des Cloud Adoption Frameworks bietet eine erzählerische Journey durch den natürlichen Entwicklungsverlauf eines Governanceteams. Eingebettet in diese Journey sind mehrere Beispiele für eine Definition of Done und Akzeptanzkriterien in Form von Richtlinienanweisungen.
Anfängliche Richtlinienanweisungen: Beispiel für anfängliche DoD basierend auf Unternehmensrichtlinien, die Anforderungen für die Anfangsphase der Einführung steuern.
Inkrementelle Verbesserungen zum Erweitern der Identitätsverwaltung: Beispiel für Unternehmensrichtlinien für die DoD, um die Anforderungen zum Erweitern der Identitätsverwaltung für eine Zielzone zu erfüllen.
Inkrementelle Verbesserungen zum Erweitern der Sicherheitsanforderungen. Beispiel für Unternehmensrichtlinien des DoD zur Erfüllung der Sicherheitsanforderungen im Einklang mit dem Cloud-Einführungsreferenzplan.
Inkrementelle Verbesserungen zum Erweitern der Betriebsverwaltung. Beispiel für Unternehmensrichtlinien des Verteidigungsministeriums zur Erfüllung grundlegender Anforderungen des Betriebsmanagements.
Inkrementelle Verbesserungen zum Erweitern der Kostenverwaltung. Beispiel für Unternehmensrichtlinien des US-Verteidigungsministeriums (DoD), um die Anforderungen an das Kostenmanagement zu erfüllen.
Die obigen Beispiele sind einfache Beispiele, die Ihnen helfen, eine DoD für Ihre Zielzonen zu entwickeln.
Azure-Tools und -Features zur Unterstützung der TDD von Zielzonen
Das folgende Diagramm zeigt die verfügbaren testgesteuerten Entwicklungstools in Azure:
Sie können diese Azure-Tools und -Features ganz einfach in die TDD für die Erstellung von Zielzonen integrieren. Die Tools dienen speziellen Zwecken und erleichtern die Entwicklung, Tests und Bereitstellung von Landungszonen in Übereinstimmung mit TDD-Zyklen.
Azure Resource Manager bietet eine konsistente Plattform für Build- und Bereitstellungsprozesse. Die Resource Manager-Plattform kann Zielzonen basierend auf Quellcodedefinitionen bereitstellen.
Azure Resource Manager (ARM)-Vorlagen stellen den primären Quellcode für in Azure bereitgestellte Umgebungen bereit. Einige Drittanbietertools wie Terraform stellen eigene ARM-Vorlagen bereit, die sie an Azure Resource Manager übermitteln können.
Azure-Schnellstartvorlagen stellen Quellcodevorlagen zur Verfügung, um die Bereitstellung von Zielzonen und Workloads zu beschleunigen.
Azure Policy stellt den primären Mechanismus zum Testen von Akzeptanzkriterien in Ihrer DoD bereit. Wenn die Bereitstellungen von den Governancerichtlinien abweichen, kann Azure Policy auch für automatische Erkennung, Schutz und Lösung verwendet werden.
In einem TDD-Zyklus können Sie eine Richtliniendefinition erstellen, um ein einzelnes Akzeptanzkriterium zu testen. Azure Policy umfasst integrierte Richtliniendefinitionen, die individuelle Akzeptanzkriterien innerhalb einer DoD erfüllen können. Dieser Ansatz bietet einen Mechanismus für Rot-Tests, bevor Sie Zielzone ändern.
Azure Policy umfasst auch integrierte Richtlinieninitiativen, die Sie dazu verwenden können, die vollständige DoD für eine Zielzone zu testen und zu erzwingen. Sie können einer Richtlinieninitiative, die dem gesamten Abonnement zugewiesen ist, alle Akzeptanzkriterien hinzufügen. Wenn die Zielzone die DoD erfüllt, kann Azure Policy die Testkriterien erzwingen, um Codeänderungen zu verhindern, die in zukünftigen Releases zu Testfehlern führen würden.
Unter Workflows für Azure Policy-as-Code finden Sie Informationen für den Entwurf als Teil Ihres TDD-Ansatzes.
Azure Resource Graph bietet eine Abfragesprache zum Erstellen von datengesteuerten Tests, die auf Informationen über die in einer Landing Zone bereitgestellten Assets basieren. Später im Einführungsplan kann dieses Tool auch komplexe Tests auf Basis der Interaktionen zwischen Workload-Assets und der zugrunde liegenden Cloudumgebung definieren.
Resource Graph enthält fortgeschrittene Abfragebeispiele, die für komplexe Testszenarien verwendet werden können, um zu verstehen, wie die Workloads innerhalb einer Zielzone bereitgestellt werden.
Abhängig von Ihrem bevorzugten Ansatz können Sie auch die folgenden Tools verwenden:
- Bereitstellen von Zielzonen mithilfe von Terraform.
- Bereitstellen von Zielzonen mithilfe von Bicep.
- Verwalten von Zielzonen mithilfe von AzOps – ein PowerShell-Modul, das Ressourcenvorlagen und Bicep-Dateien auf allen Azure-Bereichsebenen pusht und Azure-Ressourcenhierarchien pullt und exportiert.