Teilen über

Testgesteuerte Entwicklung für Azure-Zielzonen

  • Artikel

Die testgesteuerte Entwicklung (Test-Driven Development, TDD) ist ein Softwareentwicklungs- und DevOps-Prozess, der die Qualität von neuen Features und Verbesserungen in codebasierten Lösungen optimiert. Bei der TDD werden vor dem Entwickeln des tatsächlichen Codes Komponententestfälle erstellt, und der Code wird dann anhand der Testfälle getestet. Dieser Ansatz unterscheidet sich von der gängigen Praxis, zunächst den Code zu entwickeln und erst danach Testfälle zu erstellen.

Eine Zielzone ist eine mittels Code vorab bereitgestellte Umgebung zum Hosten von Workloads. Zielzonen umfassen grundlegende Funktionen, die definierte Clouddienste und bewährten Methoden verwenden. In diesem Artikel wird ein Ansatz beschrieben, der TDD verwendet, um Zielzonen erfolgreich bereitzustellen und dabei Anforderungen an Qualität, Sicherheit, Betrieb und Governance zu erfüllen.

Die Cloudinfrastruktur stellt die Ausgabe der Codeausführung dar. Ein gut strukturierter, getesteter und überprüfter Code erzeugt eine entwicklungsfähige Zielzone. Für die cloudbasierte Infrastruktur und den zugrunde liegenden Quellcode können Sie mit diesem Prozess eine hohe Qualität der Zielzonen und die Einhaltung der zentralen Anforderungen sicherstellen.

Nutzen Sie diesen Ansatz, um einfache Featureanforderungen während der frühen Entwicklungsphase zu erfüllen. Dieser Prozess kann zu einem späteren Zeitpunkt im Lebenszyklus der Cloudeinführung verwendet werden, um Anforderungen an Sicherheit, Betrieb, Governance oder Compliance zu erfüllen. Der Prozess ist besonders nützlich für die Entwicklung und Umgestaltung von Zielzonen in einem parallelen Entwicklungsansatz.

Testgesteuerter Entwicklungszyklus

Das folgende Diagramm zeigt den Lebenszyklus bei der testgesteuerten Entwicklung für Azure-Zielzonen:

Diagramm der testgesteuerten Entwicklung für Azure-Zielzonen

  1. Erstellen Sie einen Test. Definieren Sie einen Test, um die Einhaltung der Akzeptanzkriterien für ein bestimmtes Feature zu überprüfen. Automatisieren Sie den Test während der Entwicklung, um den manuellen Testaufwand zu verringern, insbesondere für Bereitstellungen auf Unternehmensniveau.

  2. Testen Sie die Zielzone. Führen Sie den neuen Test und alle vorhandenen Tests aus. Wenn das erforderliche Feature vom Cloudanbieter nicht angeboten wird und nicht über frühere Entwicklungsschritte bereitgestellt wurde, sollte der Test zu Fehlern führen. 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.

  3. Erweitern Sie die Zielzone, oder gestalten Sie sie um. Fügen Sie Quellcode hinzu, oder modifizieren Sie ihn, um das gewünschte Feature mit Mehrwert zu erfüllen und die allgemeine Qualität der Codebasis zu verbessern.

    Das Cloudplattformteam würde nur Code hinzufügen, der den TDD-Kriterien entspricht (und nicht mehr). Codequalität und Wartung sind jedoch gemeinsame Anstrengungen. Bei der Erfüllung von Anforderungen für neue Features sollte das Cloudplattformteam versuchen, den Code zu optimieren, indem es Duplizierungen entfernt und den Code klarer gestaltet. Das Ausführen von Tests zwischen der Erstellung neuen Codes und dem Umgestalten des Quellcodes wird dringend empfohlen.

  4. Stellen Sie die Zielzone bereit. Wenn der Quellcode in der Lage ist, die Featureanforderungen zu erfüllen, stellen Sie die modifizierte Zielzone beim Cloudanbieter in einer kontrollierten Test- oder Sandboxumgebung bereit.

  5. Testen Sie die Zielzone. Beim erneuten Testen der Zielzone muss überprüft werden, ob der neue Code die Akzeptanzkriterien für das angeforderte Feature erfüllt. Nachdem alle Tests bestanden wurden, wird das Feature als abgeschlossen betrachtet, und die Akzeptanzkriterien gelten als erfüllt.

Der TDD-Zyklus wird mit den obigen grundlegenden Schritten wiederholt, bis die Definition of Done (DoD) vollständig erfüllt ist. Wenn alle Features mit Mehrwert und die Akzeptanzkriterien die entsprechenden Tests bestanden haben, ist die Zielzone bereit, die nächste Welle des Cloudeinfü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 der testgesteuerten Entwicklung besteht darin, den Entwurf zu verbessern, nicht eine Suite von Tests zu erstellen. Die Tests sind ein wertvolles Artefakte zum Abschließen des Prozesses.

Definition of Done

Erfolg kann subjektiv sein und dem Cloudplattformteam während der Entwicklung oder Umgestaltung der Zielzone nur wenige aktionsfähige Informationen liefern. Diese fehlende Eindeutigkeit kann zu unerfüllten Erwartungen und Sicherheitsrisiken in einer Cloudumgebung führen. Bevor das Cloudplattformteam eine Zielzone umgestaltet oder erweitert wird, 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. In ausgereiften Prozessen haben die erwarteten Features jeweils eigene Akzeptanzkriterien, um noch mehr Klarheit zu schaffen. Wenn die Features mit Mehrwert jeweils die Akzeptanzkriterien erfüllen, ist die Zielzone ausreichend konfiguriert, um den Erfolg der aktuellen Einführungsphase oder der Veröffentlichung zu ermöglichen.

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 nicht geschäftskritisch 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 Cloudeinführungsteam die folgenden Kriterien erfüllen:

  • Netzwerksegmentierung zur Anpassung 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 Kennzeichnungsschema für die einfache Anwendung.
  • Während der Einführung: temporärer Zugriff für das Cloudeinführungsteam, um Dienstkonfigurationen zu ändern
  • Vor der Produktionsfreigabe: Integration mit dem Unternehmensidentitätsanbieter, um die fortlaufende Verwaltung von Identitäten und Zugriff für den Betrieb zu steuern. Zu diesem Zeitpunkt sollte der Zugriff des Cloudeinführungsteams widerrufen werden.

Der letzte Punkt ist kein Feature- oder Akzeptanzkriterium, aber ein Indikator, dass zusätzliche Erweiterungen erforderlich sind, die schon frühzeitig mit anderen Teams untersucht werden sollten.

Komplexere DoD-Beispiele

Die Governancemethodik innerhalb des Cloud Adoption Frameworks bietet eine erzählerische Reise 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.

Die obigen Beispiele sind einfache Beispiele, die Ihnen helfen, eine DoD für Ihre Zielzonen zu entwickeln. Für die fünf Disziplinen der Cloudgovernance stehen jeweils weitere Beispielrichtlinien zur Verfügung.

Azure-Tools und -Features zur Unterstützung der TDD von Zielzonen

Das folgende Diagramm zeigt die verfügbaren Tools zur testgesteuerten Entwicklung in Azure:

Diagramm der in Azure verfügbaren Tools zur testgesteuerten Entwicklung

Sie können diese Azure-Tools und -Features ganz einfach in die TDD für die Erstellung von Zielzonen integrieren. Diese Tools dienen einem bestimmten Zweck, um das Entwickeln, Testen und Bereitstellen Ihrer Zielzone in Übereinstimmung mit TDD-Zyklen zu vereinfachen.

  • Azure Resource Manager bietet eine konsistente Plattform für Erstellungs- und Bereitstellungsprozesse. Über die Resource Manager-Plattform können Zielzonen auf der Grundlage von Quellcodedefinitionen bereitgestellt werden.

  • Azure Resource Manager-Vorlagen (ARM) stellen den primären Quellcode für in Azure bereitgestellte Umgebungen zur Verfügung. Einige Drittanbietertools wie etwa Terraform generieren eigene ARM-Vorlagen, die dann an Azure Resource Manager übermittelt werden.

  • 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 die automatische Erkennung, den Schutz und die Lösung verwendet werden.

    Sie können in einem TDD-Zyklus eine Richtliniendefinition erstellen, um ein einzelnes Akzeptanzkriterium zu testen. Azure Policy umfasst integrierte Richtliniendefinitionen, die individuelle Akzeptanzkriterien innerhalb der 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. Ebenso können Sie alle Akzeptanzkriterien einer Richtlinieninitiative hinzufügen, die dem gesamten Abonnement zugewiesen wird. Wenn die Zielzone der DoD entspricht, kann Azure Policy die Testkriterien erzwingen, um Codeänderungen zu verhindern, die in zukünftigen Releases zu Testfehlern führen würden.

    Unter Azure Policy als Codeworkflow finden Sie Informationen für den Entwurf als Teil Ihres TDD-Ansatzes.

  • Azure Resource Graph bietet eine Abfragesprache zur Erstellung datengesteuerter Tests auf der Grundlage von Informationen zu den in einer Zielzone bereitgestellten Ressourcen. Später im Einführungsplan kann dieses Tool auch komplexe Tests definieren, die auf den Interaktionen zwischen den Workloadressourcen und der zugrunde liegenden Cloudumgebung basieren.

    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.

Je nach bevorzugtem Ansatz können Sie auch die folgenden Tools verwenden:

Nächste Schritte