Build-, Test‑ und Qualitätskontrollprozesse planen

  • 10 Minuten

In diesem Abschnitt werden Entwicklungsprozesse zum Verwalten der Build-, Test‑ und Qualitätskontrollprozesse erläutert, und Informationen zum Planen der Verwaltung dieser Prozesse bereitgestellt.

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. Das soll verhindern, dass Fehler begünstigt werden. Sie können 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

Die Auswahl der Umgebungen sollte zu Beginn der Implementierung geplant werden. 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.
  • 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 Azure SQL-Datenbank. Die Architektur in dieser Umgebung ist dieselbe wie in der Produktionsumgebung, es wird jedoch keine Notfallwiederherstellung verwendet. Diese Umgebung sollte für UAT‑ und Leistungstests verwendet werden.

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 zu unterschiedlichen Zeiten bereitgestellt. Ebene-2 wird beim Onboarding bereitgestellt. Die Entwicklungs‑ und Testumgebung der Ebene 1 wird bereitgestellt, wenn die Entwurfsphase beginnt und Microsoft Azure DevOps konfiguriert wurde. Schließlich wird die Produktionsumgebung während der Bereitschaft des Produktionssystems mit Microsoft bereitgestellt. Diese Umgebung muss über Lifecycle Services angefordert werden.

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 auch als in der Cloud gehostete Umgebung oder als Umgebungsimage bereitgestellt werden. In der Cloud gehostete Umgebungen werden vom Kunden oder Partner verwaltet. 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. Einheitentests, Regressionstests und Leistungstests können zum Testen des Systems verwendet werden.

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 könnten auch erwägen, die Leistung des Systems auf Stabilität zu testen, indem mehrere Benutzer sich im System anmelden und umfangreiche Steuerprozesse ausführen. So können Sie weitere Möglichkeiten zur Leistungssteigerung finden.

Die Finanz‑ und Betriebs-Apps enthalten das Aufgabenaufzeichnungstool, mit dem die Schritte eines Prozesses dokumentiert werden, den ein Benutzer ausführt. Außerdem können Sie mit Azure DevOps Aufgaben mit einer Entwicklungsprojektlösung verknüpfen. Die Aufgabe kann zum Nachverfolgen von Aktualisierungen, Testen von Dokumenten und anderen Notizen verwendet werden.

Quellcodeverwaltung und Qualitätskontrolle für Entwickler

Gelegentlich arbeiten mehrere Entwickler gleichzeitig in Finanz‑ und Betriebs-Apps. Es kann eine Quellcodeverwaltung mit einem Azure DevOps-Projekt eingerichtet werden, 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.

Mithilfe der Versionskontrolle können Sie sehen, welche vorherigen Änderungen vorgenommen wurden. 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-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 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 alle Konflikte bereinigt.

Standardmäßig sind Team Foundation-Versionskontrolle-Repositorys in den Azure DevOps-Organisationseinstellungen deaktiviert, und Sie müssen sie aktivieren, bevor Sie ein neues Azure DevOps-Projekt mit der Team Foundation-Versionskontrolle 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 bei dev.azure.com/<Ihre Organisation>.
  2. Wählen Sie unten links im Dashboard die Option Organisationseinstellungen aus.
  3. Öffnen Sie Repos > Repositorys.
  4. Deaktivieren Sie die Option Erstellung von TFVC-Repositorys deaktivieren in Alle Repository-Einstellungen. Screenshot des Abschnitts „Alle Repository-Einstellungen“ mit der Option „Erstellung von TFVC-Repositorys deaktivieren“

Neue DevOps-Projekte mit TFVC können als Versionskontrollsystem erstellt werden.

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 war es schwieriger, von einer Verzweigung in eine andere zu wechseln, und es waren häufig mehrere Entwicklungsumgebungen erforderlich.

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