Latest / M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands / Power Platform ALM met GitHub Actions: source, build, test en deployment zonder giswerk (AI-nasynchronisatie)

Transcript

Power Platform ALM met GitHub Actions: source, build, test en deployment zonder giswerk (AI-nasynchronisatie) · M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands

• 0:00
  Klaar voor 10 dagen Microsoft 365, Copilot, AI, Azure en de mensen die de toekomst van werk vormgeven?
• 0:07
  Deze januari is M365, kom terug en we pakken groter uit.
• 0:12
  Doe mee voor live sessies, praktijkdemo's en praktische kennis van MVP's en experts van over de hele wereld.
• 0:18
  Geen algemene presentaties, geen eindeloos jargon.
• 0:22
  We pakken de echte uitdagingen aan Copilot Studio, AI Agents, Fabric, Beveiliging, Governance en Automatisering.
• 0:29
  Of je nu een IT-professional, ontwikkelaar of zakelijk leider bent, er zijn sessies speciaal voor jou.
• 0:35
  Met 10 volledige dagen kun je meerdere technologieën verkennen en contact leggen met een wereldwijde community.
• 0:40
  Kijk live mee en neem praktische inzichten mee terug naar jouw organisatie.
• 0:44
  Januari 2027, 10 dagen, 1 Microsoft Community. De registratie is nu geopend.
• 0:52
  Claim vandaag nog jouw plek. Dat is M365.com.net.
• 0:58
  Meld je nu aan op M365.com.net en we zien je live in januari.
• 1:05
  Voelt het alsof jouw Power Platform implementaties een blackbox zijn, verstuur je een update, hou je je adem in en hoop je maar dat het werkt in dev, test en prod.
• 1:13
  Wat als je elke fase van je ARM-proces daadwerkelijk kon controleren en inzien met GitHub Actions, zonder giswerk of handmatig labwerk.
• 1:21
  Laten we achter de schermen kijken hoe elk onderdeel, broncodebeheer, automatisering en veilige variabelen echt met elkaar verbonden zijn.
• 1:28
  Dit is niet zomaar een walkthrough. Dit is het waarom dat de meeste handleidingen weglaten, zodat je bij je volgende implementatie niet hoeft te gissen.
• 1:35
  Dus, waarom voelt Power Platform allemaal als een dolhof?
• 1:38
  Als je ooit een Power App hebt geprobeerd te implementeren en die sluipende onzekerheid voelde, alsof er iets belangrijks door de mazen van het net is geglipt, dan ben je niet de enige.
• 1:46
  Op papier belooft Power Platform eenvoudige appontwikkeling, maar achter die vriendelijke façade is al alles behalve recht toe recht aan.
• 1:53
  Een webapp wordt geïmplementeerd vanuit broncodebeheer, gebouwd in een pipeline en komt in productie met voorspelbaar gedrag.
• 2:00
  Power Platform daarentegen verbergt de helft van de logica in drag- en drop-UIs, connectors en formules die je niet in een gitrepo ziet.
• 2:08
  Dus, zelfs als je elke stap uit die algemene beheerdershandleidingen volgt, loop je nog steeds tegen vreemde, moeilijk te diagnostiseren, fouten aan zodra bedrijfscritieke apps de ontwikkelomgeving verlaten.
• 2:17
  Laten we eens kijken naar de almgidsen die overal te vinden zijn.
• 2:19
  De meeste leiden je door het exporteren van een solution-zip en het importeren ervan op een andere plek.
• 2:24
  Simpel genoeg, toch? Maar de hoe is slechts één laag. Wat ze overslaan is de waarom.
• 2:29
  Waarom gaat een Power Platform implementatie op manieren kapot waarop normale code dat nooit doet?
• 2:33
  Dat is wat voor eindeloze verwarring zorgt.
• 2:35
  De kern van het probleem is dat logica, verbindingen en configuratie in Power Apps niet worden opgeslagen zoals klassieke code.
• 2:42
  Je kloont niet zomaar een repo om de unit-tests te bekijken.
• 2:45
  Dus wanneer je je app wilt verplaatsen, reizen al die verborgen afhankelijkheden, verbindingen met Outlook, SharePoint en aangepaste APIs niet altijd netjes mee in dat zip-bestand.
• 2:54
  Dit is het scenario. Je hebt een glimmende nieuwe app die werkt in de ontwikkelomgeving.
• 2:58
  Je exporteert een oplossing, importeert deze in test en plotseling werkt de flow niet meer.
• 3:01
  Het is zelden alleen een best-NS-probleem. In plaats daarvan wijzen verbindingen naar de verkeerde plek, kloppen machtigingen niet en blokkeren databeleid verbindingen die een paar minuten geleden nog prima werkten.
• 3:12
  Stel je nu voor dat je dit doet in drie omgevingen, dev, test en prod, waarbij elke omgeving andere verbindingen, gegevensbeschermingsbeleid, goedkeurders en beheerderscontroles gebruikt.
• 3:21
  Je kunt dit niet oplossen door simpelweg te kopiëren en plakken.
• 3:24
  Het onderzoek ondersteunt wat beheerders en makers elke week zien. Het merendeel van de mislukte Power Platform implementaties komt door ontbrekende connectorreferenties of slecht beheerde omgevingsvariabelen.
• 3:34
  Een ontbrekende connectorreferentie betekent simpelweg dat de flow zijn Outlook of dataverse verbinding niet kan vinden.
• 3:40
  Dus, zodra je je app of flow in een andere omgeving probeert uit te voeren, krijg je runtimefouten.
• 3:46
  En omdat omgevingsvariabelen in Power Platform anders werken dan in andere Microsoft 365 producten, zorgen ze zelfs bij ervaren ontwikkelaars voor problemen.
• 3:55
  Variabelen zijn bedoeld voor het afhandelen van eindpunten, sleutels of tenenspecifieke configuraties.
• 4:00
  Maar als iemand vergeet ze bij te werken na het exporteren van een oplossing, kan zelfs een onschuldig lijkende wijziging een live app kapotmaken.
• 4:06
  Vele van ons trappen in het begin in dezelfde val.
• 4:09
  Je zou kunnen denken dat het exporteren van een oplossingszip alles bundelt wat nodig is, maar het slaat dynamische connectorreferenties eigenlijk over.
• 4:14
  Stel bijvoorbeeld dat je een app hebt die een HTTP connector gebruikt voor een externe service in dev.
• 4:19
  Wanneer je deze importeert in Test of Prat, zal die specifieke connectorinstantie niet bestaan.
• 4:24
  De connectorreferentie in je app verwijst naar een ontbrekend object en flows in de oplossing stoppen stilletjes met werken totdat een gebruiker of beheerder handmatig verbindingen opnieuw maakt en toewijst.
• 4:34
  Als je meer dan één maker of beheerder hebt, is het nog makkelijker om het overzicht te verliezen over welke referentie waar hoort en niemand zit te wachten op een het werkte in dev evaluatie.
• 4:44
  Nog een complicatie, Service Principles.
• 4:47
  De meesten beginnen met het gebruik van gebruikersaccounts om oplossingen te exporteren en importeren omdat dat sneller is om mee te starten.
• 4:53
  Maar wanneer je probeert te automatiseren met GitHub Actions of welk CI-systeem dan ook, loopt het gebruik van iemands inloggegevens snel dood.
• 4:59
  Je loopt tegen machtigingsmuren aan, soms zonder duidelijke foutmeldingen, of je activeert zelfs compliance audits omdat je kritieke implementaties uitvoert onder een persoonlijk account in plaats van iets dat bedoeld is voor automatisering.
• 5:09
  Automatisering. Service Principles, in essentie app identiteiten aangemaakt in Azure AD, regelen alle machtigingen, logboeken en audits die je pipeline nodig heeft.
• 5:19
  Zonder deze verandert je automatiseringsketen in een lappendeken van overdrachten tussen personen, waardoor je nooit weet wie wat heeft gewijzigd.
• 5:25
  Ook versiebeheer wordt dan een onvoorspelbare factor. Bij reguliere code heb je commit geschiedenis en tools om wijzigingen te achterhalen.
• 5:32
  Power Platform oplossingsbestanden zijn slechts snapshots, waardoor je gedetailleerde wijzigingsregistratie mist.
• 5:37
  Logica verstopt in schermformules van een Canvas app of in gebrekkig gedocumenteerde flows is pas zichtbaar na een nieuwe export.
• 5:44
  Iemand past een flow-instelling aan in de UI en succes met achterhalen waarom downstream-omgevingen zich plotseling anders gedragen.
• 5:49
  Het eindresultaat is dat al een beheer voor Power Platform voelt als een puzzel oplossen waarvan de helft van de stukjes ontbreekt of verborgen ligt onder de doos.
• 5:57
  Onzichtbare afhankelijkheden, omgevingsspecifieke connectors en variabelen die je niet in de code ziet, verstoren de gebruikelijke workflow voor ontwikkelaars.
• 6:06
  En dat nog voordat je te maken krijgt met het feit dat productieomgevingen bijna altijd strengere machtigingen, ander databeleid en auditverrijs te hebben die in dev of test niet direct opvallen.
• 6:16
  Maar er is ook een voordeel. Deze complexiteit is niet willekeurig.
• 6:20
  Er is een praktische reden waarom Power Platform zo uniek omgaat met brombestanden, variabelen en connectors.
• 6:27
  Het stelt zakelijke gebruikers in staat krachtige apps te bouwen zonder zich zorgen te maken over code.
• 6:32
  De keerzijde is dat jij, als degene die de automatisering opzet, moet bijhouden wat er onder de motorkap gebeurt.
• 6:38
  Als je weet waar die onzichtbare draden lopen, kun je de meeste valkuilen die Power Platform Alm kunnen ontregelen, voorkomen of herstellen.
• 6:46
  Als dit allemaal als een grote uitdaging klinkt, dan heb je gelijk.
• 6:50
  Maar er zijn vier Alm pijlers die helpen om deze chaos te ontwarren.
• 6:53
  Bron, bouw, test en implementatie.
• 6:56
  Elk heeft zijn eigenaardigheden in Power Platform, maar samen brengen ze structuur aan in wat anders als chaos voelt.
• 7:02
  Het kernalmsysteem, bron, bouw, test, implementatie.
• 7:05
  Elke keer als iemand vraagt om een Power Platform Pipeline die simpelweg werkt, denk ik direct aan die vier bekende Alm pijlers.
• 7:12
  Bron, bouw, test, implementatie.
• 7:15
  In de traditionele ontwikkelwereld zou je dit bijna in je slaap kunnen doen.
• 7:19
  Power Platform maakt het je niet zo gemakkelijk.
• 7:21
  Ineens betekent, bron, niet langer code.
• 7:24
  Het betekent worstelen met oplossingsbestanden, het exporteren van gezipte bundels vol apps, flows en soms connectors die zich voordoen als onderdeel van de bron.
• 7:32
  Laten we beginnen bij de basis en daarna kijken wat elke pijler zo bijzonder maakt in deze wereld.
• 7:38
  Je hebt je zipbestand met de oplossing.
• 7:40
  Het is geen code in de gebruikelijke zin van het woord.
• 7:42
  Open het en je wordt begroet door XML en JSON bestanden, niet de logica die je in typescript of C-hashtag zou zien.
• 7:48
  Maar dit is de broncode voor Power Platform.
• 7:51
  Teams lopen hier vaak tegenaan.
• 7:52
  Het lijkt portable totdat je beseft dat de meeste wijzigingen, zoals het bijwerken van een formule of de logica van een flow, pas zichtbaar worden na het exporteren van een nieuwe solution zip.
• 8:02
  Dus ja, je kunt deze solution bestanden versie beheren in Git, maar tenzij je strikt exporteert na elke relevante wijziging, vertoont je historie grote gaten.
• 8:10
  Nu komt de configuratie.
• 8:12
  Bij gewone apps sla je verbindingsreeksen op in een configuratiebestand en ben je klaar.
• 8:17
  Power Platform smokkelt omgevingsspecifieke gegevens mee in deze solutions.
• 8:21
  Het zijn niet alleen omgevingsvariabelen, maar ook connectorverwijzingen, dynamische eindpunten, rollen en machtigingen gebundeld bij de bedrijfslogica.
• 8:29
  Als je vergeet deze bij te werken voor het exporteren vanuit dev of test, leg je verwijzingen naar de verkeerde plek vast.
• 8:36
  Ik heb gezien hoe teams trouw hun solution zip bestanden committen om er na implementatie achter te komen dat de helft van hun app nog met de dev dataverse praat in plaats van met prod, omdat niemand de connectorverwijzingen heeft aangepast.
• 8:48
  Dan hebben we de build.
• 8:49
  Het woord build roept meestal beelden op van het compileren van code en het zien van groene vinkjes in een CI-taak.
• 8:55
  Bij Power Platform draait het beeldproces om het opslaan van die zip-bundels, het controleren van schema's en het verifiëren van afhankelijkheden.
• 9:02
  In een GitHub Actions Pipeline pakt een beeldtaakje gecommiet solution bestand, waarna Microsoft's Power Platform CLI de solution uitpakt, valideert en opnieuw inpakt.
• 9:11
  De validatiestap is waar de magie of de chaos ontstaat. Het kan defecte verwijzingen of niet ondersteunde acties onderscheppen.
• 9:18
  Erger nog, als een wijziging in je flow afhankelijk is van een aangepaste connector die nooit in versiebeheer is opgenomen, verpak je beeld stilletjes iets dat incompleet is.
• 9:26
  Hier wordt het lastig. Die beeldtaken gaan minder over compileren en meer over het orkestreren van een betrouwbare export en zorgen dat de inhoud klaar is voor verzending.
• 9:36
  Teams die dit overslaan of overhaasten, belanden snel in situaties waarin een beeld technisch slaagt, maar het resultaat in uw AT of broad de helft van de beoogde functies mist.
• 9:44
  Microsoft blijft benadrukken dat solution bestanden al portable maken, maar er is altijd een voetnoot.
• 9:50
  Portabiliteit hangt af van het correct toewijzen van connectors en het instellen van rollen in alle omgevingen.
• 9:55
  Testen is de volgende knop. In een webapp-pipeline kunnen geautomatiseerde tests unit-tests of UI-checks uitvoeren.
• 10:02
  Voor Power Platform is het onderwerp, wat telt als test, nog voor voor discussie.
• 10:06
  Soms is het solution-validatie, met andere woorden, opent de solution en worden belangrijke afhankelijkheden opgelost.
• 10:12
  Andere keren is het het uitvoeren van testflows of controleren of connectors reageren in een testomgeving.
• 10:18
  Vaak is testen handmatig omdat het valideren van bedrijfslogica in een Canvas-app nog niet is gekoppeld aan geautomatiseerde pipelines.
• 10:25
  Maar je kunt controles automatiseren om ontbrekende connectors te vinden, kritieke flows te valideren of een testomgeving te pingen om te bewijzen dat inloggegevens werken.
• 10:33
  Bij de uitrol wordt de pijn pas echt voelbaar.
• 10:36
  Bij het uitrollen van een standaard-app hoef je vaak alleen een web-artefact naar Azure te pushen.
• 10:39
  Bij Power Platform moet je verbindingen koppelen, machtigingen toewijzen, secrets bijwerken, omgevingsvariabelen wisselen en een import activeren via een service principle, nooit een gewoon account.
• 10:49
  Anders zit je vast aan audits en geweigerde machtigingen.
• 10:52
  GitHub Actions kan dit proces stroomlijnen, maar alleen als elke job weet welke omgeving het moet targeten en welke secrets er gebruikt moeten worden.
• 11:00
  Ik heb teams gezien die dit probeerden te omzeilen door één set inloggegevens te gebruiken voor zowel dev als prod, een recept voor chaos, datalekken, rechtenfouten en functies die in slecht één omgeving werken.
• 11:10
  Neem een team uit de praktijk waar ik een paar maanden geleden mee werkte.
• 11:13
  Ze deden bijna alles goed, standaard git repos, versiebeheer voor solutionsips en duidelijke branching.
• 11:18
  Maar hun pipeline liep bij de uitrol steeds vast.
• 11:20
  Waarom? Ze namen nooit de moeite om omgevingsvariabelen te wisselen of connectorverwijzingen bij te werken voor de import naar productie.
• 11:26
  Hierdoor wezen belangrijke flows naar de verkeerde eindpunten en zijbelden gegevens naar de verkeerde systemen.
• 11:31
  De oplossing? Gescripte stappen in hun GitHub pipeline die variabelen wisselden en elke connector bij import opnieuw koppelde.
• 11:38
  De eigen richtlijnen van Microsoft zijn hier heel duidelijk over.
• 11:41
  Gebruik solution bestanden om onderdelen tussen omgevingen te verplaatsen, maar verwerk connectorverwijzingen en rollen altijd als onderdeel van je pipeline.
• 11:48
  Ze wijzen erop dat het overslaan van deze stappen de voornaamste reden is dat apps stuk gaan, zeker nu omgevingen strenger worden beveiligd.
• 11:54
  Als je bron, beeld, test en deploy als verbonden onderdelen ziet in plaats van losse stappen,
• 12:00
  is het makkelijker te begrijpen waarom veel aan pogingen falen en hoe je problemen oplost in plaats van te hopen op het beste.
• 12:07
  Laten we nu kijken hoe GitHub Actions dit proces coördineert met triggers, branching en job-scheiding,
• 12:13
  waardoor je power-platform-automatisering flexibel en veilig blijft.
• 12:16
  GitHub Actions, de lijm tussen triggers en jobs.
• 12:20
  Als je wel eens hebt gewacht op een voltooide GitHub Actions pipeline na het updaten van je power-app,
• 12:26
  weet je dat automatisering niet direct is en zeker geen magie.
• 12:29
  De meeste teams lopen tegen die muur aan direct na het enthousiasme van hun eerste geslaagde workflow.
• 12:34
  Je zet een script op, koppelt het aan je repository en verwacht dat elke nieuwe commit soepel wordt uitgerold naar alle omgevingen.
• 12:41
  Dan haalt de realiteit je in.
• 12:43
  In plaats van alleen een script te starten, gebruikt GitHub Actions een logische keten opgebouwd rond triggers, taken en overdrachten tussen omgevingen.
• 12:51
  Die volgorde en structuur voorkomt dat implementaties veranderen in een kluwe van mislukte stappen en vreemde fouten.
• 12:57
  Het startpunt in dit systeem is de trigger.
• 12:59
  De meeste beginners maken een workflow die wordt geactiveerd bij elke push of wanneer een pull request in de mainbranche terechtkomt.
• 13:07
  Op het eerste gezicht lijkt dat een best practice.
• 13:10
  Waarom zou je je pipeline niet uitvoeren telkens wanneer werk verandert?
• 13:12
  Dit is het addertje onder het gras.
• 13:14
  Wanneer je alleen een trigger op main instelt, wordt alles door één enkelspoor geleid.
• 13:17
  Wat als wijzigingen wel naar dev moeten, maar niet naar test of prod.
• 13:20
  Wat als je klaar bent om naar prod te pushen, maar test nog bezig is met validatie.
• 13:24
  Teams die vasthouden aan universele triggers lopen vaak tegen problemen aan waarbij functies voor ontwikkelomgevingen in productie sluipen of testimplementaties plotseling prod-instellingen overschrijven.
• 13:35
  Je kunt workflows vertakken voor elke omgeving, dev, test en prod, en voor elk zeer specifieke triggers instellen.
• 13:42
  Stel bijvoorbeeld een workflow in die alleen draait bij pushes naar een devbranche, of start een andere workflow wanneer iemand merget naar release prod.
• 13:49
  Deze aanpak biedt meer controle en creëert een duidelijke scheiding tussen werk in uitvoering en live wijzigingen, maar veel teams kijken naar het aanmaken nooit meer naar hun triggers.
• 13:59
  Dat is hoe geheimen van de ene omgeving in de andere kunnen lekken en configuratie voor dev per ongeluk in prod beland.
• 14:05
  Een team waar ik meewerkte, probeerde hun hele al een proces vanuit één enkele workflow te draaien.
• 14:10
  Een tijdje leek het prima, totdat iemand merkte dat de connection string voor de productiedatabase opdook in de devomgeving.
• 14:17
  Ze realiseerden zich niet dat hun geheimen werden gedeeld tussen taken.
• 14:21
  En zodra code tussen omgevingen bewoog, lekte die geheimen mee.
• 14:24
  Het was geen duidelijke crash- of foutmelding.
• 14:26
  Het verliep geruisloos.
• 14:28
  Dit soort datalekken komt vaker voor dan je denkt, zeker als je je workflows niet inricht om geheimen en omgevingsvariabelen te scheiden.
• 14:35
  Elke taak in een GitHub Actions workflow behandelt een duidelijk onderdeel van het proces.
• 14:39
  Eén taak kan het exporteren van de oplossing uit een bronomgeving afhandelen.
• 14:43
  Een andere taak zorgt voor validatie, uitpakken, het scannen van oplossingsmetadata, het controleren van alle afhankelijkheden en het garanderen dat connectorreferenties bestaan.
• 14:52
  Daarna volgt de taak die de omgevingsspecifieke variabelen voorbereidt en de oplossing vertaalt, zodat deze in de doelomgeving past.
• 14:59
  De laatste taak activeert het importproces met service principles om wijzigingen naar de juiste omgeving te schrijven.
• 15:05
  Je denkt misschien dat omgevingsvariabelen en geheime simpele placeholders zijn, maar in de praktijk zijn ze de lijm die alles bij elkaar houdt.
• 15:12
  Verbindingsreeksen, API-sleutels, gedeelde wachtwoorden, ze moeten allemaal tussen taken worden gewisseld, maar mogen nooit over grenzen heen lekken.
• 15:20
  In Power Platform Am heb je wellicht een andere dataverse verbinding voor elke omgeving, of moet je eindpunten wisselen afhankelijk van de flow of power app die je gebruikt.
• 15:29
  Als je variabelen hergebruikt of geheime hardcodeert, eindig je met een fragiele pipeline of, erger nog, aanzienlijke beveiligingsrisico's.
• 15:36
  Het importproces is afhankelijk van het ophalen van geheimen uit de juiste kluis, zodat productie niet wordt blootgesteld door fouten in Test of Dev.
• 15:44
  Een goed mentaal model voor geheimen in GitHub Actions is om elke omgeving te zien als een eigen digitale kluis, een afgesloten doos die alleen de juiste taken kunnen inzien.
• 15:53
  GitHub geeft je nauwkeurige controle.
• 15:55
  Je kunt geheime koppelen aan omgevingen, zodat een taak die in Dev draait geen toegang heeft tot crowd-inloggegevens en vice versa.
• 16:02
  Stel deze kluizen in en zelfs als iemand die de pipeline aanpast iets riskants probeert, voorkomen omgevingsregels dat een misstap doorslaat.
• 16:10
  De documentatie van zowel Microsoft als GitHub hamert op dit punt.
• 16:13
  Zij adviseren omgevingsregels en strikte beperking van geheimen om lekken tussen omgevingen te stoppen voordat ze beginnen.
• 16:20
  Zonder die vorm van bescherming vallen zelfs de best ontworpen ARM workflows uit elkaar.
• 16:24
  Stel je een workflow voor die naar prod implementeert terwijl deze nog een dev-verbindingsreeks vasthoudt, of een testomgeving die plotseling toegang heeft tot prod-data.
• 16:32
  Het maakt dingen niet altijd direct zichtbaar kapot.
• 16:35
  Soms betekent het gewoon dat compliance meldingen afgaan of laks volstromen met subtiele fouten die langzaam uitgroeien tot grotere problemen.
• 16:41
  Dit is waarom het vertakken van workflows en het beperken van geheimen niet alleen voor gevorderden zijn.
• 16:45
  Het is het vangen dat voorkomt dat je automatiseringsstilletjes ontrafelt.
• 16:48
  Het is ook waardevol om workflows te splitsen, niet alleen per omgeving, maar ook per verantwoordelijkheid.
• 16:54
  Code die oplossingen exporteert en valideert, zou niet eens moeten weten hoe je moet implementeren of geheimen moet wisselen.
• 17:00
  Als elke taak één puzzelstukje behandelt, wordt het veel makkelijker om te zien waar dingen breken, terug te draaien en wijzigingen achteraf te controleren.
• 17:08
  Geheimen blijven in hun kluis, taken volgen duidelijk afgebakende rechten en pipeline fouten wijzen direct naar het onderdeel dat gerepareerd moet worden.
• 17:16
  Begrijpen hoe GitHub Actions werk overdraagt tussen taken, terwijl geheimen strikt beperkt blijven en triggers duidelijk gedefinieerd zijn,
• 17:23
  maakt AM van een hoopvol experiment tot een betrouwbare, veilige en voorspelbare praktijk.
• 17:29
  Deze workflow segmentatie gaat niet alleen over het volgen van best practices.
• 17:33
  Het blokkeert stille beveiligingslekken en onbedoelde overschrijvingen en sluit een hele klasse onzichtbare fouten uit voordat ze je omgevingen gaan achtervolgen.
• 17:42
  Nu de onderdelen samenwerken door middel van goed afgebakende automatisering, is het tijd dat we een ander pijnpunt aanpakken.
• 17:49
  Connectors, service principles en de kleine maar cruciale valkuilen die uw implementaties kunnen vertragen precies wanneer u er vertrouwen in krijgt.
• 17:56
  Geheime service principles en de problemen met connectors.
• 18:00
  Als u ooit heeft geprobeerd een powerapp of flow van dev naar prod te verplaatsen, kent u het verhaal.
• 18:05
  Dingen werken vlekkeloos in de ene omgeving, maar zodra u overschakelt, loopt alles vast of krijgt u van die mysterieuze verbindingsfouten.
• 18:13
  Dit is niet uniek voor een specifiek team. Elke powerplatformbeheerder loopt uiteindelijk tegen deze muur aan.
• 18:19
  De kern van het probleem ligt in hoe connectors en geheimen zich achter de schermen gedragen.
• 18:24
  U kunt niet zomaar een oplossingszip exporteren vanuit development en verwachten dat het elders werkt, omdat de verbindingen waarvan het afhangt per omgeving verschillen.
• 18:32
  Neem bijvoorbeeld connectorreferenties.
• 18:35
  In het powerplatform is een connector nooit zomaar een statisch stukje informatie dat in uw app is gebundeld.
• 18:40
  Het is dynamisch, veranderlijk en vaak uniek per omgeving.
• 18:43
  Wanneer u uw oplossing exporteert, werken connectorreferenties bijna als bladwijzers.
• 18:48
  Ze verwijzen naar verbindingsobjecten die alleen bestaan in de omgeving waarin ze zijn gemaakt.
• 18:52
  Dus, wanneer u importeert in test of prod, wordt uw mooie HTTP-eindpunt of dataverse link niet noodzakelijkerwijs op dezelfde manier of helemaal niet opnieuw aangemaakt.
• 19:01
  Dit is waar teams de mist in gaan.
• 19:02
  Als dev een connector gebruikt voor testgegevens en die exacte configuratie niet wordt gespiegeld in prod, faalt uw flow of app stilletjes of loopt vast bij de eerste verbindingspoging.
• 19:16
  Veel mensen proberen dit te onzeilen door gebruikersgegevens te delen over omgevingen heen.
• 19:20
  Ze denken dat als je hetzelfde account of wachtwoord gebruikt dat de verbinding in dev heeft gemaakt, het misschien wel zal werken in prod.
• 19:27
  De realiteit is dat dit een hele reeks problemen uitlokt van geweigerde rechten tot het triggeren van compliance audits.
• 19:32
  De eigen richtlijnen van Microsoft zijn duidelijk.
• 19:34
  Het gebruik van individuele gebruikersgegevens voor geautomatiseerde implementaties is niet haalbaar of veilig.
• 19:39
  Het maakt uw automatisering afhankelijk van wachtwoordwijzigingen en kan zorgen voor onduidelijke sporen in uw audit logs.
• 19:44
  Er is geen duidelijke verantwoording en uiteindelijk blokkeren rechten de pipeline wanneer de oorspronkelijke gebruiker wordt gemarkeerd, verwijderd of toegang verliest.
• 19:53
  Maak kennis met service principles.
• 19:55
  Als u er nog niet mee heeft gewerkt, zie een service principle dan als een digitaal paar extra handen dat speciaal is gebouwd voor automatisering.
• 20:01
  In tegenstelling tot een gewone gebruiker is een service principle gekoppeld aan een app registratie in Azure AD, niet aan een echt persoon.
• 20:08
  U geeft het de minimale rechten die nodig zijn om uw implementatietaken uit te voeren.
• 20:12
  Dat klinkt simpel, maar de winst is groot.
• 20:15
  In plaats van te vertrouwen op een gebruiker die de organisatie kan verlaten of van rol kan veranderen, blijven implementaties consistent, controleerbaar en traceerbaar.
• 20:22
  Elke omgeving krijgt alleen toegang tot de juiste verbindingen en bronnen en alle wijzigingen worden gelogd onder dit robotaccount.
• 20:28
  Wanneer er iets misgaat, heb je een duidelijk audit trail en eindig je niet met weestromen die niemand kan repareren.
• 20:34
  Wat betreft het probleem van het koppelen van connectors, denk eens aan wat er gebeurt als omgevingen uit elkaar gaan lopen.
• 20:40
  Misschien heeft het ontwikkelteam goedkeuring gekregen voor een nieuwe aangepaste connector.
• 20:43
  Stel dat deze een sandbox API aanroept.
• 20:46
  Wanneer het tijd is om naar productie te gaan, ontbreekt die connector niet alleen, maar is deze wellicht niet eens toegestaan volgens het organisatiebeleid voor gegevens.
• 20:53
  Als je vergeet de koppeling aan te passen, roept de app het verkeerde eindpunt aan of loopt deze volledig vast.
• 20:58
  Ik zag dit onlangs hard misgaan bij een zorginstelling.
• 21:01
  Een gemiste connector koppeling leidde tot het gebruik van testgegevens in productie en veroorzaakte bijna een compliance incident.
• 21:07
  Hun geautomatiseerde pipeline exporteerde alles zoals gepland, maar de connectorverwijzing in de oplossing wees nog steeds naar een oude testdatabase die niet door het Power Platform werd opgemerkt totdat er echte gegevens door de verkeerde kanalen stroomden.
• 21:20
  Omgevingsvariabelen helpen om een deel van dit probleem te verlichten.
• 21:23
  In tegenstelling tot het hard coderen van eindpunten of API-sleutels kun je met omgevingsvariabelen scheiden wat verandert tussen omgevingen en wat hetzelfde blijft.
• 21:31
  Je kunt eindpunten, API-sleutels of andere geheimen bij elke implementatie vervangen zonder je app of stroom te herschrijven.
• 21:37
  Een stroom die bijvoorbeeld werkt met een dataverse ontwikkeltabel, kan bij het importeren opnieuw worden geconfigureerd voor de productietabel door simpelweg de omgevingsvariabelen in je implementatieproces te wijzigen.
• 21:47
  GitHub Actions Pipelines maken dit praktisch. Elke taak kan op het juiste moment de juiste waarde invoeren.
• 21:53
  Maar ook hier is discipline cruciaal. Vergeet je een variabele bij te werken of laat je geheime lekken tussen omgevingen, dan is je workflow plotseling blootgesteld.
• 22:03
  Microsoft benadrukt de noodzaak om geheime zorgvuldig af te bakenen en connectorverwijzingen bewust toe te wijzen.
• 22:09
  Hun DLP-beleid, Data Loss Prevention, bestaat met een reden om te voorkomen dat gevoelige informatie tussen omgevingen dwaalt of op de verkeerde plek opduikt.
• 22:18
  Als je probeert dit te omzeilen door variabelen of verbindingen te delen, loop je vast op de beveiligings- of compliance-controles van het bedrijf.
• 22:26
  Belangrijker nog, je verliest voorspelbaarheid omdat er geen grens meer is tussen wat bedoeld is voor ontwikkeling, testen of productie.
• 22:33
  De voordelen wanneer je dit allemaal goed aanpakt, zijn nauwelijks te overschatten.
• 22:37
  Service principles in combinatie met goed beheerde omgevingsvariabelen en correct gekoppelde connectors transformeren je pipeline.
• 22:43
  Je implementaties worden voorspelbaar. Wanneer dingen kapot gaan, heb je een duidelijke bewijslast en weet je precies waar je moet zoeken.
• 22:49
  Was het een connector-koppeling, een variabele of een gemiste machtiging?
• 22:52
  Aditors kunnen wijzigingen volgen en er is geen onzekerheid wanneer iemand de organisatie verlaat of wachtwoorden wijzigt.
• 22:57
  Het komt er allemaal op neer dat je geheime connectors en service principles behandelt alsof ze er echt toe doen.