Goddag og velkommen til denne her udgave af All Wars Asher. Goddag. Det er mig, Michael. Det hedder Nicolaj. Og vi er glade for at se jer. Ja, det har været påske. Jeg har forlænget påskeferien. Det har været dejligt. Ja, jeg har det. All Wars Asher, det er jo et stedtid, som vi har været på. Det er det, men nu er vi klar igen. Vi kører jo hver anden måned for tiden. Ja. Sådan er det. Det må I leve med derude. Der er egentlig mange nyheder på Asherfondet, det står vi må sige. Asher er fuldt klart fremover på isen med features. Der sker rigtig mange ting. Noget af det, der er overraskende mest, det er faktisk for, at der er fede features. Det er meget AI-noget. Men også for i høj grad noget med Enterprise Ready mod noget. Det er virkelig noget, men det skalerbarhed, det er robusthed, det er altså frelover og den slags ting. Det er virkelig, virkelig en robust platform, vi har med at gøre. Det er det. Og det er også lidt af det, vi skal snakke om i dag. Og så gemmer vi alle de andre gode ting til andre afsnit. Jep. Forhåbentlig kan vi... Altså, nu har vi jo ikke koordineret det her, men nu siger jeg det bare alligevel live-en, de er. Det kunne jo være, at vi ville snakke lidt om Azure MCP-server og sådan noget med at forbinde nogle LLM'er og sådan noget til Azure. Det kunne også godt være, at vi ville snakke lidt om det danske Azure Data Center. Måske inviterer nogle secret guests ind. Åh... Ja, vi ved i hvert fald, at de bygger på noget. Der er bygget jo nogle danske dayscenter. De er på vej. De er på vej. De er i gang med mur at ske og lægge det hammer, ikke? Jeg tror, de er ved at break em' stack. Ja, okay. Ja, det er stille hjem lidt, ikke? Stille hjem lidt, ja. Sådan. Men i dag... Skal vi snakke med noget andet? Ja. Vi skal snakke lidt om struktur og hvordan kommer man i gang, hvis man skal bygge infrastruktur af SKU. Ja, vi har hørt meget om Enterprise Scale og DevOps og kode og så videre. Men vi kan jo høre rundt omkring, når vi hjælper kunder i gang, at der er stadigvæk nogen der er sådan lidt. Det er lidt en black box for dem. Ja, fordi vi har jo en metode og en måde at gøre det på i FellowMind. Vi har vores FellowMind-mans platform, så vores Enterprise Scale-mans platform. Og der har vi en masse værktøjer, en masse redskaber, vi bruger internt til at drive vores kunder. Og det er jo den her mandeservice. Så har vi jo et væld af Azure-projekter, hvor vi støtter kunder til at bygge alle mulige forskellige fede løsninger i Azure. Og de har også forskellige måder at gøre det på. Ja, ja. Så i dag er lidt sådan nogle tips og tricks til at komme i gang med at bygge noget i Azure via noget kode på en robust måde. Og det er lidt det, vi snakker med. Ja, for man kan sige, at fordi jeg da ikke helt har i gang med løn endnu, så kan I jo prøve lige efter den certificering, der hedder ASS 400. DevOps-certificeringen. Hvad kan du komme i gang med DevOps? Det er faktisk en nemner, hvor der er nogle videoer, man kan se. Fem videoer, så ved du alle om DevOps. Nej, du kan i hvert fald komme i gang. Som er alt for her, ellers. Nej, altså, du er nødt til at, så vil sige helt blanke, så er du nok til at starte at rode lidt med DevOps. Ja. Men når I så har gjort det, synes I, det har jeg lidt styr på. Jeg trykker noget kode ud. Hvad så? Ja. Hvordan sikrer jeg, når jeg så har lært noget infrastructures code, jeg har lært at lave nogle forskellige ting, hvordan sikrer jeg ligesom kvalitet i min leverance? Og det er jo en snak, vi også har, og hvis du ser det så ud, som udvikler, hvordan sikrer jeg kvalitet i den logik, jeg bygger, om det er noget backend eller frontend, eller i hvert fald nogle frameworks, man bruger til at udvikle det her. Vi skal jo sikre noget kvalitet i det, vi leverer. Ja, altså, fordi når vi snakker om tit med infrastructures code, der er nogle ting, som det jo giver os. Det giver os noget versionering, det giver os noget styr på koden osv. Noget af det, jeg også kort kan lide, som er lidt de der sidegevinster, det er jo, at der går op for mange derude, når de begynder at bygge i Azure, så er der pludselig nogle udviklere, der bare kan trykke pejbladens ud, eller trykke ind i portalen, hvis vi synes, vi kan trykke noget kode ud. Så har I pludselig købt en marmerben af ressourcer. Og det er jo rigtig rart, hvis der er en lille smule styr på det. Hvad er det egentlig, vi køber, og hvorfor og hvordan? Og vi så også kan lave om på det igen. Og så er der jo den her governance i, hvordan vi styrer vores udviklingsprojekter, helt simpelt som strukturen i det, hvordan navngiver vi tingene, hvor ligger vi de forskellige ting, hvordan strukturerer vi vores source code, så det giver mening for det enkelte team, eller flere teams, eller har vi en fælles metode for hele vores organisation, eller må den enkelte team ligesom go nuts, har vi nogle standarder for, hvad for noget vi bruger, for nogle værktøjer vi bruger. Noget af det, som jeg synes, vi hører nogen ude, ikke slås med, men finder ud af, at de skal i gang, med det, at vi nok nødt til at have nogle... Altså i gamle dage, hvad der var der IT, det er ligesom bare platformafdelingen. Altså det er jo dem, der byggede platformen, de ejede alt. Det var dem, der vidste nogle ting, der skulle komme ud. Så det var dem, der var kongerne her. Og det er det jo et eller andet sted stadigvæk. Men så er der det, vi snakker om nu, at de der, dem kalder vi så måske platformteams i dag, dem, der bygger hele Azure-platformen, og har styr på governance og connectivity og firewall og policies osv. Når vi så sætter nogle mennesker fri til bare at bygge noget, det kan være en partner, det kan være nogle af vores kolleger. Så har vi de her applikationsteams. Men nogen er nødt til at være deres parangspartner. Så der kommer den her Azure-arkitektrolle ind, som er både i hverdagen, hvad for nogle søv skal jeg bruge? Skal jeg bruge en Cosmos database, en SQL database eller en Functioner og en Container og whatever? Ja. Noget med cost og sådan nogle ting. Men der er også alle hele, kan man sige, processdelen af det. Ja, lige præcis. Hvordan kommer, altså når jeg står med et blankt canvas, og den kommer så i gang. Og det er jo nogle andre discipliner, vi snakker om nu, hvor vi snakker om den gamle systemadministrator. Det, der blev stillet til rådighed til forretningen, det var et operativt system, man kunne logge ind i, og så, værsgo, byg noget. Nu har du fået din Windows-server, eller din Linux-server, nu kan du gå i gang i. Nu får du en helt suite af cloud services, og nu kan du gå i gang. Så det er noget helt andet, vi kigger ind i. Og det vil vi også adressere lidt. Vi vil ikke gå ind og fortælle, hvilken service, hvornår og sådan noget, men det er jo en del af det, når vi skal strukturere vores ting. Jamen det er jo også, fordi det er jo lidt to forskellige discipliner. Altså mange ting, de er jo selvfølgelig også bare helt almindelige. Der skal stadigvæk bruges server, også selvom det er Azure. Jamen så bygger du jo stadigvæk det ikke også servicevalg. Det er sådan noget, det er lidt mere kompenseret. Ja. Men lige for at forstå den her, og lad os lige prøve at tage den inden vi lige åbner VS Code og kigger i nogle andre ting. Den her forståelse mellem den her platformopdeling og applikationsopdeling. Ja. Så nogen styrer sådan en central platform med ressourcer, delte ressourcer, enterprise scale, vi snakkede om det før, og nogen har et ansvar, det kan være de samme mennesker, men ellers nogen har et ansvar for de her applikationslandingszones, hvor der ligger noget, der bygger vores forretningsaplikation. Så i det platform har vi noget enterprise scale, rammeværk til det, og til selve vores applikationslandingszones har vi det her well-architected framework, som beskriver, hvordan det er vi også adresseret i Aarhus Azure, som beskriver, hvordan designer vi det her. Og det er fint. Der er en masse designbeslutninger, en masse ting, vi skal forholde os til, men hvordan helt konkret, når jeg står så med det her blanke canvas og skal til at bygge noget, hvad er nogle gode fif til, hvordan jeg kommer i gang med det? Ja, men lad os lige prøve, bare lige på forståelsen, lige prøve at få den her tegning op. Og jeg zoomer lige lidt ud. Så det her, det er Microsoft Enterprise scale-tegningen, som viser alle de ressourcer, der nu er, alt det rundt om, og alt det, der er selve vores forretningsaplikation. Ja, den er nu i dag delt op i platform og i applikation. Den har de lige fået op. Den har de lige givet en flot lilla farve og en grøn farve. Så det er bare super flot. Så nu kan man komme ind og se, hvem har ansvaret for hvad her? Det er ligesom for at sige, der er nogen, der er rigtig dygtige til at drive hele den her platform for mig. Fellow Mind kunne være et bud på en partner, der kunne gøre det for mig. Men nu har jeg fået min landingzone, jeg har fået min subscription, nu har jeg det her blanke canvas. Ja. Hvordan? Kommer man i gang? Ja. Ikke? Og så er det ligesom en ting af den her, med hvordan for at designe tingene, hvilke ressourcer skal jeg bruge. Men hvis jeg allerede ved det, nu ved jeg præcis, hvad det er, vi vil bygge. Ja. Og hvis du også har en platform, hvor tingene går ind i sig, du har et konjunktiviskeplads, du har nogle policies for plads. Yes. Du ved, der er noget med management groups og resource groups osv. Ja, og nu har jeg besluttet mig for, at jeg skal bygge nogle container apps. Det er den page service, jeg gerne vil bruge, fordi det skal være containerized, jeg vil gerne have nogle Kubernetes-funktioner, det vil jeg gøre i Kubernetes, alt det har vi også snakket om. Det er ikke meget referencer til vores egen broadcast. Men igen, jeg står med det her blanke canvas bagefter, hvor det siger, nu skal jeg i gang, men alt er tomt. Det er nok noget med DevOps. Hvor langt er vi med? Og det er super godt. Åh, den ser blankt ud. Hvad? Okay. Og filen gør jeg. Det er godt at have noget at læne sig opad, når man står og kigger på den her fuldstændig blanke tavle her. Det er godt med nogle referencer, nogle rammer, jeg kan arbejde indenfor, måske noget erfaring fra nogle andre. Det er her, vi kommer ind i spil. Så vi har en måde, hvordan kommer du i gang med det her på? Hvordan strukturerer du det her på? Vi har tit, at vi laver en mappe til alle vores infrastrukturkomponenter. Ja. Det kan vi kalde for infra. Vi kan også kalde det templates, fordi vi bygger bicep templates. Men det er jo nogle gange, så kunne vi også godt bygge nogle templates i noget kodelogik, eller et andet regi. Så kan det være, at der er noget logik der. Det skal også sige, nu prøver jeg at bygge noget her, og det er jo ikke et endegyldigt svar på noget som helst. Det er en måde, og så kan man strukturerer det ud fra din egen forretningslogik, at bygge det op. Så vi kunne også sagtens have en source mappe. Hernede ligger vores applicationskode. Det kan være, at vi kører et monorepo, hvor alt ligger samme sted. Det kan være, at vi har mange repos, hvor ting ligger samme steder. Ja. Vi plejer i største del af alle tilfælde i de projekter, vi laver, laver vi et separat infrastruktur repository, og så et repository til vores services. Ja. Det kunne være et stort repository for alle vores services. Det kan være Lovacend, det kan være Frontend. Altså, den logik skal jo passe til det, du gerne vil bygge. Ja, ja. Og hvad med så det med devprød og så videre? Det kommer vi til. Det kommer vi til. Så devprød, det er jo sådan noget, vi gerne vil styre i vores pipelines. Ja. Så har vi en infrastruktur mappe. Så har vi faktisk også et sted, hvor vi gerne vil lave noget test, fordi vi kører BICE, vi kører Infrastructures Code, så nu kan vi teste det. Super vigtigt, ikke? Og det kommer vi tilbage til, hvordan sådan noget kører til ud. Nu laver jeg lige et punktum foran. Det er fordi, vi tit bruger den her dot notation, når vi har at gøre med sådan noget, der hedder supportive modules, supportive services. Ja. Noget, vi ikke selv har bygget, men noget, vi tager ind, som vi så bruger som sådan understøtter. Ja. Det kunne være sådan noget som Azure DevOps. Ja. Så det kunne også sagtens være, at vi gik ind, og hvis vi nu brugte GitHub, så havde vi GitHub-brem. Herinde bor vores pipelines. Azure DevOps pipelines, eller GitHub workflows actions. Ja. Nu begynder det stillere og roligt at tage form, det her. Mhm. Under vores infrastrukturmappe, så har vi næsten altid, når FellowMind laver de her projekter, bruger vi PowerShell til at lave vores deployment. Ja. Ved et Microsoft-hus, så er vi rigtig glade for at bruge PowerShell. Det kunne i virkeligheden være hvad som helst. Ja. Igen, så kunne vi sagtens have et sted her, hvor vi har vores bicep-moduler. Mhm. Og vi går så også ind og definerer en main bicep-fil. Mhm. Måske går vi så gar ind og genererer en parametre-fil også til bicep. Ja. Og den går vi så ind og bruger de her moduler, vi bygger. Ja. Det kan også være, at vi ikke selv vil lave modulerne, men bruger sådan noget som Azure Verified Modules. Ja. Og her kommer der, hvor vi så skal begynde at bygge en struktur, som så læner sig op af den logik, der passer til vores forretning, og til den forretningsapplikation, vi bygger. Ja. Så vi sagtens laver en her. Jeg kunne kalde den for Core. Og herinde har vi vores Core Modules. Det kunne være Storage, Account, Bicep. Og så har vi den herinde under vores Core. Vi kunne også sagtens begynde at arbejde med, at vi har en masse små moduler, enkeltvis af ressourcer, og så samle dem i noget, der kunne være noget. back-end. Ja. hernede kunne vi også sagtens under vores module måske bare lave en fil direkte, som var en back-end-file. Og så begynder vi at bygge noget logik, hvor vi siger, okay, et storage-account, det kan være, at jeg har en storage-account på min back-end, og min front-end, hvis det ikke har mening. Det ved jeg ikke, om det gør. Men nu bruger vi det som eksempel. Og så har vi den samme template, vi tager udgangspunkt i, fordi den er jo kurateret også. Vi ved præcis, hvad den her template kan. og så bruger vi den både i vores back-end- og vores front-end- med forskellige parameter-input. Eller det er en Azure Verified module, som er så kurateret af Microsoft. Jeps. Som vi så kan bruge. Ja. Og så begynder vi stille og roligt at bygge en struktur op, hvor vi har en metode for at lave de her, og strukturere vores bicep-moduler. Vi har en metode for at samle dem i den her main bicep-fil. Alt det her, det har vi også snakket om før. Og så kan vi parametrisere det. Og den her parameter-fil, den hedder selvfølgelig ikke main bicep. Vi kan give den en dev her, og så har vi dem dev-testproject. Ja. Så nu er vi stille og roligt ved at få bygget en struktur op. Mhm. Vores source herinde kunne jo så være vores logik, vores C-sharp, vores services, whatever det nu måtte være. Ja. Hvis det her er sådan et rent infrastrukturrepro, kan det være, at vi har nogle scripts herinde, noget kode herinde, som gør nogle ting, som vi ikke kan i bicep. Ja. Vi kan det meste i bicep, men nogle gange så giver det mening, at vi ikke prøver sådan at masse det hele ind i bicep, man har noget logik udenfor. Ja. Okay. Det var sådan lige hurtigt, prøve at bygge den her struktur. Så kan man lige sådan tage et billede af den, som til inspiration. ikke? Så prøver vi at kigge over i, hvordan kunne sådan et projekt, vi så har bygget, se ud. Ja. Det her, det er faktisk taget ud fra et kundeprojekt, vi har lavet. Fuldt anonymiseret. Godt. Vi kan godt se, det er den samme struktur. Det er lidt den samme struktur. Vi har også en docksmappe med, den her er jeg ikke fået med. Her kunne vi jo så skrive vores markdown filer, vi kunne have vores tegninger, alle de her ting, vi gerne vil publicere, måske til noget Azure DevOps, Viki, eller til noget Confluence, eller et eller andet sted, hvor vi vil gerne vil have vores dokumentation. Samle det hele i DevOps, så er det god stil at lave sådan en her. Det kunne vi gøre, ikke? Ja. Vi har vores inframappe. I stedet for en sourcemappe, har vi en scriptsmappe, med noget logik, der gør nogle ting. Den her laver nogle azmanage identities for GitHub. Vi har et script, der laver nye landing zone environments. Tjek. Så har vi en testsmappe. Den vender jeg lige tilbage til. Ja. Som også kører en deployment, kan jeg se. Som også kører et PowerShell, som i virkeligheden også er et PowerShell script. Og så har vi nogle supportive services hernede. Vi er rigtig glade for at bruge MegaLinten internt. Det er vores Cloud Infrastruktur Teams. Ja, og den er nødt til, at I sætter ord på. Hvad er den gør her også? Ja. Så MegaLinten er et vælg af services. Ja. Open Source Services, som kan lave alt fra vulnerability scan til linting af PowerShell og Bicep og alt muligt andre kodeting. JSON. Alt muligt andre ting. Den kan også teste, lave selve test af Bicep og Azure infrastrukturresurser. Så der er et vælg af services. Det, den giver dig, det er, at når du nu har bygget noget kode, så giver den dig en slags kvalitetstjek på det. Så giver den mig et kvalitetstjek. Har jeg ligesom bygget det ud for det, jeg gerne vil? Det er køre igennem det her USX Security og så MegaLinten. Det er faktisk noget, vi er rigtig glade for at bruge og det står selvfølgelig for egen regning, det her står og siger, fordi det er jo et åben produkt og det er noget, vi faktisk bruger en del interne i vores præsikker. Men vi er jo også i den verden, hvor der er masser af mennesker, der så kunne finde på at bruge forskellige AI-værktøjer til at lave kode og der er forskellige mennesker, der gør det med forskellige erfaringer nu. Så når du bedst praksismer med nogle andre omkring, hvad er det for nogle ting, du skal opmærksom på, så kan du jo vælge en rør, det den kommer med, eller du kan sige, hov, vi er klogere og tager ret til. Fuldstændig, og der er jo rigtig mange forskellige open source services, som er samlet ind i det her, men man kan vælge, hvad for nogle man vil bruge og hvad for nogle ikke vil bruge. Og det er jo det, vi har den her mega lintor jamelfil til. Det er jo netop sådan noget med, hvad for nogle lintors er det, vi gerne vil bruge og hvad er det, vi gerne vil gøre. Ja, fordi det er også muligt for at parlamentere det, at sige, der er nogle ting, vi ignorerer, vi har brugt osv. Hvem måde kan du rette det til, når du, der kan du også starte relativt blødt jo. Ja, ja. Og så størger vi til at sige, nu er vi blevet klogere på, hvad vil den? Fuldstændig. Hvad er det for, hvad er det navnestandard, eller hvor meget vil vi efterhåndens vil blive været? Ja, og det kommer vi også lidt ind på, når vi så kommer ind til nogle af de andre testværktøjer. Så er der noget bicep configuration fil, som også viser noget konfiguration her. Der bruger vi nogle preview extensions, og der kan man jo ikke definere sin PowerShell. Og så er der det her PS Rule. Ja. PS Rule for Azure. Ja. er et open source, i virkeligheden. Lægge ind på GitHub, og lavet af en Microsoft person selv. Så er der et test framework til venture. Ja. Så er det tester for World Architected Framework, og det har vi næsten også altid med. Den måde, vi kører det på, det er egentlig, at det er nogle PowerShell-moduler. Mhm. I PowerShell-moduler har vi det her PS Rule Deployment Script. PS Rule Deployment Script, det går ind og definerer, hvad er det for nogle moduler, vi gerne vil have. nogle Azure-regler, nogle kaffregler. Ja. Og så går vi egentlig ind, og så implementerer vi det her modul fra PS Gallery, og så kan vi gå i gang med at teste det. Det er så den her Assert PS Rule, så fortæller I, hvad for nogle volder er det, vi gerne vil teste, hvad for nogle options er det, vi har med, og hvad skal vores outcome? Jeg vil kun have failed, da vi kan. Ja, fordi det er spørgsmålet, hvordan får du det her output, og hvornår kommer det i brug af alt det her? Det er når du skal til at bruge din pipeline ud. Lige præcis. Så årsagen til, vi har alt det her i et PowerShell-script, det er, at nu kan jeg teste det lokalt på min egen maskine, eller jeg kan køre det selv samme script i mine pipelines. Så i mine CE-stages, når jeg laver min test, så tester jeg min infrastruktur. Er den, som jeg gerne vil have? Ja. og den her PS-script for Asia er også bundet op imod de kontroller, der ligger i well-architected framework. Ja. Og bygger det her på, og bliver udvidet hele tiden. Ja. Og er aktivt udviklet af Microsoft, og vi jo er at bidrage, prøver også at bidrage med feedback, hver gang vi finder små fejl i det. Nå, men det betyder også så det, at du er en lille smule udsikker på, hvad du laver. Er det her godt? Jamen, så får du faktisk noget ret godt feedback i forhold til... Så får du hurtigt at vide, Hav, din... Nu bliver jeg meget specifik, din Key Vault, eller storage account, bruger TLS 1.1. Ja. Den skal bruge minimum 1.2. Jamen, så får du det fange rigtig hurtigt i processen, at din infrastruktur ikke lever op til. Jeg tror, at ordentligt købt, du får links til, hvorhenne i varfdokumentationen... Ja. Så den er... Vi kommer ikke lige ind i dybden af den, men den er super god til at få hjælp. Hvad er det egentlig for en kontrol, jeg tester efter? Hvad er det for en kontrol? Hvad er det, der er anbefaling? Ja. Bicep-eksempelkode på, hvad det så skal rette. Ja. Og hvis du så siger, det er fint, at der er den anbefaling, men det er fløjtende ligegladende. Jeg vil bruge TLS 1.1. Så kan man gå ind og bruge de her filer, der ligger herinde. Ja. Til at lave nogle exclusions, ikke? Her, der har vi været... Der er der lavet mange exclusions, ikke? Ja. Og man kan godt gå ind og lave nogle specifikke ting. Ja. Derfor har vi den her PS Rule, Marve. Hvor vi så kan gå ind og lave nogle mere specifikke regler, hvis tag er lige med dev, så er det okay, at du ikke er high available school. Ja, ja. Så er vi begyndt at blive logik i vores test. Ja, ja. For der er forskelle på dev og til. Ja, selvfølgelig. Og så har vi en Readme-fil og en GetikNorv-fil. Ja, sådan det er ikke. Det er rigtig dejligt. Hvis vi så kommer lidt nærmere ind på selve vores infrastruktur. Den måde, vi deler det op på, kunne være en shared Bicep-bil. og så i det her tilfælde, der har vi lavet en core-mappe med alle vores baselines. Der er en baseline, hvordan vi laver en container app, hvordan vi laver en container app environment, hvordan vi laver application insights. Så kan det, så har vi, her har vi ikke brugt Azure Verified Modules. Nej. Det kunne vi også godt have gjort. Ja. Og så kan man så ind per nogle forskellige services, man har valgt, vi har valgt at lave noget her, der hedder shared services og noget, der hedder platform til et specifikt produkt. og så går man ind, og så samler vi de moduler i noget backend, i noget common, i noget communication, noget database. Og de moduler, er det jo nogle små kortnogne, eller er det jo også stadig nogle lange nogen, altså de moduler, der er nogen, der vi skal kigge på. Dem kan vi sagtens kigge på. Så det her backend modul, det eneste, den gør, det er i virkeligheden at deploye en container app environment. Ja. Men referere til det, der ligger nede i vores core. Ja, lige præcis. Og så nu har vi faktisk fra den her infrastruktur-mappe, eller det her repo, deployet noget infrastruktur klar, så man måske i et andet repo kan begynde at proppe services. Ja, lige præcis. Så her er der ligesom en logik, som er struktureret ud fra, hvad kan mening her? Det kan også være, det jo bare var et system, og vi ikke havde flere services, så kunne det være, der bare var agent direkte, så havde det ikke været den her mappeinddeling, men så bygger man det ud fra den logik, der giver mening. Det skal lære godt. Ja, det kan godt lide, det er, når du har de her mange filer, så er det også nemt, at vedligeholde noget af det. Selvfølgelig kan du stadigvæk se, at det er linje 87 her henad, men det er alle andre lige nemmere også at vide, at det er den her fil med det her. Ja, ja. Altså, du skal kunne dele arbejdsopgaven lidt op, hjælpe sig til at hjælpe for en ven at sige, jamen det her, det ved jeg ingenting om, det er lidt for kompenteret for mig. Ja, lige præcis. Hey, fix det her, det kan vi godt. Og her kan jeg jo også sige, det er de samme moduler, der går igen, så hvis jeg retter dem et sted, så vil det blive brugt på tværs af alle mine services, og så når jeg kører min test, så vil tingene fejle. Og så skal jeg ind, nå, det er fordi, jeg har sat en ny parameter ind på en korservice, og den bruger jeg ikke. Sådan noget. Så vil man fange de der ting, inden vi smider det ind i vores pipeline. Inden vi egentlig tester den funktionale del af vores indmiddelse. Men det vil så sige, at du kan jo så vil iholde det hele samlet, og du får den her versionering, du får styr på det. Ja. Slit. Og så vil jeg jo selvfølgelig gerne slå et slag for at virkelig kigge på de her Azure Verified Modules, for jeg synes, det giver meget, at Microsoft har de her kurvaterede redskaber, og templates, så vi ikke selv skal bruge tid på at vedligeholde de her enkelte små komponenter. Ja, for det er jo en anden del af det også, som jeg synes, vi jævnligt opdager. Det er jo ikke, fordi Microsoft, de bevidst går at lave breaking changes, men de udvikler deres platform hele tiden, og det er med Azure Pan, og det er jo helt vildt så mange funktionaliteter, det de har, det vil sige, der kommer jo ting, hvor du skal, i det må vi hellere tage brug det her. Eller de har lavet nogle ting om at sige. Der kommer ændringer. Jeg kan ikke lave den her struktur en gang, og så tro, at så er det godt, vel jeg skal hele tiden lægge på og ændre og lægge på. den virker ikke om et år. Nej, det vil jeg jo ikke virke om et år. Nej, det vil jeg ikke, men der er i hvert fald kommet mange nye, smartere måder at gøre ting om et år. Ja, præcis, ja. Så det er en del af det også, ikke også? at lave vores deployment. Det her meget simpelt script, det tager nogle parameterinput om noget tenant.id og resource group name, subscription, informationer vi skal have for at lave en deployment. Ja. Og så tager den i virkeligheden og samler det, laver et navn på den deployment, og så deployer den det. Fordi igen, så kan jeg køre det her, okay, og jeg kan køre det i mine pipelines. Ja. Så det der med at være meget afhængig af de her pipeline tasks, er noget, som vi er mindre glade for, fordi så kan jeg først tæt, teste, når jeg har sindes deres sted. Ja. Og så får jeg alle de her røde pipelines, der kører der nedad. Det er måske svært at undgå alligevel, for vi laver også nogle ændringer i vores pipeline-jarmelfiler, men så prøver vi også. Der er også nogle begrænsninger, hvor mange pipelines skulle køre os nogle ting. Ja, ja. Ja. Godt. En sidste par ting, vi lige kan kigge lidt på. Ja. Functions. Der er også en function map ved infrastrukturen, og det er fordi, vi kan i BICEP lave vores egne funktioner. Mhm. Og herinde har vi en ret simpel naming function. Så har vi lavet en navnestruktur, som ligner den navnestruktur, Microsoft har i deres kraft, men det er sådan en naming abbreviation, af hvordan man laver den her standard navnestruktur. Ja, ja. Og så går vi i virkeligheden ind og kan lave en funktion, som hedder naming, og den funktion, der har vi navn, med eller uden name, eller name without dash. Og så når jeg går ind og laver min navngivning, af mine services, så kan jeg vælge at bruge en function til det. Og spørgsmålet er, om jeg har et godt eksempel for det. Det har jeg sørger med. Her, der har jeg resource group, backend name, naming, og så siger jeg, at den skal hedde RG, og den skal hedde noget med backend, og så kommer resten, og jeg skal bruge den funktion, der hedder name, eller name without dash. Sådan. Og så kan jeg lave en navnstruktur. Så vil du være... Og så hvis jeg bruger den her funktion, hver gang jeg laver et navn, så har jeg sikret mig, at navnene overholder... Ja, ret... Altså, det er jo ikke rocket science, det er sådan en ret simpel måde at lave sådan en... Men det er en dejlig automatisering, den der, når du ikke engang har tænkt over det. Lige præcis, ikke? Så det er sådan en ret simpel måde. så... Og det kan vi også lige vise, at vi importerer den funktion. Så har jeg importeret den her, den skal kalde jeg for name, og den ligger her, og så har jeg min naming funktion nu. Så det er igen... Det er sådan en lille trick, ikke? Så kan man tage den med i baglommen. Godt. Igen. Pipelines eller workflows, som hedder GitHub. Det er jo også noget, vi bruger i stor stil her, så i vores... I den her pipeline, den her Azure pipeline, er vi jo også inde og sætte nogle standarder for, hvordan vi laver nogle stages i forhold til... Det kunne være et CI stage, hvor vi gerne vil køre noget built-in-test. Det kunne være et... Her har vi så noget, vi kalder for CD-test stage. I den her, som så også faktisk deployer noget infrastruktur til vores test environment. Og her deployer vi noget infrastruktur til vores prod environment. og så har vi også noget, hvor vi går ind og siger, noget vi godt kan lide at arbejde med, det har vi så ikke i det her eksempel, men hvor vi faktisk i vores infrastruktur definerer, hvad der er persistent og hvad der er non-persistent. Og det kan vi gøre med nogle tags, for eksempel. Så man siger, hvad er persistent data og hvad er non-persistent data? Så vi faktisk kan gå ind i vores dev-miljøer, vores testmiljøer, og så køre det step, der lige lå nedest her, som var sådan et destroy dev, eller test environment. Destroy environment. Men vi vil jo ikke destroy det der persistent data, for måske har vi nogle testbrugere, som har bygget noget dummy, noget testdata op, og måske bliver der lavet nogle ting, som vi ikke vil fjerne. Men vi vil gerne fjerne alt andet, fordi kost er en faktor. Ja, ja, men det skal vi til alvorligt. det er der, du håndterer de ting. Ja, så det er også noget, vi arbejder meget med. Det er det her, hvordan kan vi ligesom give noget information til vores infrastruktur, for hvad der må slettes, og hvad der ikke må slettes, og så lader du automatik. Nå, men det er jo noget, du skal være bevidst af, at det er dig, der har ansvaret for det. Det er dig, der bygger køren. Det er også dig, der har brugt pengene. Lige præcis. Lige præcis. Hvis du vil bygge og testvind, så glemmer du at slukke det igen efter tre uger. Lige. Ja, præcis. Så det er også noget, man kan tage med her, i den måde at strukturere tingene på. Og så kan man sige, Pipelines er et eksempel. Man kan godt have, her er der en Pipeline. Man kan også dele den op, ligesom der er i det her GitHub Workflow, i flere stages, eller i nogle templates, der kalder andre ting. Så er det bare den samme måde at strukturere det på. Altså ligner det jo meget hinanden. Der er lidt nogle forskellige funktioner imellem de to metoder. Men processen og metoden er den samme. Og inddelingen er den samme. Og så er det det, det næste er jo så, nå men nu har jeg lavet en eller anden struktur, jeg har nogle redskaber i min værktøjskasse, jeg vil gerne bruge hver gang, jeg laver nogle nye applikationer. Hvordan sikrer jeg det? Hvordan sikrer jeg det ikke, at blank canvas hver gang? Og det er jo så her, det bliver spændende. Fordi hvordan sikrer jeg, at der bliver lavet DevOps-projekter eller GitHub-projekter på en government måde, sikker måde, hvordan sikrer jeg mig, at det er måske noget kode, der allerede er der i forvejen. Altså ikke sådan en self-service-tankegang. Det er jo noget, der skal bygges op og noget, som vi i fellowmind også bruger tid på og har i vores manage platform. Men det er jo også en tankegang. Så nu har vi en beslutning for, hvordan en ramme kan se ud. Hvordan får jeg så det ind hver gang? Hvis jeg ønsker, at det er med hver gang. For jeg kan sagtens have nogle udviklere derude, som er virkelig dygtige og ved præcis, hvordan de vil strukturere dem, så det passer til dem. De skal jo ikke have måske standarden. Eller måske skal de? Nej, men så kan det jo også nemt ske, at når du har lavet den her standard og forstyrrer på nogle værktøjer, så er det den, du vil bruge også til næste projekt. Lige præcis. Så vi skal zip den og pakke den ud igen, på en lidt smartere måde, end at zip den og pakke den ud igen. Det var et crash course indblik i hvordan vi i Cloud Infrastructure Teamet tit i vores app-monerization-projekt og strukturerer infrastruktur. God. Vi håber, jeg har lyst til at skåne kode derude. Ej god, hvis I skal bruge hjælp. Ellers tak for i dag.