Latest / M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch / Power Platform ALM mit GitHub Actions: Quelle, Build, Test und Bereitstellung ohne Rätselraten (KI-Synchronfassung)

Transcript

Power Platform ALM mit GitHub Actions: Quelle, Build, Test und Bereitstellung ohne Rätselraten (KI-Synchronfassung) · M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch

• 0:00
  Bereit für 10 Tage Microsoft 365, Co-Pilot, KI-Azure und die Menschen, die die Zukunft der Arbeit gestalten?
• 0:07
  Diesen Januar ist die M35565-Con zurück und zwar noch größer, größer.
• 0:12
  Seien Sie dabei bei Live-Sessions, Demos aus der Praxis und praktischem Wissen von MVPs und Branchenexperten aus aller Welt.
• 0:18
  Keine generischen Folien, keine endlosen Schlagworte.
• 0:21
  Wir stellen uns den echten Herausforderungen.
• 0:23
  Co-Pilot Studio, KI-Agents, Fabric, Sicherheit, Governance und Automatisierung.
• 0:28
  Ganz gleich, ob es IT-Experte, Entwickler oder Führungskraftsinn es gibt, für Sie konzipierte Sessions.
• 0:35
  An 10 vollen Tagen können Sie verschiedene Technologien kennenlernen und sich mit einer globalen Community vernetzen.
• 0:40
  Sehen Sie sich die Live-Übertragung an und nehmen Sie praktische Einblicke mit nach Hause in Ihr Unternehmen.
• 0:45
  Januar 2027, 10 Tage, eine Microsoft Community. Die Registrierung ist ab sofort möglich.
• 0:51
  Gehen Sie noch heute zu Ihrem Standort.
• 0:54
  Allerjams. Das ist M300 im Fumfunkt.net.jum.
• 1:00
  Melden Sie sich jetzt unter M300 im Fumfunkt.net an und wir sehen uns im Januar live.
• 1:03
  Haben Sie, haben Sie.
• 1:05
  Jemals das Gefühl gehabt, dass Ihre Power-Plattform-Bereitstellungen eine Blackbox sind?
• 1:08
  Liefern Sie ein Update aus? Halten den Atem an und hoffen einfach, dass es in Entwicklung, Test und Produktion funktioniert?
• 1:12
  Was wäre, wenn Sie mithilfe von GitHub-Actions jede Phase Ihres ALM-Prozesses tatsächlich steuern und einsehen könnten, ohne dass Sie mehr raten oder manuell nachbessern müssen?
• 1:21
  Lassen Sie uns einen Blick hinter die Kulissen werfen und sehen, wie die einzelnen Komponenten, Quellcode-Verwaltungen, Automatisierungen und sicheren Variablen wirklich miteinander verbunden sind.
• 1:28
  Dies ist nicht einfach eine weitere Anleitung.
• 1:30
  Genau das wird in den meisten Anleitungen ausgelassen, damit Sie bei Ihrer nächsten Bereitstellung nicht im Ungewissen bleiben.
• 1:34
  Warum sich Power-Plattform-ALM wie ein Labyrinth anfühlt?
• 1:38
  Wenn Sie schon einmal versucht haben, eine Power-App bereitzustellen und dabei diese schleichende Unsicherheit verspürt haben, als ob Ihnen etwas Wichtiges durch die Maschen geschlüpft sein muss, sind Sie nicht allein.
• 1:45
  Muss sind Sie nicht alle.
• 1:46
  Auf dem Papier verspricht Power-Plattform eine einfache App-Entwicklung, aber hinter dieser freundlichen Fassade ist ALM alles andere als unkompliziert.
• 1:53
  Eine Web-App wird aus der Quellcode-Verwaltung bereitgestellt, in einer Pipeline erstellt und landet mit vorhersehbarem Verhalten in der Produktion.
• 1:59
  Power-Plattform hingegen versteckt die Hälfte der Logik in Drag-and-Drop-Benutzeroberflächen,
• 2:04
  Connector-Bildschirmen und Formeln, die man in keinem Git-Repository sieht, die man...
• 2:08
  Selbst wenn Sie also jeden Schritt dieser allgemeinen Administrator-Handbücher befolgen, stoßen Sie immer noch auf seltsame, schwer zu diagnostizierende Fehler,
• 2:15
  sobald geschäftskritische Apps die Entwicklung verlassen.
• 2:17
  Werfen wir einen Blick auf die kursierenden ALM-Handbücher.
• 2:19
  Die meisten von ihnen führen Sie durch den Export einer Lösungs-ZIP-Datei und den Import an einer anderen Stelle.
• 2:24
  Einfach genug, oder?
• 2:25
  Aber das Wie ist nur eine Ebene.
• 2:27
  Was Sie auslassen, ist das Warum.
• 2:29
  Warum funktioniert die Power-Plattform-Bereitstellung auf eine Weise, wie es bei normalem Code nie der Fall ist?
• 2:33
  Das sorgt für endlose Verwirrung.
• 2:35
  Die Wurzel des Problems ist, dass Logik, Verbindungen und Konfigurationen in Power-Apps nicht wie klassischer Code gespeichert werden.
• 2:42
  Sie klonen nicht einfach nur ein Repository und beobachten die Komponenten-Tests.
• 2:45
  Wenn Sie also versuchen, Ihre App zu verschieben, werden all diese versteckten Abhängigkeiten, Verbindungen zu Outlook, SharePoint und benutzerdefinierten APIs nicht immer ordentlich in dieser ZIP-Datei übertragen.
• 2:54
  Hier ist das Szenario.
• 2:55
  Sie erhalten eine nagelneue App, die in der Entwicklungsumgebung funktioniert.
• 2:58
  Sie exportieren eine Lösung, importieren sie zum Testen und plötzlich funktioniert der Flow nicht mehr.
• 3:01
  Es handelt sich selten um ein Dateiproblem.
• 3:03
  Stattdessen verweisen Verbindungen auf den falschen Ort, Berechtigungen stimmen nicht überein und Datenrichtlinien blockieren Verbindungen, die vor ein paar Minuten noch in Ordnung schienen.
• 3:12
  Stellen Sie sich nun vor, Sie tun dies in drei Umgebungen, Entwicklung, Test und Produktion.
• 3:16
  Wobei jede Umgebung unterschiedliche Verbindungen, Datenschutzrichtlinien, Genehmiger und Administratoren verwendet.
• 3:21
  Sie können sich da nicht einfach durch Kopieren und Einflüge herausreden.
• 3:24
  Die Forschung bestätigt, was Administratoren und Entwickler jede Woche sehen.
• 3:26
  Die meisten fehlgeschlagenen Power-Plattform-Bereitstellungen sind auf fehlende Connector-Verweise oder schlecht verwaltete Umgebungsvariablen zurückzuführen.
• 3:34
  Ein fehlender Connector-Verweis bedeutet lediglich, dass der Flow seine Outlook- oder Dataverse-Verbindung nicht finden kann.
• 3:40
  Sobald Sie also versuchen, Ihre App oder Ihren Flow in einer anderen Umgebung auszuführen, erhalten Sie Laufzeitfehler.
• 3:47
  Und da Umgebungsvariablen in Power-Plattformen anders funktionieren als in anderen Microsoft 365-Produkten, bringen Sie selbst erfahrene Entwickler zum Stolpern.
• 3:54
  Variablen sind für die Verarbeitung von Endpunkten Schlüsseln oder mandantenspezifischen Konfigurationen vorgesehen.
• 4:00
  Wenn jedoch jemand vergisst, sie nach dem Exportieren einer Projektmappe zu aktualisieren, kann selbst eine harmlos aussehende Änderung eine Live-App zum Abschluss bringen.
• 4:06
  Viele von uns tappen zunächst in dieselbe Falle.
• 4:09
  Man könnte meinen, dass beim Exportieren einer Projektmappe in ZIP-Datei alles Notwendige gebündelt ist, aber tatsächlich werden dynamische Connector-Referenzen übersprungen.
• 4:15
  Angenommen, Sie haben eine App, die ein HTTP-Connector für einen Drittanbieterdienst in der Entwicklung verwendet.
• 4:19
  Wenn Sie diese in die Test- oder Produktionsphase importieren, ist genau diese Connector-Instanz nicht vorhanden.
• 4:23
  Der Connector-Verweis in Ihrer App verweist auf ein fehlendes Objekt und die Abläufe.
• 4:27
  In der Projektmappe werden stillschweigend unterbrochen, bis ein Benutzer oder Administrator die Verbindungen manuell neu erstellt und neu zuordnet.
• 4:34
  Wenn Sie mehr als einen Ersteller oder Administrator haben, kann man noch leichter den Überblick darüber verlieren, welcher Verweis wohin gehört und niemand möchte, ein Postmortem Ergebnis es hat in der Entwicklung funktioniert.
• 4:44
  Ein weiteres Problem. Dienstprinzipale.
• 4:47
  Die meisten Leute verwenden zunächst Benutzerkonten, um Projektmappen zu exportieren und zu importieren, da der Einstieg so schneller geht.
• 4:52
  Wenn Sie jedoch versuchen, dies mit GitHub-Actions oder einem beliebigen CI-System zu automatisieren für die Verwendung der Anwälteinformation einer Person schnell in den Sackers.
• 4:59
  Sie stoßen an Berechtigungsgrenzen, manchmal ohne eindeutige Fehlermeldungen oder lösen sogar Compliance-Audits aus, da Sie wichtige Bereitstellungen unter einem persönlichen Konto ausführen und nicht unter einem Konto, das für die Automatisierung vorgesehen ist.
• 5:09
  Dienstprinzipale, im Wesentlichen in Azure AD erstellte App-Identitäten, übernehmen alle Berechtigungen, Protokollierungen und Prüfungen, die Ihre Pipeline benötigt.
• 5:19
  Ohne sie wird Ihre Automatisierungskette zu einem Flickenteppich aus persönlichen Übergaben und Sie wissen nie, wer was geändert hat.
• 5:25
  Auch die Quellcode-Verwaltung wird zum Platzhalter.
• 5:28
  Bei normalem Code verfügen Sie über Commit-Verläufe und Blame-Tools.
• 5:32
  Power-Plattform-Lösungsdateien stellen nun Momentaufnahmen da, was bedeutet, dass Ihnen eine detaillierte Änderungsnachverfolgung fehlt.
• 5:36
  Logik, die in den Bildschirmformeln einer Canvas-App oder in oberflächlich dokumentierten Flows versteckt ist, ist erst sichtbar, wenn Sie sie erneut exportieren.
• 5:44
  Jemand optimiert eine Flow-Einstellung in der Benutzeroberfläche, viel Glück beim herausfinden, warum sich nachgelagerte Umgebungen plötzlich anders verhalten.
• 5:49
  Das Endergebnis, die Verwaltung von ILM für Power-Plattform fühlt sich an, als würde man ein Puzzle lösen, bei dem die Hälfte der Teile fehlt oder zumindest unter der Schachtel versteckt ist.
• 5:57
  Unsichtbare Abhängigkeiten, umgebungsspezifische Konnektoren und Variablen, die im Code nicht sichtbar sind, bilden den üblichen Workflow für Entwickler ab.
• 6:05
  Dabei müssen wir noch nicht einmal berücksichtigen, dass Produktionsumgebungen fast immer strengere Berechtigungen, andere Datenrichtlinien und Prüfanforderungen haben, die in der Entwicklung oder im Test nicht offensichtlich sind.
• 6:16
  Aber das ist der Vorteil. Diese Komplexität ist kein Zufall.
• 6:20
  Es gibt einen praktischen Grund dafür, warum Power-Plattformen Quellen, Variablen und Konnektoren auf so einzigartige Weise behandelt.
• 6:27
  Sie soll es Geschäftsanwendern ermöglichen, leistungsstarke Apps zu erstellen, ohne sich um Code kümmern zu müssen.
• 6:31
  Ein Nebeffekt ist, dass Sie als die Person, die die Automatisierung einrichtet, nachverfolgen müssen, was sich im Hintergrund verbirgt.
• 6:38
  Wenn Sie wissen, wo diese unsichtbaren Kabel verlaufen, können Sie die meisten Hindernisse vermeiden, die Power-Plattformen ALM zum Scheitern bringen.
• 6:45
  Bringen.
• 6:45
  Wenn Ihnen das alles nach viel Arbeit klingt, liegen Sie nicht falsch.
• 6:50
  Es gibt jedoch vier ALM-Säulen, die tatsächlich dabei helfen, dieses Durcheinander zu entwirren.
• 6:54
  Quelle, Bild, Test und Bereitstellung.
• 6:56
  Jede dieser Funktionen hat in Power-Plattformen ihre Eigenheiten, doch zusammenbringen sie wieder Struktur in das, was sich ansonsten chaotisch anfühlt.
• 7:02
  Das ALM-Kernsystem Quelle, Bild, Test, Bereitstellung.
• 7:05
  Jedes Mal, wenn jemand nach einer Power-Plattform-Pipeline fragt, die einfach funktioniert, denkt man als erstes an diese vier verstaubten ALM-Säulen, Quelle, Bild, Test und Bereitstellung.
• 7:15
  In der herkömmlichen Entwicklungsumgebung könnten Sie diese Dinge fast im Schlaf ausführen.
• 7:19
  Power-Plattformen lässt Sie nicht so einfach davon kommen.
• 7:21
  Plötzlich bedeutet Quelle nicht mehr Code.
• 7:24
  Es bedeutet, sich mit Lösungsdateien herumzuschlagen, gezippte Pakete mit Apps, Flows und manchmal Konnektoren zu exportieren, die vorgeben, Teil der Quelle zu sein.
• 7:32
  Beginnen wir mit den Grundlagen und analysieren dann, was die einzelnen Säulen in dieser Welt ein wenig seltsam macht.
• 7:38
  Sie haben Ihre Lösungs-ZIP-Datei.
• 7:40
  Das ist kein Code im üblichen Sinne.
• 7:42
  Öffnen Sie sie und Sie werden mit XML- und JSON-Erklärungsdateien begrüßt, nicht mit der Logik, die Sie in TypeScript oder C-Shot finden würden.
• 7:49
  Dies ist jedoch die Quelle für Power-Plattformen.
• 7:50
  Teams stolpern hier oft.
• 7:52
  Es sieht portable aus, bis man feststellt, dass die meisten Änderungen wie das Aktualisieren einer Formel in einem Bildschirm oder das Optimieren der Logik eines Flows erst offensichtlich werden, wenn man eine neue Lösungs-ZIP-Datei exportiert.
• 8:02
  Man kann diese Lösungs-Dateien zwar in Git versionieren, aber wenn man nicht diszipliniert ist und sie nach jeder relevanten Bearbeitung exportiert, weiß der Verlauf eklatante Lücken auf.
• 8:10
  Jetzt kommt die Konfiguration.
• 8:12
  Bei regulären Apps kann man Verbindungszeichenfolgen in einer Konfigurationsdatei speichern und das war's dann auch schon.
• 8:17
  Power-Plattformen schmuggelt umgebungsspezifische Daten in diese Lösungen.
• 8:21
  Es handelt sich nicht nur um Umgebungsvariablen, sondern auch um Connector-Verweise, dynamische Endpunkte, Rollen und Berechtigungen, die zusammen mit der Geschäftslogik gebündelt werden.
• 8:28
  Wenn man es versäumt, diese vor dem Exportieren aus der Entwicklungs- oder Testphase zu aktualisieren, sperren sie die Zeiger auf die falsche Stelle.
• 8:35
  Stelle.
• 8:36
  Ich habe beobachtet, wie Teams ihre Lösungs-ZIP-Dateien gewissenhaft committen, nur...
• 8:40
  ...um dann bei der Bereitstellung festzustellen, dass die Hälfte ihrer App immer noch mit dem Entwicklungs-Dataverse statt mit der Produktion kommuniziert, weil niemand die Connector-Verweise neu zugeordnet hat, weil niemand die Connector-Verweise hat.
• 8:47
  Dann haben wir die Bild-Datei.
• 8:50
  Das Wort Bild ruft normalerweise Bilder vom Kompilieren von Code und den Betrachten grüner Häkchen in einem CI-Auftrag hervor.
• 8:55
  Bei Power-Plattformen geht es beim Bild-Prozess darum, diese ZIP-Pakete zu speichern, das Schema zu überprüfen und Abhängigkeiten zu verifizieren.
• 9:02
  In einer GitHub-Actions-Pipeline ruft ein Bild-Auftrag ihre festgeschriebene Lösungsdatei ab und verwendet dann die Power-Plattform-CLI von Microsoft, um die Lösung zu entpacken, zu validieren und neu zu verpacken.
• 9:11
  Der Validierungsschritt ist der Ort, an dem die Magie oder das Chaos geschieht.
• 9:14
  Er kann fehlerhafte Verweise oder nicht unterstützte Aktionen abfangen.
• 9:17
  Schlimmer noch, wenn eine Änderung in ihrem Flow auf einem benutzerdefinierten Connector basiert, der es nie in die Quellcode-Verwaltung geschafft hat, verpackt ihr Bild stillschweigend etwas Unvollständiges.
• 9:26
  Hier wird es knifflig.
• 9:28
  Bei diesen Bildaufträgen geht es weniger um das Kompilieren als vielmehr um die Orchestrierung eines zuverlässigen Exports und darum, sicherzustellen, dass der Inhalt auslieferbar ist.
• 9:36
  Teams, die dies überspringen oder schnell erledigen, geraten in Situationen, in denen ein Bild technisch erfolgreich ist, aber in UAT oder Prod die Hälfte der vorgesehenen Funktionen fehlen.
• 9:44
  Microsoft verbreitet immer wieder die Botschaft, dass Lösungsdateien ALM-Portabel machen, aber es gibt immer eine Fußnote.
• 9:50
  Die Portabilität hängt davon ab, dass Konnektoren ordnungsgemäß zugeordnet und Rollen in allen Umgebungen eingerichtet werden.
• 9:55
  Testen ist die nächste Schaltfläche für die Quelle.
• 9:57
  In einer Web-App-Pipeline können automatisierte Tests, Komponententests oder Benutzeroberflächenprüfungen ausführen.
• 10:02
  Bei Power-Plattformen ist es umstritten, was als Test gilt.
• 10:04
  Manchmal ist es die Validierung der Lösung, wird die Lösung geöffnet und werden wichtige Abhängigkeiten aufgelöst.
• 10:12
  Manchmal werden Testabläufe ausgeführt oder überprüft, ob Konnektoren in einer Testumgebung reagieren, reagieren.
• 10:18
  Oftmals werden Tests manuell durchgeführt, da die Validierung der Geschäftslogik in einer Canvas-App noch nicht in automatisierten Pipelines integriert ist.
• 10:25
  Sie können jedoch Prüfungen automatisieren, um fehlende Konnektoren zu erkennen, wichtige Abläufe zu validieren oder sogar eine Testumgebung anzubringen, um nachzubeißen, dass die Anmeldinformationen funktionieren.
• 10:33
  Die Bereitstellung verdeutlicht das Problem.
• 10:35
  Wenn eine Standard-App bereitgestellt wird, können Sie einfach ein Web-Artefakt in Azure pushen.
• 10:40
  Bei Power-Plattformen müssen Sie Verbindungen zuordnen, Berechtigungen zuweisen, Geheimnisse aktualisieren, Umgebungsvariablen austauschen und schließlich einen Import mit einem Dienstprinzipial auslösen, niemals mit einem regulären Konto.
• 10:49
  Andernfalls haben Sie es mit Audits und Berechtigungsverweigerungen zu tun.
• 10:53
  GitHub Actions kann diesen Prozess zusammenführen, jedoch nur wenn jeder Auftrag weiß, auf welche Zielumgebung und welche Geheimnisse er verwenden soll.
• 10:59
  Ich habe erlebt, dass Teams versucht haben, dies zu umgehen, indem sie für Entwicklung und Produktion nur einen einzigen Satz von Anmeldinformationen verwendet haben.
• 11:05
  Das führt zu Chaos, Datenlecks, Berechtigungsfehlern und fehlerhaften Funktionen, die nur in einer Umgebung auftreten.
• 11:11
  Nehmen wir ein reales Team, mit dem ich vor ein paar Monaten zusammengearbeitet habe.
• 11:13
  Sie haben fast alles richtig gemacht, Standard-Get-Repositories, versionierte Projektmappen, ZIP-Dateien und übersichtliche Verzweigung.
• 11:18
  Aber Ihre Pipeline ist bei der Bereitstellung immer kaputt gegangen.
• 11:20
  Sie haben sich nie die Mühe gemacht, Umgebungsvariablen auszutauschen oder Connector-Referenzen zu aktualisieren, bevor sie in die Produktion importiert wurden.
• 11:27
  Dadurch verwiesen wichtige Datenflüsse auf die falschen Endpunkte und die Daten gelangten in die falschen Systeme.
• 11:31
  Die Lösung bestand in Skript-Schritten in Ihrer GitHub-Pipeline, die Variablen austauschten und jeden Connector beim Import neu zuordneten.
• 11:38
  Microsofts eigene Anleitung ist diesbezüglich unverblüht.
• 11:40
  Verwenden Sie Projektmappen-Dateien, um Dinge zwischen Umgebungen zu verschieben, aber behandeln Sie Connector-Referenzen und Rollenzuordnungen immer als Teil Ihrer Pipeline.
• 11:48
  Microsoft weist darauf hin, dass das Überspringen dieser Schritte die häufigste Möglichkeit ist, Apps zum Absturz zu bringen, insbesondere wenn Umgebungen immer stärker gesperrt werden.
• 11:54
  Wenn Sie Quellcode, Bild, Test und Bereitstellung als verbundene bewegliche Teile und nicht nur als isolierte Schritte betrachten, wird es einfacher zu verstehen, warum so viele ILM-Versuche scheitern und wie Sie Probleme tatsächlich beheben können, anstatt die Daumen zu drücken.
• 12:05
  Als nächstes werfen wir einen Blick darauf, wie GitHub Actions diesen Prozess-Coordineer-Trigger, Verzweigungen und die Trennung von Aufträgen, um die Automatisierung Ihrer Power-Plattform flexibel und sicher zu halten.
• 12:17
  GitHub Actions verbindet die Punkte mit Triggern und Aufträgen.
• 12:20
  Wenn Sie nach dem Aktualisieren Ihrer Power-App auf den Abschluss einer GitHub-Actions-Pipeline gewartet haben, wissen Sie bereits, dass Automatisierung nicht sofort und definitiv nicht sofort und definitiv nicht wie von Zauberhand erfolgt.
• 12:29
  Die meisten Teams stoßen direkt nach der Aufregung, wenn Sie Ihren ersten Workflow ausführen, an diese Grenzen.
• 12:33
  Sie richten ein Skript ein, verknüpfen es mit Ihrem Repository und erwarten, dass jeder neue Commit sauber in allen Umgebungen ausgeführt wird.
• 12:41
  Dann wird man eingeholt.
• 12:43
  Anstatt einfach nur ein Skript zu starten, verwendet GitHub Actions eine Logikette, die auf Triggern, Aufträgen und Übergaben zwischen Umgebungen basiert.
• 12:51
  Diese Reihenfolge und Struktur verhindern, dass Bereitstellungen zu einem Wirrwarr aus fehlgeschlagenen Schritten und seltsamen Fehlern werden.
• 12:56
  Der Ausgangspunkt in diesem System ist der Trigger.
• 12:58
  Die meisten Anfänger erstellen einen Workflow, der bei jedem Push oder immer dann ausgelöst wird, wenn ein Pull-Request im Hauptbranche landet.
• 13:07
  Da ist in oberflächlich betrachtet, scheint das eine Methode zu sein.
• 13:10
  Warum führen Sie Ihre Pipeline nicht jedes Mal aus, wenn Sie die Arbeit ändern?
• 13:12
  Ist der Haken an der Sache.
• 13:13
  Wenn Sie nur einen Trigger für den Hauptbranche festlegen, wird alles über einen einzigen Track geleitet.
• 13:17
  Was ist, wenn Änderungen in die Entwicklungs- aber nicht in die Test- oder Produktionsphase einfließen?
• 13:20
  Was ist, wenn Sie bereit sind, in die Produktionsphase zu pushen, die Testphase aber noch die Validierung durchführen?
• 13:24
  Teams, die sich an einheitliche Trigger halten, stoßen häufig auf Probleme, bei denen sich für Entwicklungsumgebungen gedachte Funktionen in die Produktionsumgebung einschleichen oder Testbereitstellungen plötzlich die Produktionseinstellungen überschreiben.
• 13:35
  Sie können Workflows für jede Umgebung Entwicklung, Test und Produktion verzweigen und für jede Umgebung ganz spezifische Trigger einrichten.
• 13:42
  Richten Sie beispielsweise einen Workflow ein, der nur bei Pushes in einen Entwicklungsbranche ausgeführt wird?
• 13:46
  Oder lösen Sie einen anderen Workflow aus, wenn jemand einen Merch in die Produktionsversion vornimmt?
• 13:49
  Dieser Ansatz bietet mehr Kontrolle und schafft eine klare Grenze zwischen laufenden Arbeiten und Live-Änderungen.
• 13:55
  Viele Teams überprüfen ihre Trigger jedoch nie wieder, nachdem sie sie erstellt haben.
• 13:58
  Auf diese Weise können Geheimnisse aus einer Umgebung in eine andere gelangen und eine für die Entwicklung gedachte Konfiguration landet versehentlich in der Produktion.
• 14:05
  Ein Team, mit dem ich zusammengearbeitet habe, hat versucht, seinen gesamten ALM-Prozess über einen einzigen Workflow auszuführen.
• 14:10
  Eine Zeit lang schien alles in Ordnung zu sein, bis jemand bemerkte, dass eine Verbindungszeichenfolge für die Produktionsdatenbank in der Entwicklungsumgebung angezeigt wurde.
• 14:17
  Sie wussten nicht, dass ihre Geheimnisse zwischen Aufträgen geteilt wurden.
• 14:21
  Und sobald der Code zwischen Umgebungen verschoben wurde, wurden diese Geheimnisse im Innendurchgesicke.
• 14:24
  Es war kein offensichtlicher Absturz oder Fehler. Es geschah still und leistend.
• 14:28
  Diese Art von Datenverlust kommt häufiger vor, als man denkt, insbesondere wenn sie ihre Workflows nicht so einrichten, dass Geheimnisse und Umgebungsvariablen getrennt werden.
• 14:35
  Jeder Auftrag in einem GitHub-Actions-Workflow behandelt einen klaren Teil des Prozesses.
• 14:38
  Ein Auftrag kann den Export der Projektmappe aus einer Quellumgebung übernehmen, während ein anderer Auftrag die Validierung, das Entpacken, das Scannen der Projektmappen-Metadaten, die Überprüfung aller Abhängigkeiten und das Sicherstellen, dass Connector-Referenzen vorhanden sind, übernimmt.
• 14:52
  Als nächstes folgt der Auftrag, der die umgebungsspezifischen Variablen vorbereitet und die Lösung so übersetzt, dass sie in die Zielumgebung passt, dass sie in die Zielung kann.
• 14:59
  Der letzte Auftrag löst den Importvorgang mithilfe von Dienstprinzipalen aus, um Änderungen in die richtige Umgebung zu schreiben.
• 15:04
  Sie denken vielleicht, dass Umgebungsvariablen und Geheimnisse nur einfache Platzhalter sind, aber in der Praxis sind sie der Klebstoff, der alles zusammenhält, der alles zusammenhält.
• 15:12
  Verbindungszeichen folgen, API-Schlüssel und gemeinsam genutzte Passwörter müssen alle zwischen Aufträgen ausgetauscht werden, aber sie können niemals über Grenzen hinweg verloren gehen.
• 15:19
  Im Power-Plattform ALM haben sie möglicherweise eine andere Dataverse-Verbindung für jede Umgebung oder müssen Endpunkte austauschen, je nachdem, auf welchen Flow oder welche Power-Apps sie abzielen.
• 15:29
  Wenn sie Variablen wiederverwenden oder Geheimnisse hardcodieren, erhalten sie entweder eine fehleranfällige Pipeline oder schlimmer noch erhebliche Sicherheitsrisiken oder
• 15:36
  Der Importvorgang hängt davon ab, dass Geheimnisse nur aus dem richtigen Tresor abgerufen werden, sodass die Produktion nicht durch Test- oder Entwicklungspannen gefährdet wird.
• 15:43
  Ein gutes mentales Modell für Geheimnisse in GitHub-Actions ist es, sich jede Umgebung als einen eigenen digitalen Tresor vorzustellen, ein verschlossener Kasten, den nur die richtigen Aufträge sehen können.
• 15:53
  GitHub bietet ihnen präzise Kontrollen.
• 15:55
  Sie können Geheimnisse auf Umgebungen beschränken, sodass ein in der Entwicklung ausgeführter Auftrag nicht auf Produktionsanmeldinformationen zugreifen kann und umgekehrt.
• 16:02
  Richten sie diese Tresore ein und selbst wenn jemand, der die Pipeline optimiert, etwas Riskantes versucht, verhindern die Umgebungsschutzregeln, dass ein Fehltritt über die Umgebung erfolgt.
• 16:09
  Sowohl die Dokumentationen von Microsoft als auch von GitHub betonen diesen Punkt.
• 16:13
  Sie empfehlen Umgebungsschutzregeln und eine strikte Festlegung des Geheimnisbereichs, um umgebungsübergreifende Datenlags zu stoppen, bevor sie überhaupt entstehen.
• 16:20
  Ohne diese Art von Schutz funktionieren selbst die am besten konzipierten ALM-Workflows nicht.
• 16:25
  Stellen Sie sich einen Workflow vor, der in der Produktion bereitgestellt wird, während immer noch eine Entwicklungsverbindungszeichenfolge oder eine Testumgebung mit plötzlichen Zugriff auf Produktionsdaten vorhanden ist.
• 16:32
  Das führt nicht immer zu sichtbaren Problemen.
• 16:34
  Manchmal bedeutet es nur, dass Compliance-Flags ausgelöst werden oder sich Protokolle mit subtilen Fehlern füllen, die sich langsam zu größeren Problemen anhäufen.
• 16:41
  Aus diesem Grund sind das Verzweigen von Workflows und das Festlegen von Geheimnisbereichen nicht nur Themen für fortgeschoben.
• 16:45
  Sie sind das Sicherheitsnetz, das verhindert, dass ihre Automatisierung still und heimlich auseinanderbricht.
• 16:48
  Es ist auch sinnvoll, Workflows nicht nur nach Umgebung, sondern auch nach Zuständigkeit aufzuteilen.
• 16:52
  Code, der Lösungen exportiert und validiert, sollte nicht einmal wissen, wie Secrets bereitgestellt oder ausgetauscht werden.
• 16:59
  Wenn jeder Job einen Teil des Puzzles verarbeitet, wird es viel einfacher, Fehler zu erkennen, Änderungen nachträglich rückgängig zu machen und zu prüfen.
• 17:08
  Secrets bleiben in ihren Tresoren, Jobs folgen klar abgegrenzten Berechtigungen und Pipeline-Fehler verweisen direkt auf das Teil, das behoben werden muss.
• 17:15
  Wenn man versteht, wie GitHub Actions Arbeit von einem Job an einen anderen übergibt und dabei Secrets eng abgegrenzt und trigger-klar definiert,
• 17:23
  wird ARM von einem hoffnungsvollen Experiment zu einer zuverlässigen, sicheren und vorhersehbaren Praxis.
• 17:29
  Bei dieser Workflow-Segmentierung geht es nicht nur um die Einhaltung bewährter Methoden.
• 17:34
  Sie blockiert auch stille Sicherheitslücken und versehentliche Überschreibungen und unterbindet eine ganze Klasse unsichtbarer Fehler, bevor sie ihre Umgebungen heimsuchen.
• 17:41
  Jetzt, da die Teile durch eine richtig abgegrenzte Automatisierung zusammenarbeiten, ist es an der Zeit, einen weiteren Reibungspunkt anzugehen.
• 17:48
  Im Konnektoren-Service-Prinzipien und die kleinen, aber kritischen Fallstrecke, die ihre Bereitstellung verzögern können, genau dann, wenn sie sich sicherer fühlen.
• 17:57
  Geheime Service-Prinzipien und das Problem mit Konnektoren.
• 18:00
  Wenn Sie jemals versucht haben, eine Power-App oder einen Power-Flow von der Entwicklung in die Produktionsumgebung zu verschieben, kennen Sie das Problem.
• 18:04
  In einer Umgebung funktioniert alles einwandfrei, doch sobald Sie wechseln, kommt alles zum Stillstand oder es treten diese mysteriösen Verbindungsfehler auf.
• 18:13
  Das ist nicht auf ein bestimmtes Team beschränkt.
• 18:15
  Jeder Power-Plattform-Administrator stößt irgendwann auf diese Mauer.
• 18:19
  Die Ursache des Problems liegt im Verhalten von Konnektoren und Geheimnissen im Hintergrund.
• 18:24
  Sie können nicht einfach eine Lösung-SIP-Datei aus der Entwicklungsumgebung exportieren und erwarten, dass sie auch an einer anderen Stelle funktioniert,
• 18:29
  da sich die Verbindungen, von denen Sie abhängen, mit jeder Umgebung ändern.
• 18:32
  Nehmen Sie als Beispiel die Connector-Verweise.
• 18:35
  Im Power-Plattformen ist ein Connector nie nur eine statische Information, die in Ihrer App gebündelt ist.
• 18:39
  Er ist dynamisch, veränderbar und oft pro Umgebung eindeutig.
• 18:44
  Wenn Sie Ihre Lösung exportieren, verhalten sich Connector-Verweise fast wie Lesezeichen.
• 18:48
  Sie verweisen auf Verbindungsobjekte, die nur in der Umgebung vorhanden sind, in der sie erstellt wurden.
• 18:52
  Wenn Sie also in die Test- oder Produktionsumgebung importieren, wird Ihr schicke HTTP-Endpunkt oder Dataverse-Link nicht unbedingt auf die gleiche Weise oder überhaupt nicht neu erstellt.
• 19:00
  Hier geraten Teams ins Hintertreffen.
• 19:03
  Wenn die Entwicklung einen Connector zum Testen von Daten verwendet und diese exakte Konfiguration nicht in der Produktion gespiegelt wird,
• 19:09
  schlägt Ihr Flow oder Ihre App entweder stillschweigend fehl oder hängt sich beim ersten Verbindungsversuch auf.
• 19:16
  Viele Leute versuchen dies zu umgehen, indem sie Benutzeranwälteinformationen umgebungsübergreifend verwenden.
• 19:21
  Sie gehen davon aus, dass es in der Produktion funktioniert, wenn Sie dasselbe Konto oder Kennwort verwenden, mit dem die Verbindung in der Entwicklung hergestellt wurde.
• 19:26
  In der Realität bringt dies eine Reihe von Problemen mit sich, von der Verweigerung von Berechtigungen bis hin zum Auslösen von Compliance-Überprüfungen.
• 19:32
  Die eigenen Richtlinien von Microsoft sind eindeutig.
• 19:34
  Die Verwendung individueller Benutzeranwälteinformationen für automatisierte Bereitstellung ist einfach nicht praktikabel oder sicher.
• 19:39
  Ihre Automatisierung ist dadurch von Kennwort-Zurücksetzungen abhängig und kann eine unklare Spur in Ihren Überwachungsprotokollen hinterlassen.
• 19:44
  Es gibt keine klare Verantwortlichkeit und schließlich blockieren Berechtigungen die Pipeline, wenn der ursprüngliche Benutzer gekennzeichnet, entfernt oder den Zugriff verliert.
• 19:53
  Hier kommen Dienstprinzipale ins Spiel.
• 19:55
  Wenn Sie noch nicht mit Ihnen gearbeitet haben, stellen Sie sich ein Dienstprinzipal als ein zusätzliches digitales By-Handle vor, das speziell für die Automatisierung entwickelt wurde.
• 20:01
  Im Gegensatz zu einem normalen Benutzer ist ein Dienstprinzipal an eine App-Registrierung in Azure AD gebunden, nicht an eine reale Person, nicht an eine reale Person.
• 20:08
  Sie erteilen ihm die minimalen Berechtigungen, die zum Ausführen Ihrer Bereitstellungsaufgaben erforderlich sind.
• 20:12
  Das klingt einfach, aber der Nutzen ist groß.
• 20:15
  Anstatt sich auf einen Benutzer zu verlassen, der die Organisation verlassen oder die Rollen ändern könnte, bleiben Bereitstellungen konsistent, überprüfbar und nachvollziehbar.
• 20:21
  Jede Umgebung erhält nur Zugriff auf die richtigen Verbindungen, Ressourcen und alle Änderungen werden unter diesem Roboter-Konto protokolliert, poliert.
• 20:28
  Wenn etwas fehlschlägt, haben Sie einen sauberen Prüfpfad und Sie bleiben nicht mit verwaisten Abläufen zurück, den niemand beheben kann.
• 20:34
  Bezüglich des Problems der Zuordnung von Konnektoren.
• 20:37
  Sollten Sie bedenken, was passiert, wenn Umgebungen auseinanderdriften.
• 20:39
  Möglicherweise hat das Entwicklungsteam die Genehmigung für einen neuen benutzerdefinierten Konnektor.
• 20:43
  Nehmen wir an, er greift auf eine Sandbox-API zu.
• 20:46
  Wenn es an der Zeit ist, in die Produktion zu wechseln, fehlt dieser Konnektor nicht nur, sondern er ist möglicherweise nicht einmal durch die Datenrichtlinien der Organisation zulässig.
• 20:52
  Wenn Sie vergessen, die Zuordnung neu zuzuatmen, ruft die App den falschen Endpunkt auf oder bricht vollständig ab.
• 20:57
  Ab.
• 20:58
  Ich habe dies kürzlich bei einem Gesundheitskonzern miterlebt.
• 21:00
  Eine fehlende Konnektor-Zuordnung führte dazu, dass Testdaten in der Produktion verwendet wurden und führte beinahe zu einem Compliance-Vorfall.
• 21:07
  Ihre automatisierte Pipeline exportierte alles wie geplant, aber die Konnektoreferenz in der Lösung verwies immer noch auf eine alte Testdatenbank, die von Power-Plattformen erst markiert wurde.
• 21:15
  Als echte Daten durch die falschen Leitungen flossen.
• 21:18
  Er sind...
• 21:19
  Umgebungsvariablen helfen hier, einige dieser Probleme zu lindern.
• 21:23
  Im Gegensatz zu hartcodierten Endpunkten oder API-Schlüsseln können Sie mit Umgebungsvariablen trennen, was sich in verschiedenen Umgebungen ändert und was gleich bleibt.
• 21:31
  Sie können Endpunkte, API-Schlüssel oder andere Geheimnisse bei jeder Bereitstellung austauschen, ohne Ihre App oder Ihren Flow neu schreiben zu müssen.
• 21:37
  Beispielsweise kann ein Flow, der mit einer DevDataverse-Tabelle arbeitet, beim Import neu konfiguriert werden, um die ProTabelle zu verwenden, indem Sie einfach die Umgebungsvariable in Ihrem Bereitstellungsprozess ändern.
• 21:47
  GitHub-Actions-Pipelines machen dies praktisch.
• 21:50
  Jeder Auftrag kann den richtigen Wert zum richtigen Zeitpunkt einfügen.
• 21:53
  Aber auch hier ist Disziplin der Schlüssel.
• 21:56
  Vergessen Sie, eine Variable zu aktualisieren oder lassen Sie Geheimnisse zwischen Umgebungen durchsickern und plötzlich ist Ihr Workflow offengelegt.
• 22:03
  Microsoft betont, wie wichtig es ist, Geheimnisse sorgfältig zu definieren und Konnektoreferenzen bewusst zuzuordnen.
• 22:09
  Ihre DLP-Richtlinien zur Verhinderung von Datenverlust existieren aus einem bestimmten Grund.
• 22:13
  Sie sollen verhindern, dass vertrauliche Informationen zwischen Umgebungen wandern oder an der falschen Stelle auftauchen.
• 22:16
  Oder an der falschen Stelle auftauchen.
• 22:18
  Wenn Sie versuchen, diese Aspekte durch die gemeinsame Nutzung von Variablen oder Verbindungen zu umgehen,
• 22:22
  stolpern Sie über die Sicherheits- oder Compliance-Kontrollen des Unternehmens.
• 22:26
  Und was noch wichtiger ist, Sie verliehen die Vorhersehbarkeit.
• 22:28
  Da ist keine klare Grenze mehr zwischen dem, was für die Entwicklung gedacht ist und dem, was für die Entwicklung gedacht ist und dem, was für die Test- oder Produktionsphase gedacht ist.
• 22:33
  Der Vorteil, wenn Sie all dies richtig machen, kann kaum hoch genug eingeschätzt werden.
• 22:37
  Dienstprinzipien in Kombination mit gut verwalteten Umgebungsvariablen und ordnungsgemäß zugeordneten Konnektoren transformieren Ihre Pipeline.
• 22:43
  Ihre Bereitstellungen werden vorhersehbar.
• 22:44
  Wenn etwas schief geht, haben Sie eine klare Beweiskette und wissen genau, wo Sie suchen müssen.
• 22:49
  Lag es an einer Konnektor-Zuordnung, einer Variable oder einer fehlenden Berechtigung?
• 22:52
  Prüfer können Änderungen nachverfolgen und es gibt keine Spannung, wenn jemand das Unternehmen verlässt oder Passwörter ändert.
• 22:57
  Kommt darauf an, Geheimnisse, Konnektoren und Dienstprinzipien so zu behandeln, als wären sie wichtig.