Automatisieren Sie Bereitstellungen mit der Dataverse Git-Integration und Pipelines in Power Platform

Da die Einführung von Power Platform skaliert wird, kämpfen Organisationen häufig darum, ein konsistentes und geregeltes Entwicklungsmodell für mehrere Hersteller, Entwickler und Umgebungen aufrechtzuerhalten. Häufige Herausforderungen sind gemeinsame Entwicklungsumgebungen, eingeschränkte Änderungsablaufverfolgung, inkonsistente Versionsdokumentation und Schwierigkeiten beim Anwenden von Standard-Lebenszyklussteuerelementen für die Softwareentwicklung in Low-Code-Übermittlungsteams. Diese Herausforderungen erhöhen das Bereitstellungsrisiko, verlangsamen die Zusammenarbeit und erschweren die Unterstützung von Überwachungs- und Complianceaktivitäten.

Diese Referenzarchitektur behebt diese Herausforderungen, indem die native Dataverse Git-Integration mit Pipelines in Power Platform, Azure DevOps Governance und KI-unterstützte Versionshinweise-Generation kombiniert wird, um ein wiederholbares Alm-Muster (Enterprise Application Lifecycle Management) zu erstellen.

Tip

Dieser Artikel enthält ein Beispielszenario und eine generalisierte Beispielarchitektur, um zu veranschaulichen, wie Sie die Dataverse Git-Integration, Pipelines in Power Platform und Copilot Studio verwenden, um Bereitstellungen zu automatisieren und bezogene Notizen zu generieren. Das Architekturbeispiel kann für viele verschiedene Szenarien und Branchen modifiziert werden.

Architekturdiagramm

Diagramm der Dataverse ALM-Strategie mit Git-Integration in Entwicklungs-, Test- und Produktionsumgebungen mithilfe von Pipelines in Power Platform.

Workflow

Die folgenden Schritte beschreiben die im Architekturdiagramm dargestellten Entwicklungs-, Test-, Produktions- und Hotfixworkflows.

Entwicklungs- und Quellcodeverwaltungsworkflow

Entwickler und Entwickler verwenden eine von mehreren Dataverse-Entwicklungsumgebungen, um Änderungen vorzunehmen. Zusammen mit einer primären Entwicklungsumgebung können Teams andere Umgebungen verwenden, z. B. für Juniorentwickler, externe Ressourcen, laufende Arbeit für langfristige Initiativen oder für andere Arbeiten, die Teams nicht automatisch in den Hauptproduktionspfad fördern sollten.

  1. Ordnen Sie jeden Entwicklungsdatenstrom einer Git-Umgebung oder einem Featurezweig zu.

  2. Synchronisieren Sie Änderungen in Git über die Dataverse Git-Integration.

  3. Überprüfen Sie Feature-Branches und führen Sie sie mithilfe von Pull Requests und Branchschutzrichtlinien mit dem Git-Hauptbranch zusammen, sobald sie zur Übermittlung in den ALM-Pfad für Produktionstests bereit sind.

  4. Um Funktionsdrift zu vermeiden, übertragen Sie Änderungen, die in der Hauptverzweigung übernommen wurden, in die Verzweigungen, die den jeweiligen Entwicklungsumgebungen entsprechen.

  5. Stellen Sie sicher, dass die Hauptverzweigung zur maßgeblichen Quelle für Integrations- und Freigabehöherstufungen wird.

Test- und Validierungsworkflow

  1. Verwenden Sie aus der Hauptverzweigung einen benutzerdefinierten Pipelinehost , um die verpackte Lösung direkt aus dem Quellcode in der Hauptverzweigung mithilfe des Bereitstellungstyps der Quellcodeverwaltung in die Testumgebung zu übertragen.

  2. Verwenden Sie die Testumgebung für technische Validierung, Integrationsprüfungen und Rauchtests.

  3. Stufen Sie nach der Überprüfung die Lösung zur Benutzerakzeptanztestumgebung (UAT) hoch, indem Sie Pipelines in Power Platform verwenden. Erstellen oder aktualisieren Sie die entsprechenden Freigabeverzweigung in Git auf Basis der Hauptverzweigung.

  4. Generieren Sie Versionshinweise aus DevOps-Arbeitselementen in einem UAT-Status und verteilen Sie sie an verantwortliche Tester der UAT. Verwenden Sie den Agent in Copilot Studio, um mithilfe der Connectoraktion „Get Query Results“ in Azure DevOps diese Versionshinweise zu generieren und zu formatieren.

  5. Stellen Sie sicher, dass UAT vor der Produktionsfreigabe die fachliche Validierung und Prüfungen der Freigabebereitschaft unterstützt.

Workflow für die Produktionsfreigabe

  1. Stufen Sie genehmigte Änderungen aus der UAT-Umgebung mithilfe von Pipelines in Power Platform in die Produktion hoch.

  2. Generieren Sie erneut Versionshinweise aus DevOps-Arbeitselementen anhand des Status für die standardisierte Versionskommunikation.

  3. Verteilen Sie Veröffentlichungsnotizen über genehmigte Kanäle wie Teams, Outlook oder SharePoint an technische und geschäftliche Projektbeteiligte.

Hotfixworkflow

  1. Beheben Sie dringende Produktionsprobleme in einer dedizierten Hotfixumgebung.

  2. Verbinden Sie Hotfixumgebungen mit der aktuellen Git-Freigabeverzweigung für die Produktion über die Dataverse-Git-Integration.

  3. Stufen Sie validierte Hotfixes über denselben kontrollierten Pipeline-Mechanismus in die Produktionsumgebung hoch.

  4. Führen Sie Hotfixänderungen aus der Freigabeverzweigung in der Hauptverzweigung wieder zusammen, um sicherzustellen, dass sie in zukünftigen Versionen erhalten bleiben.

Components

Die folgenden Komponenten unterstützen Quellcodeverwaltung, Umgebungsförderung, Governance und Freigabekommunikation in dieser Architektur.

Integration von Git in Power Platform

Rolle in der Architektur:Die Git-Integration von Microsoft Dataverse synchronisiert Lösungsänderungen zwischen Entwicklungsumgebungen und einer Git-basierten Quellcodeverwaltung.

Warum gewählt:

  • Ermöglicht quellcodegestütztes ALM für Dataverse-Lösungskomponenten
  • Unterstützt die branchbasierte Teamzusammenarbeit
  • Reduziert die manuelle Export- und Importbehandlung

Azure Repos, Verzweigungen und Arbeitselemente

Role in architecture:Azure DevOps hostet Haupt-, Feature- und Release-Branches und erzwingt pull request (PR)-Governance. Es speichert außerdem Arbeitselemente und dient als strukturierte Quelle für den Umfang der Freigabe und Änderungszusammenfassungen.

Warum gewählt:

  • Umfasst umfassende Richtlinienkontrollen für Unternehmen, z. B. PR-Genehmigungen, Branchschutz und Auditprotokolle
  • Ermöglicht eine nahtlose Abstimmung mit Arbeitselementen und Release-Governance-Praktiken
  • Stellt eine konsistente Releasebereichsdefinition bereit.
  • Unterstützt die automatisierte Filterung von releasefertigen Elementen
  • Verbessert die Rückverfolgbarkeit zwischen Codeänderungen und kommunizierten Freigabeinhalten.

In Betracht gezogene Alternativen: GitHub für Code-Repositories und Projektarbeitselemente

Warum diese Architektur Azure DevOps bevorzugt:
Obwohl GitHub-Projekte eine flexible Nachverfolgung von Arbeitsaufgaben ermöglichen können, etwa mit benutzerdefinierten Feldern, Roadmap-Ansichten und Automatisierung, umfasst diese Architektur Azure Boards als maßgebliche Quelle für Release-Arbeitselemente. Azure Boards bietet derzeit eine leistungsfähigere Modellierung von Arbeitsaufgabenprozessen für Unternehmen, gemeinsam genutzte Abfragen und eine auf der Work Item Query Language (WIQL) basierende Eingrenzung des Releaseumfangs sowie eine umfassendere integrierte Nachverfolgbarkeit von Entwicklung und Bereitstellung für regulierte Releasevorgänge.

Pipelines in Power Platform

Rolle in der Architektur:Pipelines in Power Platform ermöglichen die Bereitstellung von Lösungen über Umgebungen hinweg, einschließlich Hotfix-Bereitstellungspfaden.

Warum gewählt:

  • Native Power Platform-Bereitstellung
  • Umgebungsabhängige Bereitstellungs-Orchestrierung
  • Sowohl für Plattformadministratoren als auch für Lösungsteams zugänglich

Alternativen in Betracht gezogen:

Warum diese Architektur Pipelines in Power Platform bevorzugt:
Diese Architektur verwendet Pipelines in Power Platform als primären Mechanismus für die Umgebungsförderung. Sie reduzieren die Konfigurationskomplexität und spezielle Anforderungen an die kontinuierliche Integration/kontinuierliche Bereitstellung (CI/CD) und bieten gleichzeitig eine systemeigene, geregelte Bereitstellungserfahrung für Entscheidungsträger, Administratoren und Pro-Entwickler.

Microsoft Copilot Studio

Role in architecture: A Copilot Studio Release Notes Agent generiert standardisierte Versionshinweise aus genehmigten Arbeitsaufgaben und Versionskontext.

Warum gewählt:

  • Reduziert den manuellen Aufwand der Veröffentlichungsdokumentation.
  • Verbessert Konsistenz und Lesbarkeit der Freigabekommunikation
  • Unterstützt duale Zielgruppen (geschäftliche und technische Projektbeteiligte)

Alternativen in Betracht gezogen:

  • Manuelles Erstellen in E-Mail- oder Wiki-Seiten
  • Vorlagenbasierte, aber nicht KI-gestützte Automatisierung

Warum diese Architektur KI umfasst:
Es zeigt praktische, risikoarme generative KI-Augmentation in einem hochwertigen betrieblichen Prozess mit klarer menschlichen Überprüfung und Rechenschaftspflicht. Es ist flexibler, Zielgruppen, Projekte und Lieferwege zu ändern als starre Automatisierung.

Szenario-Details

Die Architektur ist besonders nützlich für Organisationen, die mehrere Entwicklungsumgebungen parallel unterstützen müssen (DEV1, DEV2, DEVn), während eine gemeinsame, geregelte Quelle der Wahrheit in Git verwaltet wird. Jedes Entwickler- oder kleines Team kann in einer isolierten Umgebung arbeiten und Änderungen über verzweigte Workflows synchronisieren, sodass Teams zusammenarbeiten können, ohne sich auf eine einzige freigegebene Entwicklungsumgebung zu verlassen.

Geschäftswert

Der von dieser Architektur bereitgestellte Schlüsselwert umfasst:

  • Quellcodeverwaltung als Wahrheitsquelle für Lösungsanpassungen, anstatt eine Maker-Umgebung als autoritative Bereitstellungsquelle zu behandeln. Dieser Ansatz verbessert die Konsistenz und unterstützt die kontrollierte Förderung in downstream-Umgebungen.

  • Bewährte Methoden für Sicherheit, Überwachung und Compliance über den Lebenszyklus von Softwareentwicklung (SDLC), einschließlich Versionsverwaltung, Codeüberprüfungen, Änderungsablaufverfolgung und Integration in Enterprise Governance-Prozesse.

  • Parallele Entwicklung in großem Maßstab durch die Nutzung von Branches und isolierten Entwicklungsumgebungen, sodass mehrere Beitragende gleichzeitig entwickeln und iterieren können – bei geringerem Konfliktrisiko.

  • Unterstützung für kurzlebige Entwicklungsumgebungen, die es Teams ermöglichen, Umgebungen aus der Quellcodeverwaltung für Tests, Experimente und temporäre Entwicklungsszenarien zu rehydratisieren und gleichzeitig eine langfristige zu starke Umgebungsverbreitung zu reduzieren.

  • Produktivität von Fusion-Teams, die es Makers, Entwicklern und Administratoren ermöglicht, über native Quellcodeverwaltungsfunktionen direkt im Produkt zusammenzuarbeiten und dabei weiterhin im Einklang mit den DevOps-Praktiken des Unternehmens zu bleiben.

  • Betrieblicher Schutz und Wiederherstellbarkeit durch Quellcodeverwaltung, die den Versionsverlauf beibehalten und die Wiederherstellung vor vorherigen Zuständen unterstützt, wenn unbeabsichtigte Änderungen vorgenommen werden.

In dieser Architektur erweitert der KI-Agent für Release Notes diesen Mehrwert zusätzlich, indem er die operative Kommunikation verbessert und die Transparenz von Releases erhöht. Es wandelt genehmigte DevOps-Arbeitsaufgaben in standardisierte, stakeholderfreundliche Versionshinweise um, wodurch der manuelle Aufwand reduziert wird, während die Menschliche Überprüfung und Rechenschaftspflicht erhalten bleibt.

Überlegungen

Diese Überlegungen implementieren die Säulen von Power Platform Well-Architected, eine Reihe von Leitprinzipien, welche die Qualität einer Workload verbessern. Weitere Informationen finden Sie in Microsoft Power Platform Well-Architected.

Reliability

Diese Architektur verbessert die Zuverlässigkeit durch die Implementierung kontrollierter Übergabepfade und eines branch-sensitiven Release-Managements. Dieser Ansatz reduziert das Ausfallrisiko der Bereitstellung und unterstützt die Wiederherstellbarkeit bei dringenden Produktionsunterstützungsszenarien.

  • Standardisierter Bereitstellungsprozess von der Entwicklung über Test bis hin zur Produktion
  • Dedizierter Hotfix-Pfad mit Rückverfolgbarkeit des Release-Branchs
  • Wiederverwendbare Pipelinemechanismen anstelle manueller Bereitstellungen
  • Überprüfungsprüfpunkte vor der Produktionsförderung

Security

Diese Architektur wendet Sicherheit durch geringste Berechtigungen, Rollentrennung und kontrollierte Automatisierungsidentitäten an. Dieser Ansatz reduziert das Risiko nicht autorisierter Änderungen und verbessert die Verantwortlichkeit von Änderungen.

  • Rollenbasierte Zugriffssteuerung in Power Platform-Umgebungen und Azure DevOps
  • Dienstprinzipale oder verwaltete Identitäten für die Pipelineausführung
  • Eingeschränkte Produktionsbereitstellungsberechtigungen
  • Nachvollziehbare Branch-Zusammenführungs- und Release-Aktivitäten
  • Genehmigte Kanäle für die Verteilung von Veröffentlichungsnotizen

Betriebliche Effizienz

Diese Architektur punktet sehr für operative Exzellenz. Ein wiederholbares, skalierbares Releaseverwaltungsmodell verbessert die operative Exzellenz und unterstützt die bedingte Bereitstellung in mehreren Teams und Umgebungen.

  • Kodifizierte Verzweigungsstrategie (Funktions-, Haupt-, Freigabeverzweigung)
  • Prozess zur Höherstufung einer wiederholbaren Umgebung
  • Standardisiertes Muster zur Hotfixbehandlung
  • Automatische Generierung von Versionshinweisen, die in den Veröffentlichungsworkflow integriert ist
  • Reduzierte Abhängigkeit von Stammeswissen für die Freigabekommunikation

Leistungseffizienz

Diese Architektur optimiert die Effizienz des Übermittlungsprozesses mehr als die Laufzeit-App-Leistung, die für eine ALM-Referenzarchitektur geeignet ist. Durch die Unterstützung paralleler Entwicklungsdatenströme und die Reduzierung der manuellen Koordination über Releaseaktivitäten erhöht sich der Durchsatz für die Änderungsbereitstellung, während der Betriebsaufwand pro Release verringert wird.

  • Automatisierte Bereitstellung und Release-Kommunikation
  • Reduzierter manueller Koordinationsaufwand
  • Standardisierter Workflow für schnellere Veröffentlichungszyklen
  • Skalieren auf DEVn parallele Datenströme ohne Neugestaltung der Governance

Erlebnisoptimierung

Diese Architektur unterstützt einen vorhersehbaren und gut definierten Veröffentlichungsprozess in Entwicklungs-, Test- und Produktionsumgebungen, um die Zusammenarbeit zwischen Entscheidungsträgern, Entwicklern, Releasemanagern und Supportteams zu verbessern.

  • Rollenspezifische Workflows
  • Vorhersehbares Heraufstufungsmodell
  • Einheitliches Veröffentlichungsnotizformat und -timing
  • Minimierte Mehrdeutigkeit bei Übergaben zwischen Teams

Die Benutzeroberfläche wird für mehrere Benutzergruppen verbessert:

  • Entwickelnde und Erstellende durch klare Workflows für Umgebungen und Verzweigungen
  • Freigabemanager durch standardisierte Höherstufung und Rückverfolgbarkeit
  • Beteiligte im Unternehmen durch lesbare KI-unterstützte Freigabezusammenfassungen
  • Supportteams über eine definierte Hotfixroute

Verantwortungsvolle KI

  • Fairness: Die KI-Funktion fasst freigegebene Arbeitselemente des Releases zusammen. Es trifft keine Personalentscheidungen, legt die Berechtigung fest oder trifft Entscheidungen, die sich auf Kunden auswirken.

  • Zuverlässigkeit und Sicherheit: Menschliche Prüfer überprüfen Inhalte vor der Verteilung.

  • Datenschutz und Sicherheit: Der Agent verarbeitet nur Unternehmensfreigabemetadaten, die sich im Gültigkeitsbereich befinden, z. B. genehmigte Arbeitsaufgaben und Freigabekontext. Befolgen Sie die Richtlinien Ihrer Organisation zur Data Governance und für Konnektoren bei der Verarbeitung vertraulicher Daten.

  • Inklusivität: Die generierte Ausgabe unterstützt technische und nichttechnische Zielgruppen mit strukturierten Abschnitten und allgemeinverständlichen Zusammenfassungen.

  • Transparenz: Kennzeichnen Sie Versionshinweise als von KI unterstützt, und verknüpfen Sie die geprüfte maßgebliche Quelle mit den tatsächlichen Quellarbeitselementen in DevOps.

  • Verantwortung: Ein benannter Release-Verantwortlicher oder Genehmigender für Bereitstellungen bleibt für den endgültigen Inhalt eines Releases und für Entscheidungen über Bereitstellungen in der Produktion verantwortlich.

Nächste Schritte

  1. Verbinden Sie Ihre Dataverse-Entwicklungsumgebungen mit einem Git-Repository.
  2. Planen Sie Ihre Azure DevOps Organisationsstruktur und -strategie.
  3. Rufen Sie mit Copilot Studio Arbeitselemente aus DevOps ab, indem Sie Connectors als Tools verwenden.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

  • Nick Talsma, Technischer Architekt der Power Platform
  • Last updated on