Automatisieren von Bereitstellungen mit 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 Funktionszweige, und führen Sie sie in der Git-Hauptzweige zusammen, indem Sie Pullanforderungen und Branch-Schutzrichtlinien verwenden, wenn Sie bereit für die Übermittlung an den ALM-Pfad für Produktionstests sind.

  4. Um Funktionsabweichungen zu vermeiden, ziehen Sie änderungen, die in die Hauptverzweigung aufgenommen werden, in Verzweigungen, die allen Entwicklungsumgebungen entsprechen.

  5. Stellen Sie sicher, dass der Hauptzweig zur autoritativen Quelle für integrations- und release-Promotion wird.

Test- und Validierungsworkflow

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

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

  3. Fördern Sie nach der Überprüfung die Lösung zur Benutzerakzeptanztestumgebung (User Acceptance Test, UAT), indem Sie Pipelines in Power Platform verwenden. Erstellen oder aktualisieren Sie die entsprechende Release-Verzweigung in Git aus der Hauptzweigung.

  4. Generieren Sie Versionshinweise aus DevOps-Arbeitselementen in einem UAT-Status und verteilen Sie sie an verantwortliche Tester der UAT. Verwenden Sie einen Copilot Studio-Agent, um diese Versionshinweise mithilfe der Aktion Azure DevOps Abfrageergebnis-Connectoraktion zu generieren und zu formatieren.

  5. Stellen Sie sicher, dass UAT vor der Produktionsgenehmigung Überprüfungen und Freigabebereitschaftsprüfungen unterstützt.

Produktionsfreigabeworkflow

  1. Fördern Sie genehmigte UAT-Änderungen an der Produktion mithilfe von Pipelines in Power Platform.

  2. Generieren Sie Versionshinweise erneut aus DevOps-Arbeitselementen nach Status für die standardisierte Releasekommunikation.

  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 dem aktuellen Git Release Branch für die Produktion über die Dataverse Git-Integration.

  3. Bewerben Sie überprüfte Hotfixes zur Produktion über denselben kontrollierten Pipelinemechanismus.

  4. Führen Sie Hotfixänderungen aus der Release-Verzweigung in die Hauptverzweigung zurück, 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.

Git-Integration in Power Platform

Role in architecture:Microsoft Dataverse Git-Integration synchronisiert Lösungsänderungen mit und von Entwicklungsumgebungen in gitbasierte Quellcodeverwaltung.

Warum gewählt:

  • Aktiviert quellgestützte ALM für Dataverse-Lösungsressourcen
  • Unterstützt die zusammenarbeit mit zweigbasierten Teams
  • Reduziert die manuelle Export- und Importbehandlung

Azure Repos, Verzweigungen und Arbeitsaufgaben

Role in architecture:Azure DevOps hostet Haupt-, Feature- und Release-Branches und erzwingt pull request (PR)-Governance. Außerdem werden Arbeitsaufgaben gespeichert und als strukturierte Quelle für Den Freigabebereich und Änderungszusammenfassungen fungiert.

Warum gewählt:

  • Umfasst starke Steuerelemente für Unternehmensrichtlinien, z. B. PR-Genehmigungen, Zweigschutz und Überwachungspfade
  • Ermöglicht die systemeigene Ausrichtung mit Arbeitsaufgaben und Freigabegovernancen
  • Stellt eine konsistente Releasebereichsdefinition bereit.
  • Unterstützt die automatisierte Filterung von releasefertigen Elementen
  • Verbessert die Rückverfolgbarkeit zwischen Codeänderungen und kommunizierten Freigabeinhalten.

Alternatives als: GitHub für coderepositorys und projektarbeitselemente

Why this architecture favorisiert Azure DevOps:
Obwohl GitHub Projekte flexible Arbeitsnachverfolgung bereitstellen können, z. B. benutzerdefinierte Felder, Roadmapansichten und Automatisierung, umfasst diese Architektur Azure Boards als autoritative Freigabearbeitselementquelle. Azure Boards bietet derzeit eine stärkere Prozessmodellierung von Arbeitsaufgaben für Unternehmen, freigegebene Abfragen und WIQL-basierte Freigabedefinitionen sowie umfassendere integrierte Entwicklungs- und Bereitstellungsablaufverfolgung für geregelte Releasevorgänge.

Pipelines in Power Platform

Rolle in architektur:Pipelines in Power Platform fördern Lösungen in allen Umgebungen, einschließlich Hotfix-Heraufstufungspfade.

Warum gewählt:

  • Native Power Platform-Bereitstellung
  • Umgebungsfähige Bereitstellungs-Orchestrierung
  • Zugriff auf Plattformadministratoren und Lösungsteams

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-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 im großen Maßstab mithilfe von Verzweigungen und isolierten Entwicklungsumgebungen, sodass mehrere Mitwirkende gleichzeitig mit weniger Kollisionsrisiko erstellen und durchlaufen können.

  • 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 die langfristige Umgebungsverteilung zu reduzieren.

  • Die Produktivität des Fusion-Teams ermöglicht es Entwicklern, Entwicklern und Administratoren, über systemeigene Produkt-Quellcodeverwaltungserfahrungen zusammenzuarbeiten und gleichzeitig die DevOps-Praktiken des Unternehmens anzupassen.

  • 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-Release-Agent diesen Wert zusätzlich, indem die operative Kommunikation verbessert und Transparenz freigegeben wird. 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, indem kontrollierte Heraufsufungspfade und verzweigte Freigabebehandlung implementiert werden. Dieser Ansatz reduziert das Ausfallrisiko der Bereitstellung und unterstützt die Wiederherstellbarkeit bei dringenden Produktionsunterstützungsszenarien.

  • Standardisierte Bereitstellungsentwicklung von Entwicklung zu Test zu Produktion
  • Dedizierter Hotfixpfad mit Release Branch-Ablaufverfolgung
  • 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
  • Überprüfbare Verzweigungs- und Freigabeaktivitä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 Zweigstrategie (Feature, Hauptversion)
  • Prozess zur Heraufwertung einer wiederholbaren Umgebung
  • Standardisiertes Hotfixbehandlungsmuster
  • 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 Freigabekommunikation
  • Reduzierter manueller Koordinationsaufwand
  • Standardisierter Workflow für schnellere Veröffentlichungszyklen
  • Skalierung auf DEVn parallele Streams ohne Governance-Neugestaltung

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.

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

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

  • Entwickler und Hersteller durch klare Umgebungs - und Zweigworkflows
  • Release-Manager durch standardisierte Werbung und Rückverfolgbarkeit
  • Geschäftsbeteiligte durch lesbare KI-unterstützte Releasezusammenfassungen
  • Supportteams über eine definierte Hotfixroute

Verantwortungsvolle KI

  • Fairness: Die KI-Funktion fasst genehmigte Arbeitsaufgaben 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 Datengovernance- und Connectorrichtlinien Ihrer Organisation für die Verarbeitung vertraulicher Daten.

  • Inklusive: Die generierte Ausgabe unterstützt technische und nicht technische Zielgruppen mit strukturierten Abschnitten und Nur-Sprache-Zusammenfassungen.

  • Transparenz: Anmerkungen zur Veröffentlichung von Bezeichnungen als KI-unterstützt und verknüpfen die überprüfte Wahrheitsquelle mit den tatsächlichen Quellarbeitselementen in DevOps.

  • Verantwortlichkeit: Ein benannter Releasebesitzer oder genehmigende Bereitstellungsberechtigter bleibt für endgültige Freigabeinhalte und Produktionsbereitstellungsentscheidungen verantwortlich.

Nächste Schritte

  1. Verbinden Sie Ihre Dataverse-Entwicklungsumgebungen mit einem Git-Repository.
  2. Planen Sie Ihre Azure DevOps Organisationsstruktur und -strategie.
  3. Ziehen Sie Arbeitsaufgaben aus DevOps mit Copilot Studio, 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