Latest / M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch / Azure DevOps Pipelines für Power Platform: Stabile Deployments mit Service Principals, Validierung & Rollback (KI-Synchronfassung)

Transcript

Azure DevOps Pipelines für Power Platform: Stabile Deployments mit Service Principals, Validierung & Rollback (KI-Synchronfassung) · M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch

• 0:00
  Bereit für 10 Tage voller Microsoft 365, Co-Pilot, KI-Azure und den Vordenkern, die die Zukunft der Arbeit gestalten.
• 0:07
  Diesen Januar ist die M365-Con zurück und wir legen noch eine Schippe drauf an.
• 0:13
  Seien Sie dabei bei Live-Sessions, Praxis-Demos und Expertenwissen von MVPs und Fachleuten aus aller Welt.
• 0:18
  Keine generischen Folien, kein endloses Buzzword-Bingo.
• 0:21
  Wir gehen die echten Herausforderungen an.
• 0:23
  Co-Pilot Studio, KI-Agenten, Fabric, Sicherheit, Governance und Automatisierung.
• 0:28
  Egal ob IT-Profi, Entwickler oder Führungskraft, es gibt Sessions, die speziell für Sie konzipiert sind.
• 0:35
  An 10 vollen Tagen können Sie zahlreiche Technologien erkunden und sich mit einer globalen Community vernetzen.
• 0:40
  Schauen Sie live zu und nehmen Sie praktische Erkenntnisse mit in Ihre Organisation.
• 0:45
  Januar 2027, 10 Tage, eine Microsoft Community.
• 0:49
  Die Anmeldung ist jetzt geöffnet.
• 0:51
  Besuchen Sie m3565.com.net und sichern Sie sich noch heute Ihren Platz.
• 0:55
  Das ist m3565.net, äh...
• 1:00
  Melden Sie sich jetzt unter m355.net an.
• 1:02
  Wir sehen uns im Januar.
• 1:03
  Live by Night.
• 1:05
  Haben Sie manchmal das Gefühl, bei der Bereitstellung von Power-Plattform-Lösungen einstatt vor und zwei zurückzumachen?
• 1:09
  Wenn Sie es leid sind, dass Ihre Dataverse-Änderungen in der Qualitätssicherung scheitern oder Abhängigkeiten Ihrer Bereitstellung ruinieren,
• 1:14
  ist dieses Video genau das Richtige für Sie.
• 1:15
  Heute nehmen wir die Azure DevOps-Pipeline-Komponente für Komponente auseinander,
• 1:20
  damit Ihre Deployments wie am Schnürchen laufen und kein Glücksspiel mehr sind.
• 1:24
  Sind Sie neugierig, wie Rollbacks bei komplexer Automatisierung wirklich funktionieren?
• 1:27
  Lassen Sie uns aufdecken, was in der Dokumentation nie erwähnt wird.
• 1:30
  Manuelle Bereitstellungen versus automatisierte Pipelines hier beginnt der eigentliche Schmerz.
• 1:34
  Wenn Sie mit der Power-Plattform arbeiten, kennen Sie diesen Moment sicher.
• 1:37
  Ah.
• 1:38
  Dunnlanges Optimieren einer modellgesteuerten App, Feinschliffe in einem Power-Automate-Flow,
• 1:42
  sorgfältiges Anpassen, von Sicherheitsrollen die gesamte Checkliste.
• 1:47
  Sie haben jedes Feld doppelt geprüft, Lösungen exportieren geklickt, die ZIP-Bartei hochgeladen
• 1:50
  und gehofft, dass der neue Bild in der QA problemlos läuft.
• 1:53
  Und dann, gerade wenn sich alle offene Demo oder das Go-Live vorbereiten geht, plötzlich etwas schief.
• 1:59
  Eine Tabelle taucht nicht auf, ein Flow startet in der falschen Umgebung
• 2:02
  oder noch schlimmer, der Import schlägt mit einem kryptischen Fehlercode fehl,
• 2:05
  der nur bedeutet, dass irgendetwas nicht zusammenpasst.
• 2:10
  Der Raum wird plötzlich ganz still.
• 2:11
  Dieses bekannte ungute Gefühl im Magen macht sich breit
• 2:13
  und es geht wieder von vorne los, herausfinden was, wo und warum etwas fehlgeschlagen ist.
• 2:18
  Das ist der tägliche Alltag für Teams, die sich auf manuelle Bereitstellungen in der Power-Plattform verlassen.
• 2:22
  Sie jonglieren mit Lösungsexports auf Ihrem Desktop, verschieben ZIP-Dateien zwischen Umgebungen
• 2:26
  und nutzen manchmal alte Excel-Listen oder Teams-Chats, um festzuhalten, was wann verschoben wurde.
• 2:31
  Wenn Sie eine Anpassung vergessen, vielleicht eine neue Tabelle oder eine Verbindungsreferenz für einen Flow,
• 2:35
  ist Ihre Bereitstellung zwar halbfertig, aber komplett kaputt.
• 2:39
  Der Klassiker, es funktioniert in der Entwicklung, aber die QA hat keine Ahnung, was Sie da gerade geliefert haben.
• 2:43
  Jetzt sitzen alle bei Slack oder Teams und versuchen herauszufinden, was fehlt
• 2:46
  oder wer zuletzt die richtige Version der App exportiert hat.
• 2:49
  Manuelle Bereitstellungen sind in ihrer Anfälligkeit tückischer, als Teams erwarten.
• 2:52
  Es geht nicht nur um fehlende Schritte.
• 2:54
  Sie haben es mit Umgebungen zu tun, die über Wochen hinweg schleichend auseinanderdriften.
• 2:59
  Zuerst.
• 2:59
  In der Entwicklung kommt ein neuer Connector oder eine Berechtigung hinzu,
• 3:03
  aber niemand protokolliert es für den nächsten Rollout.
• 3:05
  Vielleicht ändert jemand die Trigger-Details eines Flows, aber nur in der Entwicklungsumgebung.
• 3:08
  Bis Sie in der Produktion ankommen, herrscht ein Flickenteppich an Konfigurationsabweichungen.
• 3:11
  Selbst wenn man versucht, alles zu dokumentieren, findet menschliches Versagen immer einen Weg hinein.
• 3:15
  Eine spätabendliche Änderung nach dem Stand-Up, eine übersehende Sicherheitsrolle
• 3:19
  oder eine manuell migrierte Umgebungsvariable.
• 3:20
  Plötzlich jagen Sie einem Problem hinterher, das vor zwei Tagen noch nicht offensichtlich war,
• 3:24
  nun aber die Nutzerakzeptanz blockiert oder Daten in einer kritischen Integration beschädigt.
• 3:28
  Oder Daten in einer kritischen Integration beschädigt.
• 3:30
  Hier ist eine Geschichte, die Ihnen wahrscheinlich bekannt vorkommt.
• 3:33
  Ein geschäftskritischer Power-Automate-Flow lief in der Entwicklung einwandfrei
• 3:36
  und verschob Zeilen zwischen Dataverse-Tabellen mithilfe neuer Verbindungsreferenzen mithilfe Rensen.
• 3:41
  Export in die Qualitätssicherung, Import sieht gut aus, aber nichts wird ausgelöst.
• 3:44
  Nachdem stundenlang Protokolle durchforstet und Berechtigungen geprüft wurden,
• 3:48
  erkennt jemand, dass die QR-Umgebung nie die richtige Verbindungsreferenz hatte.
• 3:52
  Es gibt keine Warnung im UI, nichts wird beim Importschritt markiert.
• 3:56
  Es erforderte einen tiefen Einblick in Lösungsebenen und Komponentenabhängigkeiten,
• 3:59
  während das Unternehmen fast eine Woche lang einen defekten Prozess hatte.
• 4:05
  Microsoft spricht diesen Schwachpunkt in seiner Dokumentation offen an, was fast beruhigend ist.
• 4:10
  Selbsterfahrene Administratoren, Leute, die Dataverse in- und auswendig kennen,
• 4:13
  verlieren den Überblick über versteckte Abhängigkeiten oder nuancierte Umgebungsunterschiede.
• 4:17
  Dinge, die in der Dokumentation kaum erwähnt werden, sind oft genau die, die ein Go-Live zum Scheitern bringen.
• 4:22
  Das sind keine Anfängerfehler.
• 4:24
  Sie sind die Folge einer Plattform, die zwar flexibel ist, aber im Stillen voller Querverweise und Abhängigkeiten steckt.
• 4:28
  Wenn man sich darauf verlässt, dass sich Leute jede Einstellung merken, ist es nur eine Frage der Zeit, bis etwas schief geht.
• 4:34
  Das große Versprechen lautet daher Automatisierung.
• 4:37
  Azure DevOps setzt genau hier an und verspricht manuelle, fehleranfällige Schritte in wiederholbare, nachvollziehbare und hoffentlich ausfallsichere Pipelines zu verwandeln.
• 4:46
  Die Idee sieht auf dem Papier gut aus.
• 4:49
  Sie richten eine Pipeline ein, füttern sie mit ihrer Power-Plattform und lassen sie die Schwerstarbeit erledigen.
• 4:54
  Die Lösung wird exportiert, importiert, Abhängigkeiten werden geprüft und wenn etwas fehlschlägt, erkennen sie es sofort.
• 4:59
  Sie erhalten echte, zeitgestempelte Protokolle.
• 5:02
  Sie müssen sich nicht mehr fragen, ob Alice oder Bob die neueste Kopie hat.
• 5:05
  Richtig umgesetzt ist jedes Deployment versioniert und bis zur Quelle rückverfolgbar.
• 5:09
  Kein Abhängigkeits-Rollade oder Überraschung in letzter Minute mehr.
• 5:11
  Und hier ist die Zahl, die jeder gerne in Präsentation nennt.
• 5:14
  Teams, die von manuellen Prozessen zu automatisierten Pipelines wechseln, erleben Feedback-Schleifen, die nicht nur schneller sind, sondern die meisten fehlerhaften Bereitstellungen verhindern.
• 5:24
  Natürlich passieren weiterhin Fehler, aber sie werden frühzeitig erkannt und sie verbringen keine Stunden damit, die Ursache zu finden.
• 5:29
  Noch wichtiger ist, dass sie eine Prüfbarkeit erhalten.
• 5:31
  Sie können jede Bereitstellung nachverfolgen, genau wissen, wer was veröffentlicht hat und ja, genau bestimmen, wo und wie etwas schiefgelaufen ist.
• 5:37
  Aber in Wahrheit geht es hier um Vertrauen, nicht nur um Geschwindigkeit.
• 5:40
  Wenn Ihr Team dem Bereitstellungsprozess nicht vertraut, wenn sich jede Veröffentlichung wie ein Glücksspiel anfühlt, dann ist jedes gute Feature, das Sie entwickeln, gefährdet.
• 5:47
  Interessengruppen zögern bei der Veröffentlichung.
• 5:49
  Benutzer sind frustriert über Ausfälle oder fehlende Funktionen.
• 5:51
  Das Versprechen schneller Low-Code-Innovation verpufft, wenn die letzte Meile unzuverlässig bleibt.
• 5:56
  Äh.
• 5:57
  Bei der Automatisierung geht es nicht nur darum, Zeit zu sparen oder die Führungsebene mit DevOps zu beeindrucken.
• 6:03
  Es ist der einzig realistische Weg, Power-Plattform-Lösungen bereitzustellen, die jedes Mal und in jeder Umgebung gleich funktionieren.
• 6:09
  Mit automatisierten Pipelines erhalten Sie also Vorhersehbarkeit.
• 6:12
  Sie erhalten eine zuverlässige Aufzeichnung jeder Bereitstellungsabhängigkeit und jedes ausgeführten Schrittes.
• 6:17
  Echtes CIC-CD für die Power-Plattform wird möglich und die Fehlerbehebung wird zur Sache von Protokollen, nicht von Raten.
• 6:24
  Natürlich passiert das alles nicht durch Zauberei.
• 6:27
  Automatisierung ist nur so stark wie die Verbindung zwischen Ihrer Pipeline und Ihren Umgebungen.
• 6:30
  Genau dort kann es immer noch Probleme geben.
• 6:32
  Kommen wir also als nächstes dazu, Azure DevOps so mit Ihrer Power-Plattform zu verbinden, dass es stabil und sicher ist und nicht um 3 Uhr morgens ausfällt.
• 6:43
  Der Kit, Dienstverbindungen und Agent-Pools, die nicht versagen.
• 6:46
  Wenn Sie versucht haben, Azure DevOps mit der Power-Plattform zu verbinden und zusehen mussten, wie die Pipeline sofort einen Berechtigungsfehler ausgibt oder ewig hängt, sind Sie in guter Gesellschaft.
• 6:58
  Fast jedes Team stößt irgendwann auf diese Mauer.
• 7:01
  Die Pipeline mag wunderschön gestaltet sein.
• 7:03
  Ihr Jamel mag fehlerfrei sein, aber bei nur einer falsch konfigurierten Dienstverbindung oder einer fehlenden Agent-Einstellung starren Sie auf Authentifizierungsfehler oder fragen sich, warum nichts startet.
• 7:12
  Die Realität ist, dass Power-Plattform-Bereitstellungen davon abhängen, was hinter den Kulissen passiert, was ich die unsichtbare Rohrleitung nenne.
• 7:21
  Wir sprechen von Dienstverbindungen, Authentifizierungsabläufen, Agent-Pools und all den kleinen Einstellungen, die im Stillen alles zusammenhalten oder Ihnen den Tag verderben.
• 7:29
  Seien wir ehrlich, das Konzept wirkt täuschend einfach.
• 7:32
  Sie erstellen eine Dienstverbindung in Azure DevOps, geben Anmeldeinformationen ein, verweisen auf Ihre Umgebung und kehren zum Erstellen Ihrer Flows zurück.
• 7:40
  Unter der Haube ist es jedoch ein Geflecht aus Berechtigungen, Token und API-Handshakes.
• 7:46
  Verpassen Sie ein, riskieren Sie nicht nur Ihren Pipeline-Ausfall, sondern potenziell die gesamte Integration für alle anderen, die denselben Service-Prinzipien nutzen.
• 7:53
  Das sind nicht nur Grau-Theorien.
• 7:55
  Ich habe Teams gesehen, die monatelang perfekt arbeiteten, nur um dann an einer einzigen Bereitstellung zu scheitern, die einfach nicht durchlief.
• 8:00
  Es liegt meist an einem Detail, im Hintergrund ein abgelaufenes Secret, eine fehlende Rolle beim Dienstkonto oder ein geänderter Berechtigungsumfang in Azure Active Directory.
• 8:11
  Im schlimmsten Fall sperren Sie sich oder Ihr Team versehentlich aus Umgebungen aus, wenn Sie bei der Rollenvergabe zu aggressiv vorgehen.
• 8:17
  Stellen Sie sich das Szenario vor.
• 8:18
  Sie erhalten endlich die Genehmigung, einen Service-Principle für Ihre Pipeline zu verwenden, um echte Sicherheit und Aufgabentrennung zu erreichen.
• 8:26
  Die Theorie ist sinnvoll.
• 8:27
  Sie haben eine Identität pro Umgebung und eigentlich sollte alles reibungslos funktionieren.
• 8:30
  Doch dann kommt der Takt der Bereitstellung.
• 8:32
  Sie starten Ihre Pipeline und sie scheitert bereits beim ersten Authentifizierungsschritt.
• 8:35
  Die Fehlermeldungen sind kryptisch.
• 8:37
  Sie durchsuchen die Protokolle und stellen fest, dass Sie eine winzige Dataverse-Rollenzuweisung übersehen haben.
• 8:41
  Ein einziges Häkchen fehlt und schon kann Ihr Agent nicht mehr auf die Umgebung zugreifen.
• 8:45
  Natürlich erwähnen die Protokolle das nicht explizit.
• 8:46
  Sie geben nur eine allgemeine Fehlermeldung aus und so stochern Sie um 23 im Azure-Portal herum,
• 8:52
  ändern Berechtigungen und hoffen dabei, nichts anderes kaputt zu machen.
• 8:57
  Das ist gleichermaßen frustrierend wie völlig vermeidbar.
• 9:00
  Es gibt hier ein Muster.
• 9:02
  Eine einzige fehlende Berechtigung oder eine unübliche Konfiguration kann alles blockieren.
• 9:06
  Deshalb ist es Best Practice, einen dedizierten Service-Principle zu verwenden.
• 9:10
  Und hier ist der entscheidende Punkt.
• 9:12
  Vergeben Sie nicht aus Bequemlichkeit einfach über Administratorrechte.
• 9:15
  Weisen Sie nur die minimal erforderlichen Dataverse-Rollen für die jeweilige Umgebung und Aufgabe zu.
• 9:21
  Das mag für DevOps-Neulinge übertrieben klingen, aber in der Praxis bewahrt es Sie davor, dass jemand versehentlich Daten wäscht oder beschädigt,
• 9:27
  weil ein allmächtiger Service-Principle überall Zugriff hatte.
• 9:30
  Es bedeutet auch, dass das Rotieren von Schlüsseln oder Ändern von Secret-Sauberablon.
• 9:33
  Wenn Sie eine Verbindung in der QA entziehen müssen, riskieren Sie nicht, die Produktion lahmzulegen.
• 9:39
  Teams, die an dieser Trennung festhalten, erleben selten die Panik, wenn alle Umgebungen gleichzeitig ausfallen.
• 9:45
  Kommen wir nun zu den Agent-Pools, denn, seltsamerweise, werden sie oft als zweitrangig behandelt.
• 9:50
  Sie haben zwei Hauptoptionen, von Microsoft gehostete Agenten und selbst gehostete Agenten.
• 9:54
  Die meisten Leute nehmen einfach den Standard in ihrem Azure-DevOps-Projekt und hoffen, dass es funktioniert.
• 10:02
  Für einfache .NET oder Webjobs reicht das meistens aus.
• 10:06
  Aber bei der Power-Plattform werden Sie irgendwann an eine Grenze stoßen.
• 10:09
  Von Microsoft gehostete Agenten sind gut für einfache Bildaufgaben.
• 10:12
  Aber da sie dynamisch bereitgestellt und geteilt werden, können Sie nicht garantieren, dass alle Voraussetzungen erfüllt sind.
• 10:17
  Wie bestimmte Versionen der Power-Plattform Bildtools oder benutzerdefinierte PowerShell-Module, die Sie für komplexere Lösungsaufgaben benötigen.
• 10:24
  Außerdem setzen Sie fest, wenn Sie benutzerdefinierte Software oder Integration benötigen, die nicht im Standard-Image enthalten sind.
• 10:30
  Und viel Glück bei der Fehlersuche bei isolierten Ausfällen in Umgebungen, die Ihnen nicht gehören.
• 10:34
  Selbst gehostete Agents bieten Ihnen die volle Kontrolle über die Umgebung, was Fluch und Segen zugleich ist.
• 10:39
  Einerseits können Sie Bildtools, SDKs, Skripte oder was auch immer Ihr Projekt erfordert vorinstallieren.
• 10:46
  Wenn Sie einzigartige Konnektoren oder einen stabilen Satz an Abhängigkeiten haben, kann dies jede Menge Zeit sparen.
• 10:50
  Andererseits sind Sie voll verantwortlich für Maschinen-Updates, Patches und den reibungslosen Betrieb.
• 10:56
  Agents
• 10:56
  N
• 10:57
  Dennoch bevorzugen viele Teams diesen Weg, insbesondere wenn Ihre Power-Plattform Arbeit viele benutzerdefinierte Bildschritte oder Integration umfasst,
• 11:04
  die mit den gemeinsam genutzten Microsoft-Images nicht gut funktionieren.
• 11:07
  Ein Tipp, der oft übersehen wird. Führen Sie mal einen Testlauf durch.
• 11:09
  Testen Sie Ihre Dienstverbindung und führen Sie einen Probeexport durch, bevor Sie wichtige Daten durch Ihre Pipeline jagen.
• 11:14
  Nur weil Ihre Pipeline verbunden anzeigt, heißt das nicht, dass Sie für jeden Vorgang, den Sie ausführen möchten, die richtige Zugriffsebene hat, die richtige Zugriffsebene.
• 11:21
  Dieser Testexport ist Ihr Sicherheitsnetz.
• 11:23
  Sie entdecken Berechtigungslücken, Rollenprobleme und sogar grundlegende Netzwerkstörungen, bevor Sie mitten in einer Produktionseinführung stecken.
• 11:29
  Es ist besser, dies jetzt herauszufinden, als wenn Sie gegen die Go-Live-Fristen kämpfen.
• 11:32
  Sie wollen also Zuverlässigkeit ohne Überraschungen.
• 11:35
  Robuste Dienstverbindungen und Agentpools sind das Fundament für alles, was danach kommt.
• 11:39
  Wenn Sie diese falsch einrichten, ist es egal, wie ausgefeilt Ihr Jammel oder wie schick Ihre Pipeline-Aufgaben sind.
• 11:44
  Sie werden scheitern, weil die Grundlagen nicht korrekt verbunden sind.
• 11:49
  Sobald Sie diese unsichtbare Basis im Griff haben, fügt sich der Rest des Pipeline-Prozesses viel reibungsloser und vorhersehbarer zusammen.
• 11:56
  Die Kopfschmerzen verschieben sich von, warum ist meine Pipeline nie gestartet?
• 12:00
  Hinzu, wie mache ich meine Pipeline noch intelligenter?
• 12:02
  Was ein viel angenehmeres Problem ist.
• 12:04
  Mit stabilen Verbindungen und zuverlässig laufenden Agents haben Sie gerade die erste echte Hürde genommen.
• 12:08
  Doch eine solide Basis garantiert nicht, dass Lösungsprobleme vor dem produktiven Einsatz erkannt werden.
• 12:13
  Als nächstes tauchen wir in das Thema ein, wie automatisierte Prüfungen und Validierungen Ihre Umgebungen vor stillen Fehlern schützen, bevor sie sich ausbreiten.
• 12:20
  Automatisierte Leitplanken, Abhängigkeitsprüfungen und Validierungen vor der Bereitstellung.
• 12:24
  Wenn Sie schon einmal miterlebt haben, wie eine Power-Plattform-Bereitstellung in der Entwicklung erfolgreich war,
• 12:28
  im QA-Prozess durchlief und dann im produktiven Betrieb sofort Alarm schlug, wissen Sie, worauf das hinausläuft.
• 12:33
  Wissen Sie, worauf das hinausläuft.
• 12:35
  Probleme kündigen sich fast nie im Voraus an.
• 12:39
  Stattdessen erhalten Sie diese leise verborgenen Abhängigkeiten, die tief in einer Canvas-App oder in den Zapflos einer modellgesteuerten App vergraben sind.
• 12:47
  In der Entwicklung sieht alles gut aus, aber die Produktionsumgebung mit ihren eigenen Connectors,
• 12:51
  anderen lizenzierten Benutzern oder kleinen Unterschieden bei den Dataverse-Sicherheitsrollen findet das schwache Glee sofort.
• 12:57
  Jetzt bricht Hektik aus.
• 12:58
  Manchmal ist die einzige Warnung ein Benutzer, der sagt, hey, diese Daten werden nicht aktualisiert.
• 13:02
  Oder ein Support-Ticket mit einem Stacktrace, das ist absolut keine hilfreichen Informationen.
• 13:05
  Das zugrunde liegende Problem?
• 13:07
  Niemand hat überprüft, ob alle beweglichen Teile den Transfer tatsächlich überstanden haben.
• 13:11
  Deshalb sind Abhängigkeitsprüfungen und Validierungen vor der Bereitstellung keine bloßen Nice-to-Haves.
• 13:15
  Sie sind das Immunsystem Ihrer Pipeline.
• 13:17
  Stellen Sie sich vor, Sie reisen Ihrer Bereitstellung voraus und leuchten mit einer Taschenlampe in alle Ecken, in denen sich Probleme gerne verstecken.
• 13:23
  Diese automatisierten Leitplanken erkennen Dinge wie fehlende untergeordnete Flows, abwesende Verbindungsreferenzen oder nicht verwaltete Komponenten, die nie Ihrem Export hinzugefügt wurden.
• 13:32
  Ohne diese Prüfung ist jede Bereitstellung ein Vertrauensvorschuss.
• 13:35
  Sie hoffen einfach, dass die Architektur unter Ihrer App in jeder Umgebung gleich aussieht und erfahren erst, dass dies nicht der Fall ist, wenn der Vorfallbericht in Ihrem Posteingang landet.
• 13:43
  Ich habe das schon öfter erlebt, als ich zugeben möchte.
• 13:44
  Ein Projekt hatte einen wiederkehrenden Albtraum, einen Power-Automate-Flow, der bei jedem Testlauf in der Entwicklung einwandfrei funktionierte, aber bei der Bereitstellung in der Produktion komplett verschwand.
• 13:54
  Was war passiert?
• 13:54
  Es stellte sich heraus, dass ein schneller Fix einen untergeordneten Flow als Abhängigkeit hatte und der Exportprozess bemerkte nicht, dass dieser Flow außerhalb der verwalteten Lösung lag.
• 14:02
  Als dieser untergeordnete Flow in der QR- und Produktionsumgebung fehlte, schlug die übergeordnete Logik einfach stillschweigend fehl.
• 14:08
  Kein Fehler, keine Warnung, nur ein Prozess, der sich lautlos abschaltete und benutze, die ratlos waren, warum ihre Aufgaben plötzlich feststeckten, feststeckten.
• 14:15
  Wir merkten es erst, nachdem genügend Benutzer auf fehlende Updates hinwiesen und endlich jemand das fehlende Glied fand.
• 14:21
  Bis dahin waren Stunden damit verbracht worden, XML-Export-Dateien zu durchsuchen und manuelle Prüfungen durchzuführen.
• 14:25
  Eine übersehene Abhängigkeit verursachte ein Chaos, das mit der richtigen Leitplanke hätte gemeldet werden können.
• 14:32
  Das Ärgerliche ist, wie vermeidbar das heute ist.
• 14:35
  Tools wie der Lösungschecker in der Power-Plattform ermöglichen es Ihnen, automatisierte Scans als Pipeline-Schritt einzurichten,
• 14:40
  die Sie vorab vor Problemen mit Lösungsebenen, fehlenden Abhängigkeiten, App-Performance und sogar Sicherheitsempfehlungen warnen.
• 14:49
  Die Power-Plattform-Build-Tools für Azure DevOps bringen dies noch näher an die Realität von CI-CD heran.
• 14:55
  Mit dem richtigen Pipeline-Schritt tun Sie weit mehr als nur einen einfachen Import-Slashboard.
• 14:59
  Sie führen Validierungsprüfungen sowohl für die Lösung als auch für deren Verbindungen zur Zielumgebung durch.
• 15:05
  Bei zusätzlichen Anforderungen ermöglichen benutzerdefinierte PowerShell-Skripte noch tiefere Einblicke,
• 15:10
  Sie scannen nach erforderlichen Umgebungsvariablen, validieren Verbindungen für Premium-APIs oder prüfen Berechtigungsumfänge bei AD-integrierten Flows.
• 15:20
  Interessant ist, wie viel diese automatisierten Leitplanke im Vergleich zu den alten Methoden des Exportierens und Hoffens tatsächlich abfangen,
• 15:25
  tatsächlich abfangen.
• 15:26
  Tutien aus der Community zeigen, dass diese Prüfungen bis zu 70% der Probleme identifizieren, bevor etwas live geht.
• 15:31
  Das bedeutet, weniger Anrufe nach Feierabend, weniger Aufholsprints zur Fehlerbehebung und deutlich weniger unangenehme Meetings,
• 15:38
  in denen man der Führung erklären muss, warum der Go-Live zum Reinfall wurde.
• 15:43
  Microsofts eigene Untersuchungen und Fallstudien untermauern dies.
• 15:46
  Teams, die routinemäßig eine Validierung vor der Bereitstellung durchführen,
• 15:49
  verzeichnen einen drastischen Rückgang von Produktionsfehlern
• 15:51
  und Probleme werden so früh erkannt, dass sie kaum als Vorfälle wahrgenommen werden.
• 15:54
  Ein solider Pipeline-Schritt hierfür ist unkompliziert, aber effektiv.
• 15:58
  Exportieren Sie Ihre Lösung aus der Quelle, aber starten Sie, bevor Sie sie überhaupt in die Zielumgebung importieren,
• 16:02
  eine Sequenz, die den Solution-Checker und alle von Ihnen hinzugefügten benutzerdefinierten Tests ausführt.
• 16:08
  Bleiben Sie nicht nur beim Bild stehen.
• 16:09
  Führen Sie Abfragen gegen die Produktions-Dataverse aus, um sicherzustellen,
• 16:12
  dass die Entitäten, die Sie überschreiben möchten, keine Schemaunterschiede aufweisen, die zu einem stillen Fehler führen.
• 16:17
  Validieren Sie Verbindungsreferenzen.
• 16:18
  Gehen Sie nicht davon aus, dass jeder, der in der Entwicklungs- oder QR-Umgebung Berechtigungen hatte,
• 16:21
  dieselbe Rolle in der Produktion innehat.
• 16:23
  Diese Schritte in der Pipeline sorgen dafür, dass das Skript frühzeitig abbricht, wenn etwas fehlt,
• 16:27
  und Sie erhalten hilfreiche Protokolle, die Ihnen genau zeigen, wo die Lücke liegt.
• 16:31
  Diese automatisierten Prüfungen machen den Unterschied,
• 16:33
  ob Sie Ihren Tag damit verbringen, nützliche Funktionen zu entwickeln
• 16:35
  oder Ihren Abend damit, defekte Bereitstellungen zu retten.
• 16:39
  Sie halten nicht nur die Umgebung stabil, sondern geben dem gesamten Team die Gewissheit,
• 16:42
  dass Änderungen, die die Pipeline durchlaufen,
• 16:44
  keinen entscheidenden Schritt oder eine kurzfristige Abhängigkeit ausgelassen haben.
• 16:49
  Es verwandelt den Tag der Bereitstellung von einem angespannten Ereignis in etwas Routine.
• 16:53
  Wenn jemand fragt, ist die Bereitstellung abgeschlossen?
• 16:56
  Können Sie tatsächlich mehr als ich glaube schon antworten,
• 16:57
  dass Sie die Leitplanken haben, um es zu belegen?
• 16:59
  Um es zu belegen.
• 17:01
  Es ist leicht, Prüfungen vor der Bereitstellung als bloße Formsache abzutun,
• 17:04
  aber in der Welt der Power-Plattform sparen Sie mehr Zeit und Nerven
• 17:07
  als fast jede andere Automatisierung.
• 17:10
  Anstatt von Ausfällen und Beschwerden aus rückwärts zu arbeiten,
• 17:14
  erhalten Sie proaktive Warnmeldungen frühzeitig handlungsrelevant
• 17:17
  und direkt mit den Komponenten verknüpft.
• 17:20
  Betrachten Sie sie weniger als Sicherheitsnetze, sondern eher als Radarsystem.
• 17:23
  Natürlich können die Dinge auch mit den besten Leitplanken schiefgehen.
• 17:26
  Äh, nichts ist absolut sicher und jedes Team braucht eine Möglichkeit,
• 17:29
  Änderungen rückgängig zu machen, wenn doch einmal etwas durchrutscht.
• 17:32
  Lassen Sie uns also darauf eingehen, wie ein echter Rollback- und Backup-Plan
• 17:35
  für die Power-Plattform aussieht, jenseits der Hoffnung,
• 17:38
  dass der Rückgängig-Button funktioniert.
• 17:41
  Wenn etwas kaputt geht, Aufbau einer echten Rollback- und Backup-Strategie.
• 17:45
  Lassen Sie uns darüber sprechen, was Rollback für die Power-Plattform wirklich bedeutet,
• 17:48
  denn man nimmt leicht an, dass es einen großen Rückgängig-Button gibt,
• 17:51
  der einen rettet, wenn eine Bereitstellung fehlschlägt.
• 17:55
  Doch im Gegensatz zu Code-Projekten, bei denen ein Rollback nur ein Git-Reset
• 17:58
  oder eine erneute Paketbereitstellung ist,
• 17:59
  ist die Welt der Power-Plattform weitaus weniger nachsichtig.
• 18:02
  Gerne native Optionen zum Rückgängig-Machen einer Bereitstellung.
• 18:06
  Sobald ein Import erfolgt, sind die Änderungen fest in der Umgebung verankert,
• 18:09
  Tabellen werden aktualisiert, Komponenten ändern ihre Versionen
• 18:12
  und Datenbeziehungen können sich im Hintergrund neu anordnen.
• 18:15
  Wenn während des Imports etwas schief geht,
• 18:17
  kann das Ergebnis eine halb installierte Lösung,
• 18:19
  unterbrochene Integration oder Nutzer sein,
• 18:21
  die keinen Zugriff mehr auf ihre wichtigen Apps haben.
• 18:24
  Das Risiko ist selten offensichtlich, bis es eintritt
• 18:26
  und dann erfordert die Fehlerbehebung viel Fingerspitzengefühl.
• 18:28
  Die harte Wahrheit ist, dass ein misslungene Import
• 18:31
  ihre Umgebung in einer Art Schwebezustand zurücklässt.
• 18:33
  Einige Komponenten werden möglicherweise aktualisiert,
• 18:35
  andere verbleiben auf ihrem alten Stand
• 18:37
  und Verbindungen oder Rollen können sich in einem undefinierten Zustand befinden.
• 18:41
  Konfigurationen geraten schnell aus dem Takt
• 18:43
  und sie haben ein System, das nicht mehr dem entspricht,
• 18:45
  was ursprünglich beabsichtigt war.
• 18:47
  Was wie eine kleine Anpassung in einer verwalteten Lösung aussieht,
• 18:50
  kann nachgelagerte Geschäftsprozesse komplett lahmlegen.
• 18:52
  Genau hier tappen die meisten Administratoren die Falle.
• 18:55
  Es herrscht der Eindruck, man kann den Vorgang einfach wiederholen
• 18:57
  oder einen Schritt rückgängig machen,
• 18:58
  während man in der Praxis mit einer Live-Anwendung arbeitet,
• 19:01
  auf die Nutzer für ihre tägliche Arbeit angewiesen sind.
• 19:04
  Stellen Sie sich nur die Tragweite an einen konkreten Beispiel vor.
• 19:06
  Ein großes Finanzunternehmen hatte eine neue Funktion
• 19:09
  für ihr PowerApps-Portal in der Warteschlange.
• 19:11
  Dazu einige Workflow-Anpassungen,
• 19:14
  ein paar glänzende neue Dashboards
• 19:15
  und eine neu konfigurierte Datentabelle.
• 19:16
  Die Änderung durchlief die Qualitätssicherung schnell,
• 19:19
  also gaben sie am späten Freitagabend grünes Licht
• 19:21
  für den Import in die Produktion,
• 19:23
  in der Hoffnung, alles vor der Berichtspflicht am Montag glatt zu ziehen.
• 19:25
  Der Import brach nach der Hälfte mit einem Fehler ab.
• 19:27
  Das Endergebnis, die Nutzer, die sich am Montagmorgen anmeldeten,
• 19:30
  fanden defekte Dashboards, fehlgeschlagene Automatisierungen
• 19:32
  und eine Handvoll Canvas-Apps vor, die nicht geladen werden konnten.
• 19:35
  Um das Ganze noch schlimmer zu machen,
• 19:37
  war das letzte vollständige Umgebungs-Backup bereits wochenalt
• 19:39
  und sie hatten nach den letzten Entwicklungsänderungen
• 19:41
  die aktuelle Lösungsversion nicht exportiert.
• 19:44
  Die Wiederherstellungsoptionen waren begrenzt
• 19:46
  und das Unternehmen verlor einen ganzen Arbeitstag,
• 19:48
  während die Administratoren die Umgebung mühsam wieder zusammenflicken.
• 19:50
  Kein einzelner Schritt hat das Desaster verursacht.
• 19:53
  Es war ein verpasstes Backup-Fenster,
• 19:54
  der Glaube an schnelle Lösungen
• 19:55
  und ein Mangel an flexibler Rollback-Planung,
• 19:57
  die sie ungeschützt ließen.
• 19:59
  Was können sie also konkret tun,
• 20:01
  um nicht im Rollback-Schwebe-Zustand zu landen?
• 20:04
  Die erste und zuverlässigste Ebene
• 20:05
  ist die Automatisierung von Lösungsexporten in jeder Phase.
• 20:09
  Anstatt auf die neueste Version
• 20:11
  in einem Entwicklungsordner zu vertrauen,
• 20:12
  sollte ihre Pipeline die Lösung automatisch
• 20:14
  an einen sicheren Ort exportieren,
• 20:15
  idealerweise direkt in die Versionsverwaltung.
• 20:18
  Auf diese Weise hat jede Version,
• 20:19
  ob erfolgreich oder fehlerhaft,
• 20:21
  ein entsprechendes Backup.
• 20:22
  Wenn die heutige Bereitstellung schief geht,
• 20:24
  sitzen sie nicht mit dem Fest,
• 20:25
  was zufällig auf ihrem Desktop liegt.
• 20:27
  Sie haben immer Zugriff auf das letzte,
• 20:28
  als funktionierend bekannte Paket.
• 20:30
  Nächtliche Umgebungs-Backups
• 20:31
  sind eine weitere praktische Maßnahme,
• 20:33
  selbst wenn sie glauben, sie nie zu brauchen.
• 20:35
  Microsoft bietet zwar Funktionen
• 20:36
  für vollständige Umgebungs-Backups an,
• 20:38
  besonders für Dataverse-Umgebungen,
• 20:39
  aber sie wären überrascht,
• 20:40
  wie viele Teams deren Nutzung nicht automatisieren.
• 20:42
  Die offizielle Richtlinie ist klar,
• 20:44
  erstellen sie immer ein vollständiges Umgebungs-Backup,
• 20:46
  bevor sie die Produktion anfassen.
• 20:48
  Doch in der Praxis verlassen sich viele Teams darauf,
• 20:50
  wir machen es, wenn wir daran denken.
• 20:52
  Das funktioniert genauso lange,
• 20:54
  wie man es erwartet,
• 20:54
  bis es eben nicht mehr funktioniert.
• 20:56
  Die Einrichtung nächtlicher
• 20:57
  oder vor der Bereitstellung erfolgender Backups
• 20:58
  bedeutet, dass sie einen vollständigen Snapshot
• 20:59
  zur Wiederherstellung haben,
• 21:00
  falls alles schief geht.
• 21:01
  In Kombination mit Exporten auf solutschen Ebene
• 21:04
  können sie je nach Ausmaß des Problems entscheiden,
• 21:06
  ob sie eine ganze Umgebung wiederherstellen
• 21:07
  oder nur eine einzelne Solution zurückrollen.
• 21:11
  Das Versionieren von Solution-Dateien
• 21:12
  in der Quellcode-Verwaltung mag simpel klingen,
• 21:14
  ist dabei ein Lebensretter.
• 21:15
  Das Nachverfolgen jeder exportierten ZIP-Datei
• 21:17
  mit Commit-Historie, Branch-Benennung und Pull-Requests
• 21:20
  bringt Power-Plattform-Bereitstellungen näher
• 21:21
  an klassische Anwendungslebenszyklen heran.
• 21:24
  Sie erhalten eine vollständige Auditspur darüber,
• 21:25
  was geändert wurde, wann und von wem.
• 21:27
  Wenn ein Road-Back erforderlich wird,
• 21:28
  müssen Sie nicht in Panik geraten.
• 21:30
  Stellen Sie einfach den vorherigen erfolgreichen Bild erneut bereit.
• 21:32
  Das ist nicht nur bequem.
• 21:34
  Es ist eine der zuverlässigsten Methoden,
• 21:35
  um geschäftskritische Änderungen
• 21:36
  ohne Kollateralschäden wiederherzustellen.
• 21:39
  Wenn es an der Zeit ist,
• 21:40
  ein echtes Rollback auszuführen,
• 21:42
  sind exportierte Solution-Dateien Ihre Rettungsleine.
• 21:44
  Beginnen Sie mit der Wiederherstellung
• 21:45
  der vorherigen Solution-Version,
• 21:47
  die Sie bereits in einer niedrigeren Umgebung validiert haben.
• 21:50
  Das Rollback auf diesen bekannten guten Zustand
• 21:52
  setzt Ihre Komponenten, Flows
• 21:53
  und zugehörigen Anpassungen zurück.
• 21:55
  Sie erhalten keine perfekte Zeitmaschine.
• 21:57
  Datensätze oder Transaktionsdaten,
• 21:59
  die seit der letzten Bereitstellung geändert wurden,
• 22:00
  könnten gefährdet sein, aber Sie können die App
• 22:02
  oft innerhalb einer Stunde
• 22:03
  in eine funktionierende Konfiguration zurückversetzen.
• 22:06
  Bei schwerwiegenderen Problemen
• 22:07
  wie einer beschädigten Entität,
• 22:09
  verlorenen Beziehungen oder Datenintegrationsfehlern
• 22:11
  müssen Sie möglicherweise das Umgebungs-Backup verwenden
• 22:13
  oder einzelne Tabellen wiederherstellen,
• 22:15
  je nachdem, was verfügbar ist.
• 22:18
  Eine Lektion, die man auf die harte Tour lernt?
• 22:20
  Gehen Sie niemals davon aus,
• 22:21
  dass Ihr Rollback-Plan robust ist,
• 22:22
  wenn Sie ihn nicht in einer Sandbox getestet haben.
• 22:24
  Der Unterschied zwischen einem theoretischen
• 22:26
  und einem realen Wiederherstellungsprozess ist enorm.
• 22:28
  Ohne Tests riskieren Sie,
• 22:30
  unvollständige Abhängigkeiten wiederherzustellen
• 22:31
  oder auf Importkonflikte zu stoßen,
• 22:33
  die Sie nicht vorhergesehen haben.
• 22:34
  Das Üben Ihres Rollbacks ist...
• 22:35
  Rollback System.