React-Anwendungen automatisiert bereitstellen in Power Pages

Inhalt

• Power Pages Entwicklung und manueller Upload-Overhead
  • Manuelle vs. automatisierte Upload-Schritte
  • Interaktive Visualisierung des Deployment-Prozesses
• Power Pages Architektur mit Side-by-Side Automatisierung
• Deep-Dive in die Power Pages Workflow-Automatisierung
  • Die Logik hinter dem Deployment-Script
  • Voraussetzungen an die Power Pages Projektstruktur
  • Side-by-Side Architektur
• Essenzielle PAC CLI Befehle für den Power Pages Workflow
• Strategischer Mehrwert und Power Pages System-Entkopplung

Power Pages Entwicklung und manueller Upload-Overhead

Ein klassisches Szenario in einer hybriden Enterprise-Architektur: Wir integrieren ein maßgeschneidertes, hochgradig interaktives React-Frontend in ein bestehendes Microsoft Power Pages Portal, indem wir das kompilierte JavaScript-Bundle als „Web File“ (Webdatei) in Dataverse ablegen.

Das Problem bei diesem Ansatz ist der ineffiziente, lokale Entwicklungs- und Testzyklus. Um eine einfache Code-Änderung in der DEV-Umgebung zu überprüfen, müssen Entwickler typischerweise zeitintensive manuelle Schritte durchlaufen. Frontend lokal bauen, das Portal Management Studio öffnen, den entsprechenden Webdatei-Datensatz mühsam heraussuchen, die Datei manuell ersetzen und anschließend den Power Pages Cache leeren, um die Änderungen einsehen zu können. Dieser Weg ist fehleranfällig, unterbricht den Arbeitsfluss und kostet wertvolle Zeit.

Manuelle vs. automatisierte Upload-Schritte

Der manuelle Prozess (Ineffizient)

Der klassische Weg erfordert mehrere manuelle Zwischenschritte, die den Fokus brechen:

1. React Build lokal ausführen
2. Portal Management Studio im Browser öffnen
3. Webdatei-Datensatz mühsam suchen
4. Datei manuell hochladen/ersetzen
5. Power Pages Cache manuell leeren

Der automatisierte Prozess (Vite + PAC)

Mit dem neuen Workflow reduziert sich der Aufwand auf einen einzigen Befehl:

1. Script triggert Vite Production Build
2. Automatische Synchronisation in PAC-Ordner
3. Upload via PAC CLI API-Call
4. Sofortiges Feedback im Terminal

Interaktive Visualisierung des Deployment-Prozesses

Power Pages Architektur mit Side-by-Side Automatisierung

Um diese Ineffizienz zu beseitigen, automatisieren wir den gesamten Ablauf für den Entwickler. Die Lösung basiert auf der Kombination aus einer Side-by-Side Projektstruktur und einem passgenauen Deployment-Skript.

Wir nutzen das Tooling der Power Platform (insbesondere die PAC CLI), steuern dieses aber direkt aus dem Build-Prozess unseres Frontends (z.B. Vite). Das Ziel ist ein Single-Command-Workflow: Das Skript übernimmt den Build, synchronisiert die generierten Artefakte direkt in die passende lokale Power Pages Ordnerstruktur und pusht die Änderungen im Anschluss lückenlos per PAC CLI in die Dataverse-Umgebung. So wird wertvolle Zeit gespart und lokales Entwickeln wieder effizient.

Deep-Dive in die Power Pages Workflow-Automatisierung

Die Logik hinter dem Deployment-Script

Dieses Script ist entscheidend, um den manuellen Aufwand zu eliminieren. Es nutzt die Power Platform CLI (PAC), um deine im Frontend gebauten Artefakte direkt in die Dataverse-Webdateien zu befördern.

Ein wichtiger technischer Hinweis vorab: Die PAC CLI erstellt keine neuen Webdateien in Power Pages, sondern überschreibt lediglich existierende Datensätze. Bevor das Skript also zum ersten Mal erfolgreich ausgeführt werden kann, muss die entsprechende Webdatei manuell im Portal Management Studio angelegt und eine beliebige (Platzhalter-)Datei als Anhang hinzugefügt werden. Eine detaillierte Schritt-für-Schritt-Anleitung hierfür finden Sie in meinem Beitrag über Lokale Ressourcen in Power Pages sicher laden.

Anschließend muss zwingend ein Download der Portal-Metadaten via pac pages download durchgeführt werden. Erst durch diesen Schritt werden die lokalen YAML-Konfigurationsdateien aktualisiert und die neue Webdatei-Ressource ist dem lokalen Projekt bekannt. Ohne diese Synchronisation kann die PAC CLI das Ziel beim späteren Upload nicht korrekt auflösen. Sobald dieser initiale Datensatz lokal existiert, kann das Skript die Datei bei jedem Durchlauf gezielt ansprechen und durch den aktuellen Build ersetzen.

So fängt es an: Wir dokumentieren die manuelle Erstellung der Webdatei im Portal Management Studio als notwendigen Startpunkt, gefolgt vom pac pages download, um die Metadaten-Struktur für die spätere Automatisierung lokal verfügbar zu machen.

Der Ablauf ist klar strukturiert. Zunächst stößt das Script den Vite-Build an und erzeugt so die optimierten Produktionsdateien (JS, CSS, Assets) im /dist-Ordner. Anschließend werden diese Dateien exakt an den Pfad kopiert, den das pac pages Tool für Webdateien verwaltet. Im letzten Schritt übernimmt das Script den Upload per pac pages upload und pusht alle Änderungen automatisiert in die gewünschte Power Pages Umgebung. So wird ein konsistenter, wiederholbarer und fehlerfreier Prozess sichergestellt.

Der Ablauf im Überblick:

Voraussetzungen an die Power Pages Projektstruktur

Damit das Skript die Pfade korrekt auflösen kann, setzen wir eine Side-by-Side Ordnerstruktur voraus. Das Frontend-Projekt und der (per PAC CLI heruntergeladene) Portal-Code liegen als benachbarte Verzeichnisse vor:

Side-by-Side Architektur

/my-repository/
├── my-custom-app/               <-- Your React/Vite frontend
│   ├── dist/
│   │   └── assets/
│   │       └── my-custom-app.js <-- The built artifact
│   ├── deploy.mjs               <-- Our deployment script
│   └── package.json
└── src-portal/
  └── my-power-pages-site/     <-- The Power Pages download
    ├── website.yml          <-- Required for PAC CLI
    └── web-files/
      └── my-custom-app.js <-- The target of the copy command

Nachfolgend das kompakte Node.js-Skript, das im Root-Verzeichnis des Frontend-Projekts ausgeführt wird:

import { execSync } from 'node:child_process';
import fs from 'node:fs';
import path from 'node:path';
import { fileURLToPath } from 'node:url';

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

// Path to the built frontend artifact
const BUNDLE_SRC = path.resolve(__dirname, 'dist/assets/my-custom-app.js');

// Local download path of the portal via "pac pages download"
const PORTAL_BASE_PATH = path.resolve(__dirname, '../src-portal/my-power-pages-site');

// The exact target path of our web file in the portal
const PORTAL_DEST_PATH = path.join(PORTAL_BASE_PATH, 'web-files', 'my-custom-app.js');

try {
  console.log('[Build] Starting frontend build...');
  execSync('npm run build', { stdio: 'inherit', shell: '/bin/bash' });

  // Special logic for Power Pages web files
  let finalDestination = PORTAL_DEST_PATH;

  if (fs.existsSync(PORTAL_DEST_PATH)) {
    const stats = fs.lstatSync(PORTAL_DEST_PATH);

    if (stats.isDirectory()) {
      // If it is a folder (Power Pages metadata structure),
      // we deliberately write the file INTO the folder
      finalDestination = path.join(PORTAL_DEST_PATH, 'my-custom-app.js');
    }
  }

  console.log(`[Copy] Copying bundle to: ${finalDestination}`);
  fs.copyFileSync(BUNDLE_SRC, finalDestination);

  console.log(`[Upload] Starting PAC CLI upload for portal path: ${PORTAL_BASE_PATH}`);

  // IMPORTANT: The path must point directly to the folder containing website.yml
  execSync(`pac pages upload --path "${PORTAL_BASE_PATH}" --modelVersion 2`, {
    stdio: 'inherit',
    shell: '/bin/bash',
  });

  console.log('[Success] Deployment completed!');
} catch (error) {
  console.error('[Error] Deployment failed:');
  console.error(error.message);
  process.exit(1);
}

Essenzielle PAC CLI Befehle für den Power Pages Workflow

Für deine tägliche Arbeit mit den PAC CLI Befehlen innerhalb deines Repository-Workflows sind dies die essenziellen Kommandos:

Strategischer Mehrwert und Power Pages System-Entkopplung

Dieser Ansatz vereinfacht die Systemlandschaft immens. Anstatt das gesamte Power Platform Management zu forcieren, wo es nur wenig Mehrwert bietet, schlagen wir eine Brücke zwischen klassischen Web-Entwicklern und Power Platform-Administratoren. Das Resultat ist eine erhebliche Beschleunigung der Release-Zyklen und die Vermeidung repetitiver, manueller Uploads im Portal Management.

Der Code für die Webanwendung bleibt sauber getrennt vom Portal-Code und kann unabhängig getestet werden. Das ermöglicht eine echte Entkopplung in einer Enterprise Azure- und Dataverse-Landschaft.

(Suchen Sie nach Wegen, Ihre Frontend-Entwicklung in der Microsoft-Landschaft schneller zu machen oder Ihre Enterprise-Architektur zukunftsfähig aufzustellen? Werfen Sie einen Blick auf meine Referenzprojekte oder lassen Sie uns in einem persönlichen Gespräch klären, wie Sie Ihre Deployment-Workflows effizient automatisieren.)