Build-, Test‑ und Qualitätskontrollprozesse planen

  • 10 Minuten

In dieser Lerneinheit werden Entwicklungsprozesse untersucht, die Sie zum Verwalten der Build-, Test‑ und Qualitätskontrollprozesse verwenden können. Zudem erhalten Sie Informationen zur Planung der Verwaltung dieser Prozesse.

Einen Projektplan für Builds erstellen

Je nach der gewählten Methodik müssen Sie Zeiten und Speicherorte für Builds auswählen. Sie müssen auch die Ausführungsreihenfolge für Ihre Builds festlegen. Beispielsweise möchten Sie Ihren Code erst in der Testumgebung prüfen, bevor Sie ihn von der Entwicklungsumgebung in die Produktionsumgebung übertragen.

Sie müssen auch die Vorgehensweise für eine Entwicklung definieren, die die Tests nicht besteht, da für diese Entwicklung ein Rollback erforderlich ist. Diese Methode soll verhindern, dass Fehler begünstigt werden. Sie können Microsoft Dynamics 365 Lifecycle Services zum Verwalten Ihres Builds von Umgebung zu Umgebung verwenden.

Beispielsweise kann ein Build jeden fehlerhaften Code aus Ihrer Testumgebung in Ihre Entwicklungsumgebung zurücksetzen, den Status eines erfolgreichen Code von „Testen“ in „Produktion“ ändern und schließlich den fertigen Code aus der Entwicklungsumgebung in den Status „Testen“ bringen.

Erforderliche Umgebungen bestimmen

Sie sollten die Auswahl Ihrer Umgebungen zu Beginn der Implementierung planen. Berücksichtigen Sie bei der Planung Ihrer Umgebungen Folgendes:

  • Bestimmen Sie den Umgebungszweck. Überlegen Sie, ob die Umgebungen für Entwicklung, Systemtests, Benutzerakzeptanztests (User Acceptance Testing, UAT) oder Vorgänge verwendet werden sollen.
  • Berücksichtigen Sie die Umgebungstopologie, z. B. Entwickeln oder Erstellen und testen.
  • Berücksichtigen Sie die Umgebungsebene (Ebene-1 oder Ebene-2).

Eine Ebene-1-Umgebung ist eine Single-Box-Umgebung, in der alle Komponenten auf demselben Server installiert sind. Eine Ebene-1-Umgebung verwendet Microsoft SQL Server und ist so strukturiert, dass die Entwicklungseffizienz maximiert wird. Diese Ebene ist keine gute Option für UAT‑ oder Leistungstests.

Eine Umgebung der Ebene-2 oder höher ist eine Multi-Box-Umgebung mit Komponenten, die auf mehreren Servern installiert sind. Anstatt von Microsoft SQL Server verwenden Ebene-2-Umgebungen die Microsoft Azure SQL-Datenbank. Die Architektur in dieser Umgebung ist dieselbe wie in der Produktionsumgebung, es wird jedoch keine Notfallwiederherstellung verwendet. Diese Umgebung sollten Sie für UAT‑ und Leistungstests verwenden.

Das Cloud-Standardangebot für Umgebungen umfasst eine Ebene-1-Umgebung für Entwicklung und Tests, eine Ebene-2-Umgebung für UAT und eine Produktionsumgebung. Diese Umgebungen werden vom System zu unterschiedlichen Zeiten bereitgestellt:

  • Ebene-2-Umgebung – Während des Installationsvorgangs.
  • Entwicklungs‑ und Testumgebung der Ebene 1 – Wenn die Entwurfsphase beginnt und Microsoft Azure DevOps konfiguriert wurde.
  • Produktionsumgebung – Während der Bereitschaft des Produktionssystems mit Microsoft. Sie müssen diese Umgebung über Lifecycle Services anfordern.

Sie können bei Bedarf auch eine weitere Add-On-Umgebung für Ebene-1‑ und Ebene-2-Umgebungen hinzufügen. Ebene-1-Umgebungen können zudem auch als in der Cloud gehostete Umgebung oder als Umgebungsimage bereitgestellt werden. Debitoren oder Partner verwalten die in der Cloud gehosteten Umgebungen. Das Umgebungsimage ist eine lokale Umgebung, die eine virtuelle Festplatte verwendet.

Sie können festlegen, welche Umgebungen Sie benötigen und wann Sie sie benötigen. Sie müssen Ihre erforderlichen Umgebungslisten in einer Matrix für Microsoft zusammenfassen.

Mithilfe des Umgebungsplans können Sie den Fluss für das Erstellen von Code in allen Umgebungen festlegen und das ALM strukturieren.

Anzahl erforderlicher Tests planen

Bei der Implementierung von Finanz‑ und Betriebs-Apps müssen Sie entscheiden, wie Sie Ihre Entwicklung für eine Genehmigung testen, wer den Test durchführt, welche Kriterien Sie für die Genehmigung verwenden und wie Sie die Tests nachverfolgen. Sie können Einheitentests, Regressionstests und Leistungstests zum Testen des Systems verwenden.

Einheitentests sind nützlich, um zu testen, ob eine bestimmte Funktionalität funktioniert. Beim Einheitentest wird nicht geprüft, ob der neue Code Auswirkungen auf vorhandene Funktionen im System hat.

Beim Regressionstest wird ein gesamter Prozess getestet, um sicherzustellen, dass vorhandene Features mit der neuen Entwicklung weiterhin funktionieren. Wenn Sie beispielsweise eine Änderung vornehmen, um kundenbezogene Funktionen hinzuzufügen, sollten Sie Regressionstests durchführen, um sicherzustellen, dass die neuen Funktionen vorhandene Funktionen wie Kundenaufträge nicht beeinträchtigen.

Sie sollten auch einen Leistungstest des Systems in Erwägung ziehen, um sicherzustellen, dass das System stabil ist. Lassen Sie zu diesem Zweck mehrere Benutzer auf das System zugreifen und umfangreiche Steuerprozesse durchführen. Mit diesem Ansatz können Sie weitere Möglichkeiten zur Leistungssteigerung finden.

Die Finanz‑ und Betriebs-Apps enthalten das Aufgabenaufzeichnungstool, mit dem Sie die Schritte eines Prozesses dokumentieren können, den ein Benutzer ausführt. Mit Microsoft Azure DevOps können Sie Aufgaben mit einer Entwicklungsprojektlösung verknüpfen. Die Aufgabe können Sie dann zum Nachverfolgen von Aktualisierungen, Testen von Dokumenten und anderen Notizen verwenden.

Quellcodeverwaltung und Qualitätskontrolle für Entwickler

Gelegentlich arbeiten mehrere Entwickler gleichzeitig in Finanz‑ und Betriebs-Apps. Sie können eine Quellcodeverwaltung mit einem Azure DevOps-Projekt einrichten, um zu verhindern, dass Entwickler sich gegenseitig in ihrer Arbeit stören.

In diesem Azure DevOps-Projekt wird der Quellcode Ihres Modells gehostet, mit dem Benutzer Objekte ein‑ und auschecken können. Beim Auschecken eines Objekts teilen Sie dem System mit, dass Sie Änderungen vornehmen. Beim erneuten Einchecken des Objekts erstellt das System eine neue Version dieses Objekts.

Mit der Versionskontrolle können Sie frühere Änderungen anzeigen, die jemand vorgenommen hat. Sie können ausstehende Änderungen an den zuletzt eingecheckten Änderungen rückgängig machen. Mit der Funktion Aktuelle Daten abrufen können Sie die neueste eingecheckte Version des Objekts abrufen. Diese Funktion sollte regelmäßig von Entwicklern verwendet werden, um sicherzustellen, dass sie den aktuellen Code verwenden.

Befolgen Sie die Anweisungen von Microsoft Dynamics 365 X++ und bewährte Methoden, um die Qualität der Entwicklung zu gewährleisten. Möglicherweise möchten Sie auch Ihre eigenen Best Practices entwickeln, z. B. Namenskonventionen, um die gesamte Entwicklung innerhalb der Organisation standardisiert zu halten.

Ein Versionskontrollsystem auswählen

Bei Finanz‑ und Betriebs-Apps ist ein Versionskontrollsystem obligatorisch. Azure DevOps unterstützt sowohl Team Foundation-Versionskontrolle (TFVC) als auch Git.

Azure DevOps Team Foundation-Versionskontrolle

Das Azure DevOps Team Foundation-Versionskontrolle-System ist ein Versionskontrolle-System für Finanz‑ und Betriebs-Apps. Es ist ein zentralisiertes Versionskontrollsystem, was bedeutet, dass die Entwickler in einer Zweigstelle arbeiten und eine Version jeder Datei auf ihren Entwicklungsrechnern haben. Jede Zweigstelle gehört zu einem Server-Arbeitsbereich und jeder Entwickler arbeitet in einem lokalen Arbeitsbereich. Wenn ein Entwickler Quellcode eincheckt, muss er sicherstellen, dass er die neueste Version eincheckt und bestehende Konflikte bereinigt.

Standardmäßig sind TFVC-Repositorys im Bereich Organisationseinstellungen von Azure DevOps deaktiviert. Sie müssen die Repositorys aktivieren, bevor Sie ein neues Azure DevOps-Projekt mit TFVC als Versionskontrollsystem erstellen können.

Gehen Sie folgendermaßen vor, um die Team Foundation-Versionskontrolle (TFVC) in Ihrer Organisation zu aktivieren.

  1. Öffnen Sie Azure DevOps, indem Sie zu dev.azure.com/<Ihre Organisation> wechseln.
  2. Wählen Sie unten links im Dashboard die Option Organisationseinstellungen aus.
  3. Öffnen Sie Repos > Repositorys.
  4. Deaktivieren Sie den Schalter Erstellung von TFVC-Repositorys deaktivieren im Abschnitt Alle Repository-Einstellungen.

Screenshot des Abschnitts „Alle Repository-Einstellungen“ mit der Option „Erstellung von TFVC-Repositorys deaktivieren“

Sie können neue Azure DevOps-Projekte mit TFVC als Versionskontrollsystem erstellen.

Git

Git ist das für die Entwicklung empfohlene Standard-Versionskontrollsystem von Microsoft.

Git ist ein verteiltes System, während TFVC ein zentralisiertes Versionskontrollsystem ist. Jeder Entwickler hat seine eigene Kopie eines Quellrepositorys (oder einer Lightweight-Verzweigung) und kann Änderungen darin festschreiben. Entwickler können neue private Verzweigungen erstellen und von einer Verzweigung in eine andere wechseln. In TFVC ist es schwieriger, von einer Verzweigung in eine andere zu wechseln, und es sind häufig mehrere Entwicklungsumgebungen erforderlich.

Es ist wichtig zu beachten, dass Sie die Möglichkeit haben, von TFVC zu Git und umgekehrt zu migrieren.