Software engineering-systemen toepassen

Zodra u de problemen begrijpt die u als eerste in uw platform engineeringtraject wilt aanpakken, kan het verbeteren van selfservice voor ontwikkelaars bovenaan de lijst komen te komen. Een van de eenvoudigste manieren om geautomatiseerde selfservice-ervaringen mogelijk te maken, is door uw bestaande technische systemen opnieuw te gebruiken. Deze systemen zijn niet alleen bekend bij u en uw interne klanten, maar ze kunnen een breed scala aan automatiseringsscenario's mogelijk maken, zelfs als de eerste gebruikerservaring niet mooi is.

In dit artikel vindt u enkele tips voor het toepassen van uw technische systemen om een breder scala aan selfservicescenario's aan te pakken en hoe u best practices kunt inkapselen in sjablonen waarmee u goed kunt beginnen en goed kunt blijven.

Uw basisprocedures voor DevOps en DevSecOps evalueren

Technische systemen zijn een essentieel aspect van uw interne ontwikkelplatform. Als u echter al geen systemen hebt die zich richten op ten minste enkele van de belangrijkste tenants van DevOps en DevSecOps, zullen de problemen die u identificeert, u waarschijnlijk vertellen dat u daar moet beginnen. Interne ontwikkelplatforms bouwen op basis van deze platforms op om de cognitieve belasting voor alle betrokkenen te verminderen.

Kort samengevat combineert DevOps ontwikkeling en bewerkingen om mensen, processen en technologie te verenigen in de planning, ontwikkeling, levering en bewerkingen van toepassingen. Het is bedoeld om de samenwerking te verbeteren tussen rollen die zich in het verleden in een silo hebben verspreid, zoals ontwikkeling, IT-bewerkingen, kwaliteitsengineering en beveiliging. U brengt een doorlopende lus tot stand tussen ontwikkeling, implementatie, bewaking, observatie en feedback. DevSecOps-lagen in deze lus met continue beveiligingsprocedures tijdens het ontwikkelingsproces van toepassingen.

Het DevOps-resourcecentrum van Microsoft is een uitstekende plek om te zoeken naar advies over de typen processen en systemen die u nodig hebt, dus deze worden in deze sectie niet uitgebreid besproken. Dit worden essentiële ingrediënten naarmate je verder gaat. En vergeet niet rekening te houden met recente DevSecOps-onderwerpen, zoals beveiliging van de toeleveringsketen van containers in uw plannen.

Zie Metrische gegevens die u kunt overwegen voor meer informatie over continue feedback. U vindt ook meer informatie over hulpprogramma's voor gebruik in de gebieden waarneembaarheid, bewaking en continue feedback in Uw toepassingsplatform verfijnen.

In de rest van dit artikel richten we ons op verbeteringen die meer rechtstreeks worden toegeschreven aan de platformengineering: verharde paden, geautomatiseerd inrichten van infrastructuur (naast toepassingsimplementatie), het instellen van coderingsomgevingen, samen met selfservice-inrichting en configuratie van hulpprogramma's, teamassets en services die niet rechtstreeks deel uitmaken van de ontwikkelingslus van toepassingen.

De gewenste verharde paden instellen

Als u al meerdere sets hulpprogramma's hebt die deel uitmaken van uw technische systemen, moet u in een vroeg stadium beslissen of u deze wilt consolideren als onderdeel van uw eerste engineering-inspanningen op het platform of dat u vanaf het begin een aantal verschillende hulpprogramma's wilt ondersteunen. In de meeste gevallen is het definiëren van een set verharde paden binnen deze constellatie van hulpmiddelen het meest effectief en biedt het een grotere mate van flexibiliteit.

Naarmate u naar een productmentaliteit overstapt, kunt u de technische systemen binnen deze geplaveide paden beschouwen als hulpprogramma's die centraal worden beheerd als een service voor ontwikkelteams. Afzonderlijke teams of afdelingen binnen uw organisatie kunnen vervolgens afwijken, maar er wordt verwacht dat ze hun hulpprogramma's afzonderlijk beheren, onderhouden en betalen, terwijl ze zich nog steeds houden aan eventuele nalevingsvereisten. Dit biedt een manier om nieuwe hulpprogramma's zonder onderbreking in het ecosysteem te voeren, omdat u alles kunt evalueren dat na verloop van tijd afwijkt voor mogelijke opname in een geplaveid pad. Zoals een platform engineering lead het uit te leggen:

Je kunt nog steeds je eigen ding doen, maar doe het in een richting die we gaan... u kunt veranderen wat u wilt, maar dit wordt uw verantwoordelijkheid. Jij bent de eigenaar van de veranderingen – jij bent eigenaar van de scherpe messen. - Mark, platform engineering lead, Large European Multinational Retail Company

Gezien het feit dat een belangrijk doel voor platform engineering is om over te schakelen naar productmentaliteit, waarbij u waarde biedt aan uw interne klanten, werkt deze constellatiebenadering doorgaans beter dan een top-down-mandaat. Wanneer u uw geplaveide paden instelt en verfijnt, kunnen teams met enige flexibiliteit input geven en voldoen aan eventuele echt unieke vereisten voor een bepaalde toepassing zonder dat dit van invloed is op anderen in de organisatie. Dit leidt tot een reeks volledig geplaveide, gouden paden, terwijl andere slechts gedeeltelijk zijn geplaveid. In gevallen waarin er geen unieke vereisten zijn, zorgt het extra werk dat ontwikkelteams nemen er natuurlijk voor dat ze na verloop van tijd naar een ondersteund pad willen overstappen.

Als u de voorkeur geeft aan een consolidatiestrategie, moet u er rekening mee houden dat het migreren van bestaande toepassingen meer werk kan zijn dan verwacht. Om te beginnen wilt u zich dus richten op het juiste beginaspect van deze ruimte en zich richten op nieuwe projecten. Dit geeft u uw eerste geplaveide pad, terwijl alles wat er bestaat inherent onverhard is. Ontwikkelteams op het onverharde pad overwegen dan te verhuizen zodra uw nieuwe geplaveide pad de waarde ervan voor de organisatie laat zien. Op dat moment kunt u een get right-campagne uitvoeren om iedereen op de gewenste status te krijgen via tweerichtingscommunicatie, omdat dev-teams dit als een voordeel beschouwen in plaats van een belasting. Tijdens de campagne kunnen platformengineeringsteams zich richten op het helpen van teams bij het migreren, terwijl de ontwikkelaarsteams feedback geven over het verbeteren van de geplaveide paden.

Probeer hoe dan ook niet het gebruik van uw verharde paden te verplichten. De meest effectieve manier om ze uit te rollen, is door te benadrukken wat teams eruit halen in plaats van door geforceerde acceptatie. Omdat uw interne ontwikkelaarsplatform zich richt op het gelukkig maken van exact dezelfde teams, is de druk op budget en tijd-tot-waarde op individuele leiders de neiging om voor de rest te zorgen. Haal de juiste campagnes en bieden vervolgens een mogelijkheid voor tweerichtingsgesprekken op de beste manier voor mensen die een onverhard pad hebben om over te schakelen.

Automatiseringsprogramma's voor ontwikkelaars gebruiken om selfservice voor uw geplaveide paden te verbeteren

Een deel van het maken van uw eerste geplaveide pad moet zijn om uw belangrijkste automatiseringsproducten voor ontwikkelaars vast te stellen. Deze zijn belangrijk wanneer u begint na te denken over het inschakelen van selfservicemogelijkheden voor ontwikkelaars.

Automatische inrichting van toepassingsinfrastructuur inschakelen tijdens continue levering

Als deze problemen nog niet zijn geïmplementeerd, wijzen de problemen die u tijdens de planning hebt geïdentificeerd waarschijnlijk op problemen die kunnen worden opgelost met continue integratie (CI) en continue levering (CD). Producten zoals GitHub Actions, Azure DevOps, Jenkins, samen met pull-gebaseerde GitOps-oplossingen zoals Flux of Argo CD, bevinden zich in deze ruimte. U kunt aan de slag met deze onderwerpen in het Microsoft DevOps-resourcecentrum.

Zelfs als u al een manier hebt geïmplementeerd om uw toepassing continu te implementeren in een bestaande infrastructuur, kunt u overwegen om infrastructuur als code (IaC) te gebruiken om de benodigde toepassingsinfrastructuur te maken of bij te werken als onderdeel van uw CD-pijplijn.

Bekijk bijvoorbeeld deze afbeeldingen waarin twee benaderingen worden weergegeven die gebruikmaken van GitHub Actions om de infrastructuur bij te werken en in Azure Kubernetes Service te implementeren: één met behulp van pushimplementaties en één op pull gebaseerde implementaties (GitOps).

Zie CI/CD voor AKS-apps met GitHub Actions en Gitflow voor meer informatie over elke benadering.

Welke u kiest, is vaak gebaseerd op uw bestaande IaC-vaardigheden en de details van uw doeltoepassingsplatform. De GitOps-benadering is recenter en populair bij organisaties die Kubernetes gebruiken als basis voor hun toepassingen, terwijl het pull-gebaseerde model u momenteel de meeste flexibiliteit biedt vanwege het aantal beschikbare opties. We verwachten dat de meeste organisaties een combinatie van de twee gebruiken. Hoe dan ook, als u goed op de hoogte bent van IaC-procedures, kunt u patronen leren die van toepassing zijn op verdere automatiseringsscenario's.

IaC centraliseren in een catalogus of register om de beveiliging te schalen en te verbeteren

Als u IaC in verschillende toepassingen wilt beheren en schalen, moet u uw IaC-artefacten centraal publiceren voor hergebruik. U kunt bijvoorbeeld Terraform-modules gebruiken in een register, Bicep-modules, Radius-recepten of Helm-grafieken die zijn opgeslagen in een cloudeigen OCI-artefactregister, zoals Azure Container Registry (ACR), DockerHub of de catalogus in Azure Deployment Environments (ADE). Voor GitOps en Kubernetes kunt u met de Cluster-API (en implementaties zoals CAPZ) Kubernetes-workloadclusters beheren, terwijl aangepaste resourcedefinities zoals Azure Service Operator extra ondersteuning kunnen bieden voor andere soorten Azure-resources, andere hulpprogramma's zoals crossplane-ondersteuningsresources in meerdere clouds. Hiermee kunt u gecentraliseerde of algemene Helm-grafieken in iets als ACR gebruiken voor een breder scala aan scenario's.

Het centraliseren van IaC verbetert de beveiliging doordat u meer controle hebt over wie updates kan uitvoeren, omdat deze niet meer worden opgeslagen met toepassingscode. Er is minder risico op een onbedoelde onderbreking die wordt veroorzaakt door een onbedoelde wijziging tijdens een code-update wanneer experts, bewerkingen of platformtechnici de benodigde wijzigingen aanbrengen. Ontwikkelaars profiteren ook van deze bouwstenen omdat ze niet zelf volledige IaC-sjablonen hoeven te maken en automatisch hoeven te profiteren van gecodeerde best practices.

Welke IaC-indeling u kiest, is afhankelijk van uw bestaande vaardighedenset, het controleniveau dat u nodig hebt en het app-model dat u gebruikt. Azure Container Apps (ACA) en het recente experimentele Radius OSS-incubatieproject zijn bijvoorbeeld meer eigen mening dan het rechtstreeks gebruiken van Kubernetes, maar stroomlijnen ook de ontwikkelaarservaring. De trainingsmodule Cloudservicetypen beschrijven kan u helpen de voor- en nadelen van verschillende modellen te begrijpen. Hoe dan ook, het verwijzen naar gecentraliseerde en beheerde IaC in plaats van volledige definities in uw bronstructuur heeft aanzienlijke voordelen.

Het behouden van alle benodigde inrichtingsidentiteiten of geheimen op een manier dat ontwikkelaars niet rechtstreeks toegang hebben tot de lagen in de basisbouwstenen voor governance. Bekijk bijvoorbeeld deze afbeelding van de rolscheiding die u kunt bereiken met Behulp van Azure Deployment Environments (ADE).

Hier ontwikkelen platformtechnici en andere specialisten IaC en andere sjablonen en plaatsen deze in een catalogus. Bewerkingen kunnen vervolgens beheerde identiteiten en abonnementen toevoegen op 'omgevingstype' en ontwikkelaars en andere gebruikers toewijzen die deze mogen gebruiken voor inrichting.

Ontwikkelaars of uw CI/CD-pijplijn kunnen vervolgens de Azure CLI of Azure Developer CLI gebruiken om vooraf geconfigureerde en beheerde infrastructuur in te richten zonder zelfs maar toegang te hebben tot het onderliggende abonnement of de onderliggende identiteiten die hiervoor zijn vereist. Of u nu iets als ADE gebruikt of niet, uw systeem voor continue levering van keuze kan u helpen de infrastructuur veilig bij te werken door geheimen te scheiden en IaC-inhoud te kopen van locaties die ontwikkelaars niet zelf kunnen openen of wijzigen.

Selfservice inschakelen in scenario's die verder gaan dan continue levering van toepassingen

Hoewel CI- en CD-concepten zijn gekoppeld aan de ontwikkeling van toepassingen, zijn veel van de dingen die uw interne klanten willen inrichten niet rechtstreeks gekoppeld aan een bepaalde toepassing. Dit kan een gedeelde infrastructuur zijn, het maken van een opslagplaats, inrichtingshulpprogramma's en meer.

Als u wilt weten waar dit kan helpen, moet u nadenken over waar u momenteel handmatige processen of processen op basis van een servicedesk hebt. Denk voor elk na over de volgende vragen:

• Hoe vaak vindt dit proces plaats?
• Is het proces traag, foutgevoelig of vereist het aanzienlijke werk om te bereiken?
• Zijn deze processen handmatig vanwege een vereiste goedkeuringsstap of gewoon vanwege een gebrek aan automatisering?
• Als een fiatteur nodig is, is deze dan bekend met broncodebeheersystemen en pull-aanvraagprocessen?
• Wat zijn de controlevereisten voor de processen? Verschillen deze van de controlevereisten van uw broncodebeheersysteem?
• Zijn er processen waarmee u kunt beginnen met een lager risico voordat u verdergaat met complexere processen?

Identificeer frequente, hoge inspanning of foutgevoelige processen als potentiële doelen om eerst te automatiseren. Vervolgens bespreken we een aantal eenvoudige manieren om dit te laten gebeuren.

Het alles als codepatroon gebruiken

Een van de leuke dingen van Git naast de alomtegenwoordigheid is dat het is bedoeld als een veilige, controleerbare bron van informatie. Naast de doorvoergeschiedenis en toegangsbeheer bieden concepten zoals pull-aanvragen en vertakkingsbeveiliging een manier om specifieke revisoren, een gespreksgeschiedenis en of geautomatiseerde controles vast te stellen die moeten worden uitgevoerd voordat ze worden samengevoegd in de hoofdbranch. In combinatie met flexibele taakengines, zoals die in CI/CD-systemen, beschikt u over een beveiligd automatiseringsframework.

Het idee achter alles als code is dat u bijna alles kunt omzetten in een bestand in een beveiligde Git-opslagplaats. Verschillende hulpprogramma's of agents die zijn verbonden met de opslagplaats kunnen vervolgens de inhoud lezen. Door alles als code te behandelen, kunt u de herhaalbaarheid verbeteren door middel van sjablonen en vereenvoudigt u selfservice voor ontwikkelaars. Laten we enkele voorbeelden bekijken van hoe dit kan werken.

IaC-patronen toepassen op elke infrastructuur

Hoewel IaC populair werd voor het automatiseren van de levering van toepassingen, wordt het patroon uitgebreid naar alle infrastructuur, hulpprogramma's of services die u mogelijk wilt inrichten en configureren, niet alleen die gekoppeld aan een specifieke toepassing. Bijvoorbeeld het delen van K8's met clusters waarop Flux is geïnstalleerd, het inrichten van iets als DataDog dat door meerdere teams en toepassingen wordt gebruikt, of zelfs het instellen van uw favoriete samenwerkingshulpprogramma's.

De manier waarop dit werkt, is dat u een afzonderlijke, beveiligde gecentraliseerde opslagplaats hebt die een reeks bestanden bevat die aangeven wat moet worden ingericht en geconfigureerd (in dit geval alles van Bicep, Terraform tot Helm-grafieken en andere systeemeigen Kubernetes-indelingen). Een operationeel team of een andere set beheerders is eigenaar van de opslagplaats en ontwikkelaars (of systemen) kunnen pull-aanvragen indienen. Zodra deze pull-aanvragen door deze beheerders zijn samengevoegd in de hoofdbranch, kunnen dezelfde CI/CD-hulpprogramma's die tijdens de ontwikkeling van toepassingen worden gebruikt, worden gestart om de wijzigingen te verwerken. Bekijk deze afbeelding waarin gebruik wordt gemaakt van GitHub Actions en IaC en implementatie-identiteiten die zijn ondergebracht in Azure Deployment Environments:

Als u al een GitOps-benadering gebruikt voor toepassingsimplementatie, kunt u deze hulpprogramma's ook opnieuw gebruiken. Door hulpprogramma's zoals Flux en Azure Service Operator te combineren, kunt u uitbreiden buiten Kubernetes:

In beide gevallen hebt u een volledig beheerde, reproduceerbare en controleerbare bron van informatie, zelfs als wat wordt geproduceerd niet voor een toepassing is. Net als bij toepassingsontwikkeling kunnen alle geheimen of beheerde identiteiten die u nodig hebt, worden opgeslagen in de pijplijn-/werkstroomengine of in de systeemeigen mogelijkheden van een inrichtingsservice.

Omdat de personen die de pull-aanvragen maken geen directe toegang hebben tot deze geheimen, biedt het ontwikkelaars een manier om veilig acties te starten waarvoor ze zelf geen directe toestemming hebben. Hierdoor kunt u voldoen aan het principe van minimale bevoegdheden, terwijl ontwikkelaars nog steeds een selfserviceoptie hebben.

Ingerichte infrastructuur bijhouden

Wanneer u begint met het schalen van deze benadering, moet u bedenken hoe u de infrastructuur wilt bijhouden die is ingericht. Uw Git-opslagplaats is een bron van waarheid voor de configuratie, maar vertelt u niet de specifieke URI's en statusinformatie over wat u hebt gemaakt. Als u echter een alles als-code-benadering volgt, krijgt u een bron van informatie die u kunt gebruiken om een inventaris van de ingerichte infrastructuur te synthetiseren. Uw inrichting kan ook een goede bron van deze informatie zijn die u kunt gebruiken. Azure-implementatieomgevingen bevatten bijvoorbeeld mogelijkheden voor het bijhouden van omgevingen waar ontwikkelaars inzicht in hebben.

Zie Een selfservicebasis voor ontwikkelaars ontwerpen voor meer informatie over het bijhouden van verschillende gegevensbronnen.

De beveiliging toepassen als code en beleid als codepatronen

Hoewel het inrichten van infrastructuur nuttig is, is het net zo belangrijk om ervoor te zorgen dat deze omgevingen veilig zijn en over het algemeen het beleid van uw organisatie volgen. Dit heeft geleid tot de opkomst van het concept 'beleid als code'. Hier kunnen configuratiebestanden in een opslagplaats voor broncodebeheer worden gebruikt om bijvoorbeeld beveiligingsscans uit te voeren of infrastructuurbeleid toe te passen.

Veel verschillende producten en open source projecten ondersteunen deze benadering, waaronder Azure Policy, Open Policy Agent, GitHub Advanced Security en GitHub CODEOWNERS. Wanneer u de infrastructuur, services of hulpprogramma's van uw toepassing selecteert, moet u evalueren hoe goed deze patronen worden ondersteund. Zie Uw toepassingsplatform verfijnen voor meer informatie over het verfijnen van uw toepassing en governance.

Alles gebruiken als code voor uw eigen scenario's

Alles als code breidt deze patronen uit naar een breed scala aan automatiserings- en configuratietaken buiten IaC. Het kan niet alleen het maken of configureren van elk type infrastructuur ondersteunen, maar ook het bijwerken van gegevens of het activeren van werkstromen in een downstreamsysteem.

De pull-aanvraag wordt een goede selfservicegebruikerservaring voor verschillende processen, met name wanneer u aan de slag gaat. De processen krijgen op natuurlijke wijze de voordelen van beveiliging, controleerbaarheid en terugdraaien die Git zelf biedt en de betrokken systemen kunnen ook in de loop van de tijd veranderen zonder dat dit van invloed is op de gebruikerservaring.

Teams als code

Een voorbeeld van het toepassen van alles als code op uw eigen scenario's is de teams als codepatroon. Organisaties passen dit patroon toe om teamlidmaatschap te standaardiseren en, in sommige gevallen, ontwikkelaarshulpprogramma's/servicerechten voor een breed scala aan systemen. Dit patroon elimineert handmatige onboarding en offboarding van servicedeskprocessen die worden aangestuurd door de noodzaak voor systeemontwikkelaars en operators om toegang te krijgen tot hun eigen groeperings-, gebruikers- en toegangsconcepten. Handmatige servicedeskprocessen vormen een potentieel beveiligingsrisico omdat het mogelijk is om toegang te veel in te stellen. Wanneer u de teams als codepatroon gebruikt, kan de combinatie van git- en pull-aanvragen selfservice vanuit een controleerbare gegevensbron inschakelen.

Bekijk het blogbericht van GitHub over hoe ze rechten beheren voor een voorbeeld van een uitgebreide variatie van dit patroon. GitHub heeft ook opensource-implementatie van hun geavanceerde rechten geïmplementeerd , zodat u deze kunt uitproberen of gebruiken. Hoewel in het blogbericht alle rechten van werknemers worden beschreven, kunt u de teams als codeconcept toepassen op scenario's met een meer beperkt bereik van ontwikkelteams. Deze ontwikkelteams worden mogelijk helemaal niet weergegeven in een organigram van werknemers en hebben betrekking op eigen hulpprogramma's of services die het onboarden of offboarden van teamleden kunnen bemoeilijken.

Hier volgt een samenvatting van een vereenvoudigde variant van dit idee die gebruikmaakt van een CI/CD-systeem en id-providergroepen om updates te coördineren:

Voor dit voorbeeld gaan we uit van het volgende:

1. Elk betrokken systeem is ingesteld voor het gebruik van uw id-provider (bijvoorbeeld Microsoft Entra ID) voor eenmalige aanmelding (SSO).
2. U gebruikt id-providergroepen (bijvoorbeeld Entra-groepen) in verschillende systemen om het lidmaatschap per rol te beheren om de complexiteit te verminderen en gecentraliseerde controle te onderhouden.

Op hoog niveau werkt dit patroon als volgt:

1. Een centrale, vergrendelde Git-opslagplaats bevat een set bestanden (meestal YAML) die elk abstract team, gerelateerd gebruikerslidmaatschap en gebruikersrollen vertegenwoordigen. Eigenaren/fiatteurs voor teamwijzigingen kunnen ook op dezelfde plek worden opgeslagen (bijvoorbeeld via CODEOWNERS). De verwijzing naar een gebruiker in deze bestanden is de id-provider, maar deze opslagplaats fungeert als de bron van waarheid voor deze teams (maar niet voor gebruikers).
2. Net als in andere codecases, worden alle updates voor deze bestanden uitgevoerd via pull-aanvragen. Hierdoor worden gesprekken en gerelateerde deelnemers aan de aanvraag gekoppeld aan Git Commit voor controlebaarheid.
3. Potentiële klanten en individuele gebruikers kunnen pull-aanvragen maken om personen toe te voegen/te verwijderen, en ontwikkelaars-leads en andere rollen kunnen nieuwe teams maken met behulp van pull-aanvragen die met een nieuw teambestand uit een sjabloon worden gebruikt.
4. Wanneer een pull-aanvraag wordt samengevoegd met main, werkt een CI/CD-systeem dat is gekoppeld aan de opslagplaats, het systeem van de id-provider en alle downstreamsystemen bij, indien van toepassing.

Met name het CI/CD-systeem:

5. Maakt gebruik van de juiste systeem-API voor id-providers om een id-providergroep per rol te maken of bij te werken met precies de personen in het bestand (niet meer, niet minder).
6. Maakt gebruik van API's voor elk downstreamsysteem om dat systeemgroeperingsconcept te koppelen aan een providergroep voor elke rol (bijvoorbeeld: GitHub en Azure DevOps). Dit kan leiden tot een een-op-veel-relatie tussen uw team en het downstreamsysteem om een rol te vertegenwoordigen.
7. Optioneel maakt gebruik van API's voor elk downstreamsysteem om machtigingenlogica te implementeren die is gekoppeld aan het groeperingsmechanisme van het systeem.
8. Maakt gebruik van een API om een vergrendeld gegevensarchief bij te werken met de resultaten (inclusief het koppelen van de downstream systeemteam-id's) die vervolgens kunnen worden gebruikt voor een van uw intern gebouwde systemen. U kunt hier indien nodig ook koppelingen opslaan voor verschillende systeemweergaven van gebruikers-id's voor dezelfde id-providergebruiker/-account.

Als uw organisatie al gebruikmaakt van iets als Entra Rechtenbeheer, kunt u het beheer van groepslidmaatschap mogelijk weglaten van dit patroon.

Uw behoeften en beleid kunnen de details wijzigen, maar het algemene patroon kan worden aangepast aan een willekeurig aantal variaties. Alle geheimen die vereist zijn om te integreren met downstreamsystemen, worden bijgehouden in het CI/CD-systeem (bijvoorbeeld in GitHub Actions,Azure Pipelines) of in iets als Azure Key Vault.

Handmatige of extern geactiveerde, geparameteriseerde werkstromen gebruiken

Sommige problemen met betrekking tot selfservice die u identificeert, zijn mogelijk niet geschikt voor het gebruik van bestanden in Git. Of misschien hebt u een gebruikersinterface die u wilt gebruiken om de selfservice-ervaring te stimuleren.

Gelukkig hebben de meeste CI-systemen, waaronder GitHub Actions en Azure-pijplijnen, de mogelijkheid om een werkstroom in te stellen met invoer die u vervolgens handmatig kunt activeren via hun gebruikersinterfaces of CLIs. Gezien ontwikkelaars en gerelateerde bewerkingsrollen waarschijnlijk al bekend zijn met deze gebruikerservaringen, kunnen handmatige triggers het alles als codepatroon uitbreiden om automatisering mogelijk te maken voor activiteiten (of taken) die geen natuurlijke bestandsweergave hebben of die volledig moeten worden geautomatiseerd zonder een pull-aanvraagproces.

In feite kan uw CI-systeem u toestaan om deze werkstromen/pijplijnen te activeren vanuit uw eigen gebruikerservaringen via een API. Voor GitHub Actions is de rest-API van Actions de sleutel om een gebeurtenis voor het verzenden van een werkstroom te activeren om een werkstroomuitvoering te activeren. Azure DevOps-triggers zijn vergelijkbaar en u kunt ook de Azure DevOps Pipeline-API gebruiken voor uitvoeringen. Waarschijnlijk ziet u dezelfde mogelijkheden in andere producten. Of deze nu handmatig of via een API wordt geactiveerd, elke werkstroom kan een set invoer ondersteunen door een workflow_dispatch-configuratie toe te voegen aan het YAML-bestand van de werkstroom. Dit is bijvoorbeeld hoe portal-toolkits zoals Backstage.io communiceren met GitHub Actions.

Het werkstroom-/taaksysteem van uw CI/CD-systeem houdt ongetwijfeld activiteiten bij, rapporteert de status terug en bevat gedetailleerde logboeken die zowel ontwikkelaars als operationele teams kunnen gebruiken om te zien wat er mis is gegaan. Op deze manier heeft het enkele van dezelfde voordelen op het gebied van beveiliging, controle en zichtbaarheid als het alles als-codepatroon. Houd er echter rekening mee dat alle acties die door deze werkstromen/pijplijnen worden uitgevoerd, eruitzien als een systeemidentiteit (bijvoorbeeld service-principal of beheerde identiteit in Microsoft Entra ID) voor downstreamsystemen.

U hebt inzicht in wie aanvragen in uw CI/CD-systeem initieert, maar u moet beoordelen of dit voldoende informatie is en ervoor zorgen dat uw CI/CD-bewaarinstellingen voldoen aan uw controlevereisten voor gevallen waarin deze informatie essentieel is.

In andere gevallen hebben de hulpprogramma's waarmee u integreert mogelijk hun eigen traceringsmechanismen waarop u kunt vertrouwen. Deze CI/CD-hulpprogramma's hebben bijvoorbeeld bijna altijd verschillende meldingsmechanismen beschikbaar, zoals het gebruik van een Microsoft Teams - of Slack-kanaal , waarmee u iedereen die een aanvraag indient om statusupdates te ontvangen, kunt behouden. Het kanaal biedt een informeel overzicht van wat er is gebeurd. Dezelfde werkstroomengines zijn vaak al ontworpen om te integreren met operationele hulpprogramma's om het nut van deze patronen verder uit te breiden.

Kortom, u kunt enige automatisering implementeren met behulp van bestanden die zijn opgeslagen in een opslagplaats voor broncodebeheer dankzij de flexibiliteit van CI/CD-hulpprogramma's en hun out-of-box gebruikerservaringen.

Zie Een selfservicebasis voor ontwikkelaars ontwerpen als u wilt zien hoe interne ontwikkelplatforms deze aanpak als uitgangspunt kunnen gebruiken zonder dat dit ten koste gaat van meer geavanceerde mogelijkheden.

Het instellen van programmeeromgevingen voor ontwikkelaars automatiseren

Een ander veelvoorkomend probleem waarmee uw technische systemen kunnen helpen, is bootstrapping en normalisatie van ontwikkelaarscoderingsomgevingen. Hier volgen enkele veelvoorkomende problemen die u op dit gebied kunt horen:

• In sommige gevallen kan het weken duren voordat een ontwikkelaar zijn eerste pull-aanvraag heeft. Dit is een problematisch gebied wanneer u ontwikkelaars vrij vaak overdraagt tussen functieteams en projecten (bijvoorbeeld in matrixorganisaties), aannemers moet opvoeren of in een team zit dat zich in een wervingsfase bevindt.
• Inconsistentie tussen ontwikkelaars en uw CI-systemen kan leiden tot frequente problemen met 'het werkt op mijn computer', zelfs voor ervaren teamleden.
• Experimenten en het upgraden van frameworks, uitvoeringstijden en andere software kunnen ook bestaande ontwikkelomgevingen breken en leiden tot verloren tijd bij het achterhalen van precies wat er fout is gegaan.
• Voor ontwikkelaars-leads kunnen codebeoordelingen de ontwikkeling vertragen, omdat ze mogelijk een configuratiewijziging vereisen om ze te testen en ongedaan te maken zodra de beoordeling is voltooid.
• Teamleden en operators moeten ook tijd besteden aan het verbeteren van gerelateerde rollen naast ontwikkeling (operators, QA, bedrijven, sponsors) om te helpen testen, voortgang te bekijken, bedrijfsrollen te trainen en het werk dat het team doet te evangeliseren.

Deel van uw verharde paden

Als u deze problemen wilt oplossen, moet u nadenken over het instellen van specifieke hulpprogramma's en hulpprogramma's als onderdeel van uw goed gedefinieerde geplaveide paden. Het instellen van scripts voor ontwikkelaarscomputers kan helpen en u kunt dezelfde scripts opnieuw gebruiken in uw CI-omgeving. Overweeg echter om in containers geplaatste of gevirtualiseerde ontwikkelomgevingen te ondersteunen vanwege de voordelen die ze kunnen bieden. Deze coderingsomgevingen kunnen vooraf worden ingesteld volgens de specificaties van uw organisatie of project.

Vervangen van werkstations en gericht op Windows

Als u windows gebruikt of volledige werkstationvirtualisatie wilt uitvoeren (clienthulpprogramma's en instellingen voor hostbesturingssystemen naast projectspecifieke instellingen), bieden VM's meestal de beste functionaliteit. Deze omgevingen kunnen nuttig zijn voor alles van Windows-clientontwikkeling tot Windows-service of het beheren en onderhouden van webtoepassingen met een volledig framework voor .NET.

Aanpak	Voorbeelden
In de cloud gehoste VM's gebruiken	Microsoft Dev Box is een volledige windows-werkstationvirtualisatieoptie met ingebouwde integratie met desktopbeheersoftware.
Lokale VM's gebruiken	Hashicorp Vagrant is een goede optie en u kunt HashiCorp Packer gebruiken om VM-installatiekopieën te bouwen voor zowel het als Dev Box.

Werkruimtevirtualisatie en gericht op Linux

Als u linux gebruikt, kunt u een optie voor werkruimtevirtualisatie overwegen. Deze opties zijn minder gericht op het vervangen van uw ontwikkelaarswerkblad en meer op project- of toepassingsspecifieke werkruimten.

Aanpak	Voorbeelden
In de cloud gehoste containers gebruiken	GitHub Codespaces is een cloudomgeving voor Dev Containers die ondersteuning biedt voor integratie met VS Code, IntelliJ en terminalhulpprogramma's van JetBrains. Als deze of een vergelijkbare service niet aan uw behoeften voldoet, kunt u ondersteuning voor SSH of externe tunnels van VS Code gebruiken met Dev Containers op externe Linux-VM's. De optie op basis van een tunnel die niet alleen werkt met de client, maar ook met de webgebaseerde vscode.dev.
Lokale containers gebruiken	Als u de voorkeur geeft aan een lokale Dev Containers-optie in plaats van of naast een in de cloud gehoste optie, biedt Dev Containers solide ondersteuning in VS Code, ondersteuning in IntelliJ en andere hulpprogramma's en services.
In de cloud gehoste VM's gebruiken	Als u containers te beperkend vindt, kunt u met SSH-ondersteuning in hulpprogramma's zoals VS Code of JetBrains-hulpprogramma's zoals IntelliJ rechtstreeks verbinding maken met linux-VM's die u zelf beheert. VS Code heeft een optie op basis van een tunnel die hier ook werkt.
De Windows-subsysteem voor Linux gebruiken	Als uw ontwikkelaars uitsluitend Windows gebruiken, is Windows-subsysteem voor Linux (WSL) een uitstekende manier voor ontwikkelaars om linux lokaal te gebruiken. U kunt een WSL-distributie voor uw team exporteren en deze delen met alles wat is ingesteld. Voor een cloudoptie kunnen cloudwerkstationservices zoals Microsoft Dev Box ook gebruikmaken van WSL om linux-ontwikkeling te targeten.

Sjablonen voor het juiste begin maken met de juiste configuratie voor het behouden van de juiste configuratie

Het mooie van het codepatroon Alles als is dat ontwikkelaars hiermee op de geplaveide paden kunnen blijven die u vanaf het begin hebt ingesteld. Als dit een uitdaging voor uw organisatie is, kunnen toepassingssjablonen snel een essentiële manier worden om bouwstenen opnieuw te gebruiken om consistentie te stimuleren, standaardisatie te bevorderen en de best practices van uw organisatie te codificeren.

Om te beginnen kunt u iets eenvoudigs gebruiken als een GitHub-sjabloonopslagplaats, maar als uw organisatie een monorepo-patroon volgt, is dit mogelijk minder effectief. U kunt ook sjablonen maken waarmee u iets kunt instellen dat niet rechtstreeks is gerelateerd aan een toepassingsbronstructuur. In plaats daarvan kunt u een sjabloonengine zoals cookiecutter, Yeoman of iets zoals de Azure Developer CLI (azd) gebruiken die, naast het verleiden en vereenvoudigde CI/CD-installatie, ook een handige set opdrachten voor ontwikkelaars biedt. Omdat de Azure Developer CLI in alle scenario's kan worden gebruikt voor het instellen van de omgeving, kan deze worden geïntegreerd met Azure-implementatieomgevingen voor verbeterde beveiliging, geïntegreerde IaC, omgevingstracking, scheiding van problemen en vereenvoudigde cd-installatie.

Zodra u een set sjablonen hebt, kunnen ontwikkelaars leads deze opdrachtregelprogramma's of andere geïntegreerde gebruikerservaringen gebruiken om hun inhoud voor hun toepassingen te maken. Omdat ontwikkelaars mogelijk niet gemachtigd zijn om opslagplaatsen of andere inhoud van uw sjablonen te maken, is dit ook een andere mogelijkheid om handmatig geactiveerde, geparameteriseerde werkstromen/pijplijnen te gebruiken. U kunt invoer instellen en uw CI/CD-systeem namens hen alles laten maken, van een opslagplaats tot infrastructuur.

Rechts blijven en gelijk krijgen

Om te helpen schalen, moeten deze toepassingssjablonen waar mogelijk echter verwijzen naar gecentraliseerde bouwstenen (bijvoorbeeld IaC-sjablonen of zelfs CI/CD-werkstromen/pijplijnen). Het is zelfs mogelijk dat het behandelen van deze gecentraliseerde bouwstenen als hun eigen vorm van juiste sjablonen een effectieve strategie is om een aantal van de problemen die u hebt geïdentificeerd op te lossen.

Elk van deze afzonderlijke sjablonen kan niet alleen worden toegepast op nieuwe toepassingen, maar ook op bestaande toepassingen die u wilt bijwerken als onderdeel van een juiste campagne om bijgewerkte of verbeterde richtlijnen uit te rollen. Nog beter, deze centralisatie helpt u om zowel nieuwe als bestaande toepassingen correct te houden, zodat u uw best practices in de loop van de tijd kunt ontwikkelen of uitbreiden.

Sjablooninhoud

U wordt aangeraden rekening te houden met de volgende gebieden bij het maken van sjablonen.

Gebied	Details
Voldoende voorbeeldbroncode om app-patronen, SDK's en hulpprogrammagebruik aan te drijven	Voeg code en configuratie toe om ontwikkelaars te sturen naar aanbevolen talen, app-modellen en -services, API's, SDK's en architectuurpatronen. Zorg ervoor dat u code opneemt voor gedistribueerde tracering, logboekregistratie en waarneembaarheid met behulp van de hulpprogramma's van uw keuze.
Scripts bouwen en implementeren	Bied ontwikkelaars een algemene manier om een build en een lokale/sandbox-implementatie te activeren. Voeg in-IDE/editor de foutopsporingsconfiguratie toe voor de hulpprogramma's van uw keuze om deze te gebruiken. Dit is een belangrijke manier om onderhoudsproblemen te voorkomen en te voorkomen dat CI/CD niet synchroon is. Als uw sjabloonengine een mening heeft zoals de Azure Developer CLI, zijn er mogelijk al opdrachten die u gewoon kunt gebruiken.
Configuratie voor CI/CD	Werkstromen/pijplijnen bieden voor het bouwen en implementeren van toepassingen op basis van uw aanbevelingen. Profiteer van gecentraliseerde, herbruikbare of sjabloonwerkstromen /pijplijnen om ze up-to-date te houden. In feite kunnen deze herbruikbare werkstromen/pijplijnen zelf de juiste sjablonen zijn. Overweeg een optie om deze werkstromen handmatig te activeren.
Infrastructuur als codeassets	Geef aanbevolen IaC-configuraties op, inclusief verwijzingen naar centraal beheerde modules of catalogusitems , om ervoor te zorgen dat bij het instellen van de infrastructuur de aanbevolen procedures vanaf het get-go worden gevolgd. Deze verwijzingen kunnen teams ook helpen bij het behouden van de juiste tijd. In combinatie met werkstromen/pijplijnen kunt u ook IaC of EaC opnemen om zowat alles in te richten.
Beveiliging en beleid als codeassets	De DevSecOps-verplaatsing heeft ook de beveiligingsconfiguratie verplaatst naar code, wat ideaal is voor sjablonen. Sommige beleidsregels als codeartefacten kunnen ook worden toegepast op toepassingsniveau. Neem op als alles, van bestanden zoals CODEOWNERS tot scanconfiguraties zoals dependabot.yaml in GitHub Advanced Security. Bied geplande werkstromen/pijplijnuitvoeringen voor scans met iets als Defender voor Cloud , samen met omgevingstestuitvoeringen. Dit is met name belangrijk voor de beveiliging van de toeleveringsketen en zorg ervoor dat u naast toepassingspakketten en code ook rekening houdt met containerinstallatiekopieën . Met deze stappen kunnen ontwikkelteams op het juiste moment blijven werken.
Waarneembaarheid, bewaking en logboekregistratie	Een onderdeel van het inschakelen van selfservice is het bieden van eenvoudig inzicht in toepassingen zodra deze zijn geïmplementeerd. Naast de runtime-infrastructuur moet u ook instellingen opnemen voor waarneembaarheid en bewaking. In de meeste gevallen moet er een IaC-aspect worden ingesteld (bijvoorbeeld agentimplementatie, instrumentatie), terwijl het in andere gevallen een ander type configuratie-als-codeartefact kan zijn (bijvoorbeeld bewakingsdashboards voor Azure-toepassing Insights). Ten slotte moet u codevoorbeeldcode opnemen voor gedistribueerde tracering, logboekregistratie en waarneembaarheid met behulp van de hulpprogramma's van uw keuze.
Instellen van coderingsomgeving	Inclusief configuratiebestanden voor het coderen van linters, formatters, editors en IDE's. Neem installatiescripts op samen met werkruimte- of werkstationvirtualisatiebestanden zoals devcontainer.json, devbox.yaml, dockerfiles voor ontwikkelaars, Docker Compose-bestanden of Vagrantfiles.
Configuratie testen	Bied configuratiebestanden voor zowel eenheidstests als uitgebreidere tests met behulp van uw favoriete services, zoals Microsoft Playwright Testing voor gebruikersinterface of Azure Load Testing.
Hulpprogramma voor samenwerking instellen	Als uw systeem voor probleembeheer en broncodebeheer taak-/probleem-/PR-sjablonen als code ondersteunt, moet u deze ook opnemen. In gevallen waarin meer installatie is vereist, kunt u desgewenst een werkstroom/pijplijn opgeven waarmee uw systemen worden bijgewerkt met behulp van een beschikbare CLI of API. Hiermee kunt u ook andere samenwerkingshulpprogramma's instellen, zoals Microsoft Teams of Slack.

Uw toepassingsplatform verfijnen