WEBVTT 00:00:00.270 --> 00:00:07.010 Bereit für 10 Tage voller Microsoft 365, Co-Pilot, KI-Azure und den Vordenkern, die die Zukunft der Arbeit gestalten. 00:00:07.610 --> 00:00:12.050 Diesen Januar ist die M365-Con zurück und wir legen noch eine Schippe drauf an. 00:00:13.010 --> 00:00:17.650 Seien Sie dabei bei Live-Sessions, Praxis-Demos und Expertenwissen von MVPs und Fachleuten aus aller Welt. 00:00:18.790 --> 00:00:21.030 Keine generischen Folien, kein endloses Buzzword-Bingo. 00:00:21.990 --> 00:00:23.630 Wir gehen die echten Herausforderungen an. 00:00:23.790 --> 00:00:28.450 Co-Pilot Studio, KI-Agenten, Fabric, Sicherheit, Governance und Automatisierung. 00:00:28.450 --> 00:00:34.150 Egal ob IT-Profi, Entwickler oder Führungskraft, es gibt Sessions, die speziell für Sie konzipiert sind. 00:00:35.470 --> 00:00:39.890 An 10 vollen Tagen können Sie zahlreiche Technologien erkunden und sich mit einer globalen Community vernetzen. 00:00:40.870 --> 00:00:44.210 Schauen Sie live zu und nehmen Sie praktische Erkenntnisse mit in Ihre Organisation. 00:00:45.130 --> 00:00:48.710 Januar 2027, 10 Tage, eine Microsoft Community. 00:00:49.330 --> 00:00:50.470 Die Anmeldung ist jetzt geöffnet. 00:00:51.610 --> 00:00:55.490 Besuchen Sie m3565.com.net und sichern Sie sich noch heute Ihren Platz. 00:00:55.490 --> 00:00:59.490 Das ist m3565.net, äh... 00:01:00.090 --> 00:01:02.270 Melden Sie sich jetzt unter m355.net an. 00:01:02.590 --> 00:01:03.430 Wir sehen uns im Januar. 00:01:03.650 --> 00:01:04.690 Live by Night. 00:01:05.330 --> 00:01:08.770 Haben Sie manchmal das Gefühl, bei der Bereitstellung von Power-Plattform-Lösungen einstatt vor und zwei zurückzumachen? 00:01:09.450 --> 00:01:14.030 Wenn Sie es leid sind, dass Ihre Dataverse-Änderungen in der Qualitätssicherung scheitern oder Abhängigkeiten Ihrer Bereitstellung ruinieren, 00:01:14.130 --> 00:01:15.790 ist dieses Video genau das Richtige für Sie. 00:01:15.790 --> 00:01:19.970 Heute nehmen wir die Azure DevOps-Pipeline-Komponente für Komponente auseinander, 00:01:20.090 --> 00:01:23.210 damit Ihre Deployments wie am Schnürchen laufen und kein Glücksspiel mehr sind. 00:01:24.250 --> 00:01:27.510 Sind Sie neugierig, wie Rollbacks bei komplexer Automatisierung wirklich funktionieren? 00:01:27.890 --> 00:01:29.850 Lassen Sie uns aufdecken, was in der Dokumentation nie erwähnt wird. 00:01:30.470 --> 00:01:33.790 Manuelle Bereitstellungen versus automatisierte Pipelines hier beginnt der eigentliche Schmerz. 00:01:34.790 --> 00:01:37.450 Wenn Sie mit der Power-Plattform arbeiten, kennen Sie diesen Moment sicher. 00:01:37.830 --> 00:01:38.070 Ah. 00:01:38.070 --> 00:01:42.530 Dunnlanges Optimieren einer modellgesteuerten App, Feinschliffe in einem Power-Automate-Flow, 00:01:42.710 --> 00:01:46.790 sorgfältiges Anpassen, von Sicherheitsrollen die gesamte Checkliste. 00:01:47.350 --> 00:01:50.610 Sie haben jedes Feld doppelt geprüft, Lösungen exportieren geklickt, die ZIP-Bartei hochgeladen 00:01:50.610 --> 00:01:52.690 und gehofft, dass der neue Bild in der QA problemlos läuft. 00:01:53.550 --> 00:01:58.390 Und dann, gerade wenn sich alle offene Demo oder das Go-Live vorbereiten geht, plötzlich etwas schief. 00:01:59.310 --> 00:02:02.670 Eine Tabelle taucht nicht auf, ein Flow startet in der falschen Umgebung 00:02:02.670 --> 00:02:05.530 oder noch schlimmer, der Import schlägt mit einem kryptischen Fehlercode fehl, 00:02:05.530 --> 00:02:08.350 der nur bedeutet, dass irgendetwas nicht zusammenpasst. 00:02:10.330 --> 00:02:11.470 Der Raum wird plötzlich ganz still. 00:02:11.930 --> 00:02:13.910 Dieses bekannte ungute Gefühl im Magen macht sich breit 00:02:13.910 --> 00:02:17.730 und es geht wieder von vorne los, herausfinden was, wo und warum etwas fehlgeschlagen ist. 00:02:18.250 --> 00:02:21.670 Das ist der tägliche Alltag für Teams, die sich auf manuelle Bereitstellungen in der Power-Plattform verlassen. 00:02:22.170 --> 00:02:26.270 Sie jonglieren mit Lösungsexports auf Ihrem Desktop, verschieben ZIP-Dateien zwischen Umgebungen 00:02:26.270 --> 00:02:30.850 und nutzen manchmal alte Excel-Listen oder Teams-Chats, um festzuhalten, was wann verschoben wurde. 00:02:31.930 --> 00:02:35.850 Wenn Sie eine Anpassung vergessen, vielleicht eine neue Tabelle oder eine Verbindungsreferenz für einen Flow, 00:02:35.850 --> 00:02:38.410 ist Ihre Bereitstellung zwar halbfertig, aber komplett kaputt. 00:02:39.190 --> 00:02:42.810 Der Klassiker, es funktioniert in der Entwicklung, aber die QA hat keine Ahnung, was Sie da gerade geliefert haben. 00:02:43.290 --> 00:02:46.250 Jetzt sitzen alle bei Slack oder Teams und versuchen herauszufinden, was fehlt 00:02:46.250 --> 00:02:48.810 oder wer zuletzt die richtige Version der App exportiert hat. 00:02:49.710 --> 00:02:52.550 Manuelle Bereitstellungen sind in ihrer Anfälligkeit tückischer, als Teams erwarten. 00:02:52.870 --> 00:02:54.030 Es geht nicht nur um fehlende Schritte. 00:02:54.790 --> 00:02:58.610 Sie haben es mit Umgebungen zu tun, die über Wochen hinweg schleichend auseinanderdriften. 00:02:59.070 --> 00:02:59.390 Zuerst. 00:02:59.390 --> 00:03:02.970 In der Entwicklung kommt ein neuer Connector oder eine Berechtigung hinzu, 00:03:03.050 --> 00:03:04.690 aber niemand protokolliert es für den nächsten Rollout. 00:03:05.150 --> 00:03:08.130 Vielleicht ändert jemand die Trigger-Details eines Flows, aber nur in der Entwicklungsumgebung. 00:03:08.450 --> 00:03:11.530 Bis Sie in der Produktion ankommen, herrscht ein Flickenteppich an Konfigurationsabweichungen. 00:03:11.970 --> 00:03:15.270 Selbst wenn man versucht, alles zu dokumentieren, findet menschliches Versagen immer einen Weg hinein. 00:03:15.270 --> 00:03:19.030 Eine spätabendliche Änderung nach dem Stand-Up, eine übersehende Sicherheitsrolle 00:03:19.030 --> 00:03:20.850 oder eine manuell migrierte Umgebungsvariable. 00:03:20.930 --> 00:03:24.270 Plötzlich jagen Sie einem Problem hinterher, das vor zwei Tagen noch nicht offensichtlich war, 00:03:24.490 --> 00:03:28.170 nun aber die Nutzerakzeptanz blockiert oder Daten in einer kritischen Integration beschädigt. 00:03:28.390 --> 00:03:30.350 Oder Daten in einer kritischen Integration beschädigt. 00:03:30.690 --> 00:03:32.390 Hier ist eine Geschichte, die Ihnen wahrscheinlich bekannt vorkommt. 00:03:33.190 --> 00:03:36.430 Ein geschäftskritischer Power-Automate-Flow lief in der Entwicklung einwandfrei 00:03:36.430 --> 00:03:40.850 und verschob Zeilen zwischen Dataverse-Tabellen mithilfe neuer Verbindungsreferenzen mithilfe Rensen. 00:03:41.850 --> 00:03:44.510 Export in die Qualitätssicherung, Import sieht gut aus, aber nichts wird ausgelöst. 00:03:44.510 --> 00:03:48.290 Nachdem stundenlang Protokolle durchforstet und Berechtigungen geprüft wurden, 00:03:48.390 --> 00:03:51.610 erkennt jemand, dass die QR-Umgebung nie die richtige Verbindungsreferenz hatte. 00:03:52.470 --> 00:03:55.070 Es gibt keine Warnung im UI, nichts wird beim Importschritt markiert. 00:03:56.070 --> 00:03:59.710 Es erforderte einen tiefen Einblick in Lösungsebenen und Komponentenabhängigkeiten, 00:03:59.710 --> 00:04:02.850 während das Unternehmen fast eine Woche lang einen defekten Prozess hatte. 00:04:05.150 --> 00:04:08.670 Microsoft spricht diesen Schwachpunkt in seiner Dokumentation offen an, was fast beruhigend ist. 00:04:10.030 --> 00:04:13.210 Selbsterfahrene Administratoren, Leute, die Dataverse in- und auswendig kennen, 00:04:13.210 --> 00:04:16.950 verlieren den Überblick über versteckte Abhängigkeiten oder nuancierte Umgebungsunterschiede. 00:04:17.730 --> 00:04:21.710 Dinge, die in der Dokumentation kaum erwähnt werden, sind oft genau die, die ein Go-Live zum Scheitern bringen. 00:04:22.450 --> 00:04:23.550 Das sind keine Anfängerfehler. 00:04:24.030 --> 00:04:28.430 Sie sind die Folge einer Plattform, die zwar flexibel ist, aber im Stillen voller Querverweise und Abhängigkeiten steckt. 00:04:28.430 --> 00:04:33.850 Wenn man sich darauf verlässt, dass sich Leute jede Einstellung merken, ist es nur eine Frage der Zeit, bis etwas schief geht. 00:04:34.350 --> 00:04:36.030 Das große Versprechen lautet daher Automatisierung. 00:04:37.070 --> 00:04:46.110 Azure DevOps setzt genau hier an und verspricht manuelle, fehleranfällige Schritte in wiederholbare, nachvollziehbare und hoffentlich ausfallsichere Pipelines zu verwandeln. 00:04:46.110 --> 00:04:48.870 Die Idee sieht auf dem Papier gut aus. 00:04:49.310 --> 00:04:53.210 Sie richten eine Pipeline ein, füttern sie mit ihrer Power-Plattform und lassen sie die Schwerstarbeit erledigen. 00:04:54.090 --> 00:04:59.430 Die Lösung wird exportiert, importiert, Abhängigkeiten werden geprüft und wenn etwas fehlschlägt, erkennen sie es sofort. 00:04:59.930 --> 00:05:01.910 Sie erhalten echte, zeitgestempelte Protokolle. 00:05:02.150 --> 00:05:04.550 Sie müssen sich nicht mehr fragen, ob Alice oder Bob die neueste Kopie hat. 00:05:05.390 --> 00:05:08.390 Richtig umgesetzt ist jedes Deployment versioniert und bis zur Quelle rückverfolgbar. 00:05:09.370 --> 00:05:11.730 Kein Abhängigkeits-Rollade oder Überraschung in letzter Minute mehr. 00:05:11.730 --> 00:05:14.410 Und hier ist die Zahl, die jeder gerne in Präsentation nennt. 00:05:14.970 --> 00:05:23.550 Teams, die von manuellen Prozessen zu automatisierten Pipelines wechseln, erleben Feedback-Schleifen, die nicht nur schneller sind, sondern die meisten fehlerhaften Bereitstellungen verhindern. 00:05:24.190 --> 00:05:28.930 Natürlich passieren weiterhin Fehler, aber sie werden frühzeitig erkannt und sie verbringen keine Stunden damit, die Ursache zu finden. 00:05:29.630 --> 00:05:31.130 Noch wichtiger ist, dass sie eine Prüfbarkeit erhalten. 00:05:31.570 --> 00:05:37.150 Sie können jede Bereitstellung nachverfolgen, genau wissen, wer was veröffentlicht hat und ja, genau bestimmen, wo und wie etwas schiefgelaufen ist. 00:05:37.930 --> 00:05:40.150 Aber in Wahrheit geht es hier um Vertrauen, nicht nur um Geschwindigkeit. 00:05:40.150 --> 00:05:46.770 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. 00:05:47.350 --> 00:05:48.730 Interessengruppen zögern bei der Veröffentlichung. 00:05:49.030 --> 00:05:51.410 Benutzer sind frustriert über Ausfälle oder fehlende Funktionen. 00:05:51.750 --> 00:05:56.410 Das Versprechen schneller Low-Code-Innovation verpufft, wenn die letzte Meile unzuverlässig bleibt. 00:05:56.810 --> 00:05:57.010 Äh. 00:05:57.950 --> 00:06:02.490 Bei der Automatisierung geht es nicht nur darum, Zeit zu sparen oder die Führungsebene mit DevOps zu beeindrucken. 00:06:03.530 --> 00:06:09.170 Es ist der einzig realistische Weg, Power-Plattform-Lösungen bereitzustellen, die jedes Mal und in jeder Umgebung gleich funktionieren. 00:06:09.170 --> 00:06:12.490 Mit automatisierten Pipelines erhalten Sie also Vorhersehbarkeit. 00:06:12.990 --> 00:06:16.630 Sie erhalten eine zuverlässige Aufzeichnung jeder Bereitstellungsabhängigkeit und jedes ausgeführten Schrittes. 00:06:17.970 --> 00:06:23.730 Echtes CIC-CD für die Power-Plattform wird möglich und die Fehlerbehebung wird zur Sache von Protokollen, nicht von Raten. 00:06:24.890 --> 00:06:26.470 Natürlich passiert das alles nicht durch Zauberei. 00:06:27.170 --> 00:06:30.430 Automatisierung ist nur so stark wie die Verbindung zwischen Ihrer Pipeline und Ihren Umgebungen. 00:06:30.430 --> 00:06:32.830 Genau dort kann es immer noch Probleme geben. 00:06:32.830 --> 00:06:42.070 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. 00:06:43.490 --> 00:06:46.730 Der Kit, Dienstverbindungen und Agent-Pools, die nicht versagen. 00:06:46.730 --> 00:06:57.570 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. 00:06:58.630 --> 00:07:00.670 Fast jedes Team stößt irgendwann auf diese Mauer. 00:07:01.570 --> 00:07:03.170 Die Pipeline mag wunderschön gestaltet sein. 00:07:03.730 --> 00:07:12.850 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. 00:07:12.850 --> 00:07:19.990 Die Realität ist, dass Power-Plattform-Bereitstellungen davon abhängen, was hinter den Kulissen passiert, was ich die unsichtbare Rohrleitung nenne. 00:07:21.490 --> 00:07:28.150 Wir sprechen von Dienstverbindungen, Authentifizierungsabläufen, Agent-Pools und all den kleinen Einstellungen, die im Stillen alles zusammenhalten oder Ihnen den Tag verderben. 00:07:29.630 --> 00:07:31.610 Seien wir ehrlich, das Konzept wirkt täuschend einfach. 00:07:32.970 --> 00:07:40.210 Sie erstellen eine Dienstverbindung in Azure DevOps, geben Anmeldeinformationen ein, verweisen auf Ihre Umgebung und kehren zum Erstellen Ihrer Flows zurück. 00:07:40.210 --> 00:07:45.010 Unter der Haube ist es jedoch ein Geflecht aus Berechtigungen, Token und API-Handshakes. 00:07:46.010 --> 00:07:52.810 Verpassen Sie ein, riskieren Sie nicht nur Ihren Pipeline-Ausfall, sondern potenziell die gesamte Integration für alle anderen, die denselben Service-Prinzipien nutzen. 00:07:53.770 --> 00:07:54.710 Das sind nicht nur Grau-Theorien. 00:07:55.130 --> 00:08:00.630 Ich habe Teams gesehen, die monatelang perfekt arbeiteten, nur um dann an einer einzigen Bereitstellung zu scheitern, die einfach nicht durchlief. 00:08:00.630 --> 00:08:09.750 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. 00:08:11.030 --> 00:08:16.910 Im schlimmsten Fall sperren Sie sich oder Ihr Team versehentlich aus Umgebungen aus, wenn Sie bei der Rollenvergabe zu aggressiv vorgehen. 00:08:17.910 --> 00:08:18.770 Stellen Sie sich das Szenario vor. 00:08:18.770 --> 00:08:24.890 Sie erhalten endlich die Genehmigung, einen Service-Principle für Ihre Pipeline zu verwenden, um echte Sicherheit und Aufgabentrennung zu erreichen. 00:08:26.050 --> 00:08:26.790 Die Theorie ist sinnvoll. 00:08:27.150 --> 00:08:30.130 Sie haben eine Identität pro Umgebung und eigentlich sollte alles reibungslos funktionieren. 00:08:30.390 --> 00:08:31.650 Doch dann kommt der Takt der Bereitstellung. 00:08:32.010 --> 00:08:35.210 Sie starten Ihre Pipeline und sie scheitert bereits beim ersten Authentifizierungsschritt. 00:08:35.650 --> 00:08:36.850 Die Fehlermeldungen sind kryptisch. 00:08:37.370 --> 00:08:41.470 Sie durchsuchen die Protokolle und stellen fest, dass Sie eine winzige Dataverse-Rollenzuweisung übersehen haben. 00:08:41.790 --> 00:08:44.890 Ein einziges Häkchen fehlt und schon kann Ihr Agent nicht mehr auf die Umgebung zugreifen. 00:08:45.330 --> 00:08:46.970 Natürlich erwähnen die Protokolle das nicht explizit. 00:08:46.970 --> 00:08:52.010 Sie geben nur eine allgemeine Fehlermeldung aus und so stochern Sie um 23 im Azure-Portal herum, 00:08:52.110 --> 00:08:55.810 ändern Berechtigungen und hoffen dabei, nichts anderes kaputt zu machen. 00:08:57.130 --> 00:09:00.190 Das ist gleichermaßen frustrierend wie völlig vermeidbar. 00:09:00.990 --> 00:09:01.590 Es gibt hier ein Muster. 00:09:02.270 --> 00:09:05.850 Eine einzige fehlende Berechtigung oder eine unübliche Konfiguration kann alles blockieren. 00:09:06.990 --> 00:09:09.930 Deshalb ist es Best Practice, einen dedizierten Service-Principle zu verwenden. 00:09:10.750 --> 00:09:11.730 Und hier ist der entscheidende Punkt. 00:09:12.430 --> 00:09:15.050 Vergeben Sie nicht aus Bequemlichkeit einfach über Administratorrechte. 00:09:15.050 --> 00:09:20.170 Weisen Sie nur die minimal erforderlichen Dataverse-Rollen für die jeweilige Umgebung und Aufgabe zu. 00:09:21.430 --> 00:09:26.970 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, 00:09:27.030 --> 00:09:29.410 weil ein allmächtiger Service-Principle überall Zugriff hatte. 00:09:30.990 --> 00:09:33.710 Es bedeutet auch, dass das Rotieren von Schlüsseln oder Ändern von Secret-Sauberablon. 00:09:33.710 --> 00:09:38.330 Wenn Sie eine Verbindung in der QA entziehen müssen, riskieren Sie nicht, die Produktion lahmzulegen. 00:09:39.290 --> 00:09:43.730 Teams, die an dieser Trennung festhalten, erleben selten die Panik, wenn alle Umgebungen gleichzeitig ausfallen. 00:09:45.070 --> 00:09:49.650 Kommen wir nun zu den Agent-Pools, denn, seltsamerweise, werden sie oft als zweitrangig behandelt. 00:09:50.690 --> 00:09:54.390 Sie haben zwei Hauptoptionen, von Microsoft gehostete Agenten und selbst gehostete Agenten. 00:09:54.390 --> 00:10:00.090 Die meisten Leute nehmen einfach den Standard in ihrem Azure-DevOps-Projekt und hoffen, dass es funktioniert. 00:10:02.690 --> 00:10:05.170 Für einfache .NET oder Webjobs reicht das meistens aus. 00:10:06.250 --> 00:10:08.490 Aber bei der Power-Plattform werden Sie irgendwann an eine Grenze stoßen. 00:10:09.010 --> 00:10:11.830 Von Microsoft gehostete Agenten sind gut für einfache Bildaufgaben. 00:10:12.250 --> 00:10:16.530 Aber da sie dynamisch bereitgestellt und geteilt werden, können Sie nicht garantieren, dass alle Voraussetzungen erfüllt sind. 00:10:17.350 --> 00:10:24.600 Wie bestimmte Versionen der Power-Plattform Bildtools oder benutzerdefinierte PowerShell-Module, die Sie für komplexere Lösungsaufgaben benötigen. 00:10:24.600 --> 00:10:29.840 Außerdem setzen Sie fest, wenn Sie benutzerdefinierte Software oder Integration benötigen, die nicht im Standard-Image enthalten sind. 00:10:30.360 --> 00:10:33.560 Und viel Glück bei der Fehlersuche bei isolierten Ausfällen in Umgebungen, die Ihnen nicht gehören. 00:10:34.200 --> 00:10:38.300 Selbst gehostete Agents bieten Ihnen die volle Kontrolle über die Umgebung, was Fluch und Segen zugleich ist. 00:10:39.900 --> 00:10:45.620 Einerseits können Sie Bildtools, SDKs, Skripte oder was auch immer Ihr Projekt erfordert vorinstallieren. 00:10:46.780 --> 00:10:50.940 Wenn Sie einzigartige Konnektoren oder einen stabilen Satz an Abhängigkeiten haben, kann dies jede Menge Zeit sparen. 00:10:50.940 --> 00:10:55.760 Andererseits sind Sie voll verantwortlich für Maschinen-Updates, Patches und den reibungslosen Betrieb. 00:10:56.280 --> 00:10:56.760 Agents 00:10:56.760 --> 00:10:57.580 N 00:10:57.580 --> 00:11:04.060 Dennoch bevorzugen viele Teams diesen Weg, insbesondere wenn Ihre Power-Plattform Arbeit viele benutzerdefinierte Bildschritte oder Integration umfasst, 00:11:04.340 --> 00:11:06.800 die mit den gemeinsam genutzten Microsoft-Images nicht gut funktionieren. 00:11:07.540 --> 00:11:09.480 Ein Tipp, der oft übersehen wird. Führen Sie mal einen Testlauf durch. 00:11:09.920 --> 00:11:14.220 Testen Sie Ihre Dienstverbindung und führen Sie einen Probeexport durch, bevor Sie wichtige Daten durch Ihre Pipeline jagen. 00:11:14.220 --> 00:11:20.880 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. 00:11:21.220 --> 00:11:22.900 Dieser Testexport ist Ihr Sicherheitsnetz. 00:11:23.360 --> 00:11:28.620 Sie entdecken Berechtigungslücken, Rollenprobleme und sogar grundlegende Netzwerkstörungen, bevor Sie mitten in einer Produktionseinführung stecken. 00:11:29.120 --> 00:11:32.220 Es ist besser, dies jetzt herauszufinden, als wenn Sie gegen die Go-Live-Fristen kämpfen. 00:11:32.720 --> 00:11:34.660 Sie wollen also Zuverlässigkeit ohne Überraschungen. 00:11:35.660 --> 00:11:39.240 Robuste Dienstverbindungen und Agentpools sind das Fundament für alles, was danach kommt. 00:11:39.240 --> 00:11:44.860 Wenn Sie diese falsch einrichten, ist es egal, wie ausgefeilt Ihr Jammel oder wie schick Ihre Pipeline-Aufgaben sind. 00:11:44.940 --> 00:11:47.820 Sie werden scheitern, weil die Grundlagen nicht korrekt verbunden sind. 00:11:49.440 --> 00:11:55.740 Sobald Sie diese unsichtbare Basis im Griff haben, fügt sich der Rest des Pipeline-Prozesses viel reibungsloser und vorhersehbarer zusammen. 00:11:56.860 --> 00:11:59.500 Die Kopfschmerzen verschieben sich von, warum ist meine Pipeline nie gestartet? 00:12:00.160 --> 00:12:02.000 Hinzu, wie mache ich meine Pipeline noch intelligenter? 00:12:02.500 --> 00:12:03.700 Was ein viel angenehmeres Problem ist. 00:12:04.160 --> 00:12:08.380 Mit stabilen Verbindungen und zuverlässig laufenden Agents haben Sie gerade die erste echte Hürde genommen. 00:12:08.380 --> 00:12:13.180 Doch eine solide Basis garantiert nicht, dass Lösungsprobleme vor dem produktiven Einsatz erkannt werden. 00:12:13.720 --> 00:12:19.860 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. 00:12:20.780 --> 00:12:24.280 Automatisierte Leitplanken, Abhängigkeitsprüfungen und Validierungen vor der Bereitstellung. 00:12:24.820 --> 00:12:28.380 Wenn Sie schon einmal miterlebt haben, wie eine Power-Plattform-Bereitstellung in der Entwicklung erfolgreich war, 00:12:28.460 --> 00:12:33.580 im QA-Prozess durchlief und dann im produktiven Betrieb sofort Alarm schlug, wissen Sie, worauf das hinausläuft. 00:12:33.940 --> 00:12:35.040 Wissen Sie, worauf das hinausläuft. 00:12:35.040 --> 00:12:37.300 Probleme kündigen sich fast nie im Voraus an. 00:12:39.000 --> 00:12:46.460 Stattdessen erhalten Sie diese leise verborgenen Abhängigkeiten, die tief in einer Canvas-App oder in den Zapflos einer modellgesteuerten App vergraben sind. 00:12:47.480 --> 00:12:51.760 In der Entwicklung sieht alles gut aus, aber die Produktionsumgebung mit ihren eigenen Connectors, 00:12:51.840 --> 00:12:56.760 anderen lizenzierten Benutzern oder kleinen Unterschieden bei den Dataverse-Sicherheitsrollen findet das schwache Glee sofort. 00:12:57.720 --> 00:12:58.480 Jetzt bricht Hektik aus. 00:12:58.480 --> 00:13:01.940 Manchmal ist die einzige Warnung ein Benutzer, der sagt, hey, diese Daten werden nicht aktualisiert. 00:13:02.400 --> 00:13:05.140 Oder ein Support-Ticket mit einem Stacktrace, das ist absolut keine hilfreichen Informationen. 00:13:05.840 --> 00:13:06.680 Das zugrunde liegende Problem? 00:13:07.120 --> 00:13:10.360 Niemand hat überprüft, ob alle beweglichen Teile den Transfer tatsächlich überstanden haben. 00:13:11.000 --> 00:13:14.960 Deshalb sind Abhängigkeitsprüfungen und Validierungen vor der Bereitstellung keine bloßen Nice-to-Haves. 00:13:15.700 --> 00:13:17.140 Sie sind das Immunsystem Ihrer Pipeline. 00:13:17.140 --> 00:13:22.700 Stellen Sie sich vor, Sie reisen Ihrer Bereitstellung voraus und leuchten mit einer Taschenlampe in alle Ecken, in denen sich Probleme gerne verstecken. 00:13:23.900 --> 00:13:31.720 Diese automatisierten Leitplanken erkennen Dinge wie fehlende untergeordnete Flows, abwesende Verbindungsreferenzen oder nicht verwaltete Komponenten, die nie Ihrem Export hinzugefügt wurden. 00:13:32.800 --> 00:13:35.280 Ohne diese Prüfung ist jede Bereitstellung ein Vertrauensvorschuss. 00:13:35.460 --> 00:13:42.460 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. 00:13:43.040 --> 00:13:44.780 Ich habe das schon öfter erlebt, als ich zugeben möchte. 00:13:44.780 --> 00:13:53.300 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. 00:13:54.000 --> 00:13:54.460 Was war passiert? 00:13:54.820 --> 00:14:01.440 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. 00:14:02.320 --> 00:14:08.280 Als dieser untergeordnete Flow in der QR- und Produktionsumgebung fehlte, schlug die übergeordnete Logik einfach stillschweigend fehl. 00:14:08.280 --> 00:14:15.220 Kein Fehler, keine Warnung, nur ein Prozess, der sich lautlos abschaltete und benutze, die ratlos waren, warum ihre Aufgaben plötzlich feststeckten, feststeckten. 00:14:15.540 --> 00:14:20.500 Wir merkten es erst, nachdem genügend Benutzer auf fehlende Updates hinwiesen und endlich jemand das fehlende Glied fand. 00:14:21.200 --> 00:14:25.860 Bis dahin waren Stunden damit verbracht worden, XML-Export-Dateien zu durchsuchen und manuelle Prüfungen durchzuführen. 00:14:25.860 --> 00:14:31.220 Eine übersehene Abhängigkeit verursachte ein Chaos, das mit der richtigen Leitplanke hätte gemeldet werden können. 00:14:32.180 --> 00:14:34.020 Das Ärgerliche ist, wie vermeidbar das heute ist. 00:14:35.100 --> 00:14:40.880 Tools wie der Lösungschecker in der Power-Plattform ermöglichen es Ihnen, automatisierte Scans als Pipeline-Schritt einzurichten, 00:14:40.980 --> 00:14:47.640 die Sie vorab vor Problemen mit Lösungsebenen, fehlenden Abhängigkeiten, App-Performance und sogar Sicherheitsempfehlungen warnen. 00:14:49.100 --> 00:14:54.680 Die Power-Plattform-Build-Tools für Azure DevOps bringen dies noch näher an die Realität von CI-CD heran. 00:14:55.860 --> 00:14:59.360 Mit dem richtigen Pipeline-Schritt tun Sie weit mehr als nur einen einfachen Import-Slashboard. 00:14:59.860 --> 00:15:04.000 Sie führen Validierungsprüfungen sowohl für die Lösung als auch für deren Verbindungen zur Zielumgebung durch. 00:15:05.300 --> 00:15:10.440 Bei zusätzlichen Anforderungen ermöglichen benutzerdefinierte PowerShell-Skripte noch tiefere Einblicke, 00:15:10.620 --> 00:15:19.140 Sie scannen nach erforderlichen Umgebungsvariablen, validieren Verbindungen für Premium-APIs oder prüfen Berechtigungsumfänge bei AD-integrierten Flows. 00:15:20.520 --> 00:15:25.540 Interessant ist, wie viel diese automatisierten Leitplanke im Vergleich zu den alten Methoden des Exportierens und Hoffens tatsächlich abfangen, 00:15:25.540 --> 00:15:26.420 tatsächlich abfangen. 00:15:26.620 --> 00:15:31.280 Tutien aus der Community zeigen, dass diese Prüfungen bis zu 70% der Probleme identifizieren, bevor etwas live geht. 00:15:31.680 --> 00:15:38.880 Das bedeutet, weniger Anrufe nach Feierabend, weniger Aufholsprints zur Fehlerbehebung und deutlich weniger unangenehme Meetings, 00:15:38.960 --> 00:15:42.420 in denen man der Führung erklären muss, warum der Go-Live zum Reinfall wurde. 00:15:43.860 --> 00:15:46.240 Microsofts eigene Untersuchungen und Fallstudien untermauern dies. 00:15:46.680 --> 00:15:49.400 Teams, die routinemäßig eine Validierung vor der Bereitstellung durchführen, 00:15:49.400 --> 00:15:51.440 verzeichnen einen drastischen Rückgang von Produktionsfehlern 00:15:51.440 --> 00:15:54.000 und Probleme werden so früh erkannt, dass sie kaum als Vorfälle wahrgenommen werden. 00:15:54.420 --> 00:15:57.320 Ein solider Pipeline-Schritt hierfür ist unkompliziert, aber effektiv. 00:15:58.560 --> 00:16:02.780 Exportieren Sie Ihre Lösung aus der Quelle, aber starten Sie, bevor Sie sie überhaupt in die Zielumgebung importieren, 00:16:02.980 --> 00:16:07.120 eine Sequenz, die den Solution-Checker und alle von Ihnen hinzugefügten benutzerdefinierten Tests ausführt. 00:16:08.240 --> 00:16:09.220 Bleiben Sie nicht nur beim Bild stehen. 00:16:09.760 --> 00:16:12.560 Führen Sie Abfragen gegen die Produktions-Dataverse aus, um sicherzustellen, 00:16:12.640 --> 00:16:16.300 dass die Entitäten, die Sie überschreiben möchten, keine Schemaunterschiede aufweisen, die zu einem stillen Fehler führen. 00:16:17.200 --> 00:16:18.400 Validieren Sie Verbindungsreferenzen. 00:16:18.760 --> 00:16:21.820 Gehen Sie nicht davon aus, dass jeder, der in der Entwicklungs- oder QR-Umgebung Berechtigungen hatte, 00:16:21.920 --> 00:16:23.020 dieselbe Rolle in der Produktion innehat. 00:16:23.720 --> 00:16:26.920 Diese Schritte in der Pipeline sorgen dafür, dass das Skript frühzeitig abbricht, wenn etwas fehlt, 00:16:27.020 --> 00:16:30.200 und Sie erhalten hilfreiche Protokolle, die Ihnen genau zeigen, wo die Lücke liegt. 00:16:31.280 --> 00:16:33.220 Diese automatisierten Prüfungen machen den Unterschied, 00:16:33.360 --> 00:16:35.600 ob Sie Ihren Tag damit verbringen, nützliche Funktionen zu entwickeln 00:16:35.600 --> 00:16:38.100 oder Ihren Abend damit, defekte Bereitstellungen zu retten. 00:16:39.240 --> 00:16:42.780 Sie halten nicht nur die Umgebung stabil, sondern geben dem gesamten Team die Gewissheit, 00:16:42.900 --> 00:16:44.580 dass Änderungen, die die Pipeline durchlaufen, 00:16:44.580 --> 00:16:48.540 keinen entscheidenden Schritt oder eine kurzfristige Abhängigkeit ausgelassen haben. 00:16:49.480 --> 00:16:52.700 Es verwandelt den Tag der Bereitstellung von einem angespannten Ereignis in etwas Routine. 00:16:53.380 --> 00:16:55.320 Wenn jemand fragt, ist die Bereitstellung abgeschlossen? 00:16:56.080 --> 00:16:57.920 Können Sie tatsächlich mehr als ich glaube schon antworten, 00:16:57.960 --> 00:16:59.540 dass Sie die Leitplanken haben, um es zu belegen? 00:16:59.960 --> 00:17:00.440 Um es zu belegen. 00:17:01.180 --> 00:17:04.520 Es ist leicht, Prüfungen vor der Bereitstellung als bloße Formsache abzutun, 00:17:04.680 --> 00:17:07.940 aber in der Welt der Power-Plattform sparen Sie mehr Zeit und Nerven 00:17:07.940 --> 00:17:10.060 als fast jede andere Automatisierung. 00:17:10.060 --> 00:17:14.280 Anstatt von Ausfällen und Beschwerden aus rückwärts zu arbeiten, 00:17:14.480 --> 00:17:17.240 erhalten Sie proaktive Warnmeldungen frühzeitig handlungsrelevant 00:17:17.240 --> 00:17:19.520 und direkt mit den Komponenten verknüpft. 00:17:20.360 --> 00:17:22.840 Betrachten Sie sie weniger als Sicherheitsnetze, sondern eher als Radarsystem. 00:17:23.700 --> 00:17:26.340 Natürlich können die Dinge auch mit den besten Leitplanken schiefgehen. 00:17:26.600 --> 00:17:29.600 Äh, nichts ist absolut sicher und jedes Team braucht eine Möglichkeit, 00:17:29.760 --> 00:17:32.180 Änderungen rückgängig zu machen, wenn doch einmal etwas durchrutscht. 00:17:32.180 --> 00:17:35.940 Lassen Sie uns also darauf eingehen, wie ein echter Rollback- und Backup-Plan 00:17:35.940 --> 00:17:38.040 für die Power-Plattform aussieht, jenseits der Hoffnung, 00:17:38.160 --> 00:17:39.520 dass der Rückgängig-Button funktioniert. 00:17:41.180 --> 00:17:44.460 Wenn etwas kaputt geht, Aufbau einer echten Rollback- und Backup-Strategie. 00:17:45.420 --> 00:17:48.780 Lassen Sie uns darüber sprechen, was Rollback für die Power-Plattform wirklich bedeutet, 00:17:48.780 --> 00:17:51.580 denn man nimmt leicht an, dass es einen großen Rückgängig-Button gibt, 00:17:51.660 --> 00:17:53.980 der einen rettet, wenn eine Bereitstellung fehlschlägt. 00:17:55.200 --> 00:17:58.220 Doch im Gegensatz zu Code-Projekten, bei denen ein Rollback nur ein Git-Reset 00:17:58.220 --> 00:17:59.840 oder eine erneute Paketbereitstellung ist, 00:17:59.840 --> 00:18:02.160 ist die Welt der Power-Plattform weitaus weniger nachsichtig. 00:18:02.860 --> 00:18:05.220 Gerne native Optionen zum Rückgängig-Machen einer Bereitstellung. 00:18:06.080 --> 00:18:09.200 Sobald ein Import erfolgt, sind die Änderungen fest in der Umgebung verankert, 00:18:09.300 --> 00:18:12.120 Tabellen werden aktualisiert, Komponenten ändern ihre Versionen 00:18:12.120 --> 00:18:14.800 und Datenbeziehungen können sich im Hintergrund neu anordnen. 00:18:15.500 --> 00:18:17.360 Wenn während des Imports etwas schief geht, 00:18:17.440 --> 00:18:19.220 kann das Ergebnis eine halb installierte Lösung, 00:18:19.360 --> 00:18:21.420 unterbrochene Integration oder Nutzer sein, 00:18:21.480 --> 00:18:24.020 die keinen Zugriff mehr auf ihre wichtigen Apps haben. 00:18:24.760 --> 00:18:26.560 Das Risiko ist selten offensichtlich, bis es eintritt 00:18:26.560 --> 00:18:28.660 und dann erfordert die Fehlerbehebung viel Fingerspitzengefühl. 00:18:28.660 --> 00:18:31.080 Die harte Wahrheit ist, dass ein misslungene Import 00:18:31.080 --> 00:18:32.960 ihre Umgebung in einer Art Schwebezustand zurücklässt. 00:18:33.600 --> 00:18:35.780 Einige Komponenten werden möglicherweise aktualisiert, 00:18:35.900 --> 00:18:37.360 andere verbleiben auf ihrem alten Stand 00:18:37.360 --> 00:18:40.680 und Verbindungen oder Rollen können sich in einem undefinierten Zustand befinden. 00:18:41.880 --> 00:18:43.280 Konfigurationen geraten schnell aus dem Takt 00:18:43.280 --> 00:18:45.620 und sie haben ein System, das nicht mehr dem entspricht, 00:18:45.720 --> 00:18:47.040 was ursprünglich beabsichtigt war. 00:18:47.700 --> 00:18:50.080 Was wie eine kleine Anpassung in einer verwalteten Lösung aussieht, 00:18:50.160 --> 00:18:52.560 kann nachgelagerte Geschäftsprozesse komplett lahmlegen. 00:18:52.560 --> 00:18:54.980 Genau hier tappen die meisten Administratoren die Falle. 00:18:55.500 --> 00:18:57.700 Es herrscht der Eindruck, man kann den Vorgang einfach wiederholen 00:18:57.700 --> 00:18:58.800 oder einen Schritt rückgängig machen, 00:18:58.940 --> 00:19:01.020 während man in der Praxis mit einer Live-Anwendung arbeitet, 00:19:01.140 --> 00:19:03.120 auf die Nutzer für ihre tägliche Arbeit angewiesen sind. 00:19:04.300 --> 00:19:06.260 Stellen Sie sich nur die Tragweite an einen konkreten Beispiel vor. 00:19:06.680 --> 00:19:09.040 Ein großes Finanzunternehmen hatte eine neue Funktion 00:19:09.040 --> 00:19:10.940 für ihr PowerApps-Portal in der Warteschlange. 00:19:11.140 --> 00:19:13.680 Dazu einige Workflow-Anpassungen, 00:19:14.060 --> 00:19:15.360 ein paar glänzende neue Dashboards 00:19:15.360 --> 00:19:16.560 und eine neu konfigurierte Datentabelle. 00:19:16.560 --> 00:19:19.880 Die Änderung durchlief die Qualitätssicherung schnell, 00:19:19.980 --> 00:19:21.780 also gaben sie am späten Freitagabend grünes Licht 00:19:21.780 --> 00:19:22.940 für den Import in die Produktion, 00:19:23.040 --> 00:19:25.040 in der Hoffnung, alles vor der Berichtspflicht am Montag glatt zu ziehen. 00:19:25.720 --> 00:19:27.520 Der Import brach nach der Hälfte mit einem Fehler ab. 00:19:27.860 --> 00:19:30.200 Das Endergebnis, die Nutzer, die sich am Montagmorgen anmeldeten, 00:19:30.320 --> 00:19:32.520 fanden defekte Dashboards, fehlgeschlagene Automatisierungen 00:19:32.520 --> 00:19:34.860 und eine Handvoll Canvas-Apps vor, die nicht geladen werden konnten. 00:19:35.780 --> 00:19:36.920 Um das Ganze noch schlimmer zu machen, 00:19:37.000 --> 00:19:39.660 war das letzte vollständige Umgebungs-Backup bereits wochenalt 00:19:39.660 --> 00:19:41.280 und sie hatten nach den letzten Entwicklungsänderungen 00:19:41.280 --> 00:19:43.200 die aktuelle Lösungsversion nicht exportiert. 00:19:44.540 --> 00:19:46.240 Die Wiederherstellungsoptionen waren begrenzt 00:19:46.240 --> 00:19:47.960 und das Unternehmen verlor einen ganzen Arbeitstag, 00:19:48.040 --> 00:19:50.160 während die Administratoren die Umgebung mühsam wieder zusammenflicken. 00:19:50.820 --> 00:19:52.700 Kein einzelner Schritt hat das Desaster verursacht. 00:19:53.300 --> 00:19:54.580 Es war ein verpasstes Backup-Fenster, 00:19:54.680 --> 00:19:55.720 der Glaube an schnelle Lösungen 00:19:55.720 --> 00:19:57.560 und ein Mangel an flexibler Rollback-Planung, 00:19:57.620 --> 00:19:58.560 die sie ungeschützt ließen. 00:19:59.760 --> 00:20:01.020 Was können sie also konkret tun, 00:20:01.100 --> 00:20:02.780 um nicht im Rollback-Schwebe-Zustand zu landen? 00:20:04.140 --> 00:20:05.640 Die erste und zuverlässigste Ebene 00:20:05.640 --> 00:20:08.400 ist die Automatisierung von Lösungsexporten in jeder Phase. 00:20:09.860 --> 00:20:11.020 Anstatt auf die neueste Version 00:20:11.020 --> 00:20:12.560 in einem Entwicklungsordner zu vertrauen, 00:20:12.560 --> 00:20:14.400 sollte ihre Pipeline die Lösung automatisch 00:20:14.400 --> 00:20:15.620 an einen sicheren Ort exportieren, 00:20:15.620 --> 00:20:17.440 idealerweise direkt in die Versionsverwaltung. 00:20:18.320 --> 00:20:19.640 Auf diese Weise hat jede Version, 00:20:19.780 --> 00:20:20.980 ob erfolgreich oder fehlerhaft, 00:20:21.060 --> 00:20:21.980 ein entsprechendes Backup. 00:20:22.680 --> 00:20:24.200 Wenn die heutige Bereitstellung schief geht, 00:20:24.280 --> 00:20:25.220 sitzen sie nicht mit dem Fest, 00:20:25.300 --> 00:20:26.500 was zufällig auf ihrem Desktop liegt. 00:20:27.340 --> 00:20:28.500 Sie haben immer Zugriff auf das letzte, 00:20:28.580 --> 00:20:29.720 als funktionierend bekannte Paket. 00:20:30.600 --> 00:20:31.700 Nächtliche Umgebungs-Backups 00:20:31.700 --> 00:20:33.180 sind eine weitere praktische Maßnahme, 00:20:33.300 --> 00:20:34.680 selbst wenn sie glauben, sie nie zu brauchen. 00:20:35.660 --> 00:20:36.900 Microsoft bietet zwar Funktionen 00:20:36.900 --> 00:20:38.320 für vollständige Umgebungs-Backups an, 00:20:38.400 --> 00:20:39.540 besonders für Dataverse-Umgebungen, 00:20:39.540 --> 00:20:40.340 aber sie wären überrascht, 00:20:40.400 --> 00:20:42.180 wie viele Teams deren Nutzung nicht automatisieren. 00:20:42.180 --> 00:20:44.600 Die offizielle Richtlinie ist klar, 00:20:44.700 --> 00:20:46.560 erstellen sie immer ein vollständiges Umgebungs-Backup, 00:20:46.620 --> 00:20:47.620 bevor sie die Produktion anfassen. 00:20:48.620 --> 00:20:50.500 Doch in der Praxis verlassen sich viele Teams darauf, 00:20:50.580 --> 00:20:51.900 wir machen es, wenn wir daran denken. 00:20:52.880 --> 00:20:53.940 Das funktioniert genauso lange, 00:20:54.000 --> 00:20:54.500 wie man es erwartet, 00:20:54.620 --> 00:20:55.560 bis es eben nicht mehr funktioniert. 00:20:56.140 --> 00:20:57.000 Die Einrichtung nächtlicher 00:20:57.000 --> 00:20:58.460 oder vor der Bereitstellung erfolgender Backups 00:20:58.460 --> 00:20:59.760 bedeutet, dass sie einen vollständigen Snapshot 00:20:59.760 --> 00:21:00.520 zur Wiederherstellung haben, 00:21:00.580 --> 00:21:01.180 falls alles schief geht. 00:21:01.880 --> 00:21:04.060 In Kombination mit Exporten auf solutschen Ebene 00:21:04.060 --> 00:21:06.000 können sie je nach Ausmaß des Problems entscheiden, 00:21:06.000 --> 00:21:07.700 ob sie eine ganze Umgebung wiederherstellen 00:21:07.700 --> 00:21:10.220 oder nur eine einzelne Solution zurückrollen. 00:21:11.340 --> 00:21:12.780 Das Versionieren von Solution-Dateien 00:21:12.780 --> 00:21:14.340 in der Quellcode-Verwaltung mag simpel klingen, 00:21:14.440 --> 00:21:15.220 ist dabei ein Lebensretter. 00:21:15.660 --> 00:21:17.660 Das Nachverfolgen jeder exportierten ZIP-Datei 00:21:17.660 --> 00:21:20.000 mit Commit-Historie, Branch-Benennung und Pull-Requests 00:21:20.000 --> 00:21:21.900 bringt Power-Plattform-Bereitstellungen näher 00:21:21.900 --> 00:21:23.720 an klassische Anwendungslebenszyklen heran. 00:21:24.200 --> 00:21:25.720 Sie erhalten eine vollständige Auditspur darüber, 00:21:25.780 --> 00:21:26.860 was geändert wurde, wann und von wem. 00:21:27.440 --> 00:21:28.620 Wenn ein Road-Back erforderlich wird, 00:21:28.700 --> 00:21:29.760 müssen Sie nicht in Panik geraten. 00:21:30.240 --> 00:21:32.260 Stellen Sie einfach den vorherigen erfolgreichen Bild erneut bereit. 00:21:32.260 --> 00:21:33.480 Das ist nicht nur bequem. 00:21:34.040 --> 00:21:35.580 Es ist eine der zuverlässigsten Methoden, 00:21:35.660 --> 00:21:36.760 um geschäftskritische Änderungen 00:21:36.760 --> 00:21:38.580 ohne Kollateralschäden wiederherzustellen. 00:21:39.380 --> 00:21:40.240 Wenn es an der Zeit ist, 00:21:40.320 --> 00:21:41.660 ein echtes Rollback auszuführen, 00:21:42.120 --> 00:21:44.280 sind exportierte Solution-Dateien Ihre Rettungsleine. 00:21:44.920 --> 00:21:45.980 Beginnen Sie mit der Wiederherstellung 00:21:45.980 --> 00:21:47.160 der vorherigen Solution-Version, 00:21:47.220 --> 00:21:49.440 die Sie bereits in einer niedrigeren Umgebung validiert haben. 00:21:50.520 --> 00:21:52.260 Das Rollback auf diesen bekannten guten Zustand 00:21:52.260 --> 00:21:53.720 setzt Ihre Komponenten, Flows 00:21:53.720 --> 00:21:55.160 und zugehörigen Anpassungen zurück. 00:21:55.640 --> 00:21:57.160 Sie erhalten keine perfekte Zeitmaschine. 00:21:57.760 --> 00:21:59.260 Datensätze oder Transaktionsdaten, 00:21:59.300 --> 00:22:00.880 die seit der letzten Bereitstellung geändert wurden, 00:22:00.880 --> 00:22:02.420 könnten gefährdet sein, aber Sie können die App 00:22:02.420 --> 00:22:03.360 oft innerhalb einer Stunde 00:22:03.360 --> 00:22:05.340 in eine funktionierende Konfiguration zurückversetzen. 00:22:06.540 --> 00:22:07.800 Bei schwerwiegenderen Problemen 00:22:07.800 --> 00:22:09.040 wie einer beschädigten Entität, 00:22:09.180 --> 00:22:11.320 verlorenen Beziehungen oder Datenintegrationsfehlern 00:22:11.320 --> 00:22:13.920 müssen Sie möglicherweise das Umgebungs-Backup verwenden 00:22:13.920 --> 00:22:15.460 oder einzelne Tabellen wiederherstellen, 00:22:15.560 --> 00:22:16.800 je nachdem, was verfügbar ist. 00:22:18.080 --> 00:22:19.780 Eine Lektion, die man auf die harte Tour lernt? 00:22:20.140 --> 00:22:21.080 Gehen Sie niemals davon aus, 00:22:21.120 --> 00:22:22.280 dass Ihr Rollback-Plan robust ist, 00:22:22.340 --> 00:22:24.100 wenn Sie ihn nicht in einer Sandbox getestet haben. 00:22:24.840 --> 00:22:26.200 Der Unterschied zwischen einem theoretischen 00:22:26.200 --> 00:22:28.180 und einem realen Wiederherstellungsprozess ist enorm. 00:22:28.180 --> 00:22:30.140 Ohne Tests riskieren Sie, 00:22:30.200 --> 00:22:31.780 unvollständige Abhängigkeiten wiederherzustellen 00:22:31.780 --> 00:22:33.120 oder auf Importkonflikte zu stoßen, 00:22:33.160 --> 00:22:34.140 die Sie nicht vorhergesehen haben. 00:22:34.620 --> 00:22:35.180 Das Üben Ihres Rollbacks ist... 00:22:35.180 --> 00:22:35.640 Rollback System.