Een release-pijplijn plannen met behulp van Azure Pipelines
In deze sectie volgt u Andy en Mara als ze een eenvoudige CD-pijplijn plannen die wordt uitgevoerd in Azure Pipelines.
Wanneer het klaar is, demo's ze het naar de rest van het team. De pijplijn fungeert als een POC die ze verbeteren en uitbreiden naarmate ze meer leren en feedback krijgen van Tim en Amita.
Wat zijn de onderdelen van een eenvoudige CD-pijplijn?
Een eenvoudige CD-pijplijn bevat een trigger voor het proces en ten minste één fase of implementatiefase. Een fase bestaat uit banen. Een taak is een reeks stappen waarmee wordt gedefinieerd hoe u uw toepassing bouwt, test of implementeert.
Andy: We hebben het 
build-artefact al. Het is het ZIP-bestand dat door onze bestaande build-pijplijn wordt gemaakt. Maar hoe implementeren we deze in een 
liveomgeving?
Wat is een pijplijnfase?
Een fase maakt deel uit van de pijplijn die onafhankelijk kan worden uitgevoerd en kan worden geactiveerd door verschillende mechanismen. Een mechanisme kan het succes zijn van de vorige fase, een planning of zelfs een handmatige trigger. In de volgende module leert u meer over deze mechanismen.
Mara: We kunnen een fase hebben die de app bouwt en een andere fase die tests uitvoert.
Mara: We hebben de taken voor de buildfase al gedefinieerd in onze pijplijn. Onze implementatiefase kan vergelijkbaar zijn, inclusief taken die de build implementeren in een omgeving.
De vraag is, waar moeten we het artefact implementeren?
Wat is een omgeving?
U hebt waarschijnlijk de term omgeving gebruikt om te verwijzen naar waar uw toepassing of service wordt uitgevoerd. Uw productieomgeving kan bijvoorbeeld de locatie zijn waar uw eindgebruikers toegang hebben tot uw toepassing.
In dit voorbeeld is uw productieomgeving mogelijk:
- Een fysieke machine of virtuele machine (VM).
- Een containeromgeving, zoals Kubernetes.
- Een beheerde service, zoals Azure-app Service.
- Een serverloze omgeving, zoals Azure Functions.
Een artefact wordt geïmplementeerd in een omgeving. Met Azure Pipelines kunt u eenvoudig implementeren in vrijwel elk soort omgeving, ongeacht of deze on-premises of in de cloud is.
In Azure Pipelines heeft de term omgeving een tweede betekenis. Hier is een omgeving een abstracte weergave van uw implementatieomgeving, zoals een Kubernetes-cluster, een App Service-exemplaar of een virtuele machine.
Een Azure Pipelines-omgeving registreert de implementatiegeschiedenis om u te helpen de bron van wijzigingen te identificeren. Met behulp van Azure Pipelines-omgevingen kunt u ook beveiligingscontroles en manieren definiëren om te bepalen hoe een artefact wordt gepromoveerd van de ene fase van een pijplijn naar een andere. Wat een omgeving bevat, is afhankelijk van wat u met het artefact wilt doen. Een omgeving waarin u het artefact wilt testen, wordt waarschijnlijk anders gedefinieerd dan een omgeving waarin u het artefact voor uw eindgebruikers wilt implementeren.
Een manier om een Azure Pipelines-omgeving te definiëren, is met een YAML-bestand. Uw YAML-bestand bevat een environment sectie, die de Azure Pipelines-omgeving aangeeft, waar u uw artefact gaat implementeren.
Wanneer u uw release-pijplijn plant, moet u bepalen waar uw toepassing of service wordt uitgevoerd. Laten we eens kijken wat Andy en Mara beslissen.
Andy: Op hoog niveau, welk type omgeving willen we? Willen we on-premises of in de cloud implementeren?
Mara: We kunnen Tim vragen om een virtuele machine voor ons te maken in het lab, maar hij heeft altijd geen hardware meer. Het is snel en eenvoudig om zelf een POC in te stellen als we de cloud gebruiken.
Andy: Ik ben het ermee eens, maar er zijn zoveel cloudopties om rekening mee te houden en we kunnen Azure Pipelines gebruiken om ze te implementeren. Wat moeten we proberen?
Mara: De teams die onze games ontwikkelen, gebruiken Azure om een aantal van hun back-endsystemen te hosten. Ze stellen het snel in en lijken het leuk te vinden. Ik denk dat we ons moeten houden aan Azure voor onze cloud.
Andy: Ok, dat is logisch! Maar Azure biedt zoveel rekenopties. Welke moeten we kiezen?
Andy vermeldt deze opties op het whiteboard:
- Virtuele machines
- Containers
- Azure App Service
- Computerbewerkingen zonder servers
Notitie
U vindt meer informatie over elk van deze rekenopties aan het einde van deze module.
Mara: Ik weet dat containers en serverloze computing momenteel populair zijn. Vergeleken met VM's zijn ze beide lichtgewicht in termen van resources. Ze zijn ook eenvoudig te vervangen en uit te schalen. Beide zijn interessant, maar ik ben nerveus over het leren van twee nieuwe technologieën tegelijk. Ik wil me liever concentreren op het bouwen van de pijplijn.
Andy: Ik ben bij jou. Hierdoor blijven VM's of App Service. Ik denk dat VM's een betere keuze zijn als we een Line-Of-Business-app ( een app die volledige toegang tot een bepaalde omgeving vereist) naar de cloud verplaatst. We doen niets zo belangrijk.
Mara: Dat verlaat App Service, wat mijn keuze zou zijn. Het is ontworpen om te werken met Azure DevOps en biedt voordelen. Het is een PaaS-omgeving (Platform as a Service) voor web-apps, dus het kost ons veel last. We hoeven ons geen zorgen te maken over infrastructuur. Het wordt ook geleverd met beveiligingsfuncties en stelt ons in staat om taakverdeling en automatisch schalen uit te voeren.
Andy: App Service klinkt als wat we nodig hebben. We gaan App Service gebruiken. We maken toch maar een proof of concept. We kunnen de rekenoptie altijd wijzigen als we later iets anders willen proberen.
Hoe voert Azure Pipelines implementatiestappen uit?
Als u uw toepassing wilt implementeren, moet Azure Pipelines eerst worden geverifieerd met de doelomgeving. Azure Pipelines biedt verschillende verificatiemechanismen. De omgeving die u gebruikt, is afhankelijk van de doelomgeving waarnaar u implementeert. Aan het einde van deze module vindt u meer informatie over deze mechanismen.
Andy: We hebben ons build-artefact en we weten dat we in fasen van de pijplijn gaan bouwen en implementeren. We hebben ook de doelomgeving voor onze implementatie gedefinieerd. Dat is App Service. Mijn vraag is nu, hoe verifieert Azure Pipelines met App Service? Ik weet dat dit een van Tim's zorgen zal zijn. We moeten ervoor zorgen dat het proces veilig is.
Na wat onderzoek komen Andy en Mara aan de slag met de algemene stappen waarmee Azure Pipelines kan worden geïmplementeerd in App Service:
- Geef de doelimplementatieomgeving op in de pijplijnconfiguratie.
- Een manier bieden voor Azure Pipelines om toegang tot die omgeving te verifiëren.
- Gebruik Azure Pipelines-taken om het build-artefact in die omgeving te implementeren.
Mara: Volgens ons onderzoek moeten we een serviceverbinding maken om de doelomgeving op te geven en toegang tot deze omgeving te verifiëren. Nadat we de serviceverbinding hebben gedefinieerd, is deze beschikbaar voor al onze taken die kunnen worden gebruikt. Vervolgens moeten we de ingebouwde taken DownloadPipelineArtifact gebruiken om het build-artefact te downloaden naar de pijplijnagent en AzureWebApp om onze toepassing te implementeren in Azure-app Service.
Wat zijn jobs en strategieën?
Uw bestaande build-pijplijn definieert een buildagent, pijplijnvariabelen en de taken die nodig zijn om uw software te bouwen.
Het implementatiegedeelte van uw pijplijn bevat dezelfde elementen. Uw implementatieconfiguratie definieert doorgaans ook een of meer taken, een pijplijnomgeving en strategieën. U hebt eerder geleerd over pijplijnomgevingen.
Hier volgt een voorbeeldconfiguratie die u later in deze module gaat uitvoeren. Met deze configuratie wordt de Space Game-website geïmplementeerd in Azure-app Service.
- stage: 'DeployDev'
displayName: 'Deploy to dev environment'
dependsOn: Build
jobs:
- deployment: Deploy
pool:
vmImage: 'ubuntu-20.04'
environment: dev
variables:
- group: 'Release Pipeline'
strategy:
runOnce:
deploy:
steps:
- download: current
artifact: drop
- task: AzureWebApp@1
displayName: 'Azure App Service Deploy: website'
inputs:
azureSubscription: 'Resource Manager - Tailspin - Space Game'
appName: '$(WebAppName)'
package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'
Taken
Een taak is een reeks stappen (of taken) die sequentieel worden uitgevoerd als een eenheid. Elke pijplijnfase heeft standaard één taak, zelfs als die fase het trefwoord niet gebruikt job .
Een taak kan worden uitgevoerd in een agentgroep, in een container of rechtstreeks op de Azure DevOps-server. De voorbeeldtaak die hier wordt weergegeven, wordt uitgevoerd op een Door Microsoft gehoste Ubuntu-agent.
U kunt de voorwaarden opgeven waaronder elke taak wordt uitgevoerd. In de voorbeeldtaak die hier wordt weergegeven, worden geen voorwaarden gedefinieerd. Een taak wordt standaard uitgevoerd als deze niet afhankelijk is van een andere taak of als alle taken waarvan deze wel afhankelijk is, succesvol zijn voltooid.
U kunt taken ook parallel of opeenvolgend uitvoeren. Met behulp van uw bestaande build-pijplijn als voorbeeld kunt u parallelle taken gebruiken om uw software op Windows-, Linux- en macOS-agents tegelijkertijd te bouwen.
Een implementatietaak is een speciaal type taak dat een belangrijke rol speelt in uw implementatiefasen. Implementatietaken registreren de status van uw implementaties in Azure Pipelines, zodat u een audittrail krijgt. Implementatietaken helpen u ook bij het definiëren van uw implementatiestrategie. Dit doen we binnenkort.
Strategieën
Een strategie definieert hoe uw toepassing wordt geïmplementeerd. In een toekomstige module leert u meer over strategieën zoals blauw-groen en kanarie. Voorlopig gebruikt u de runOnce-strategie om het Space Game-pakket uit de pijplijn te downloaden en te implementeren in Azure-app Service.
Hoe maakt Azure Pipelines verbinding met Azure?
Als u uw app wilt implementeren in een Azure-resource, zoals een virtuele machine of App Service, hebt u een serviceverbinding nodig. Een serviceverbinding biedt beveiligde toegang tot uw Azure-abonnement met behulp van een van de twee methoden:
- Verificatie van service-principal
- Beheerde identiteiten voor Azure-resources
Aan het einde van deze module vindt u meer informatie over deze beveiligingsmodellen, maar kortom:
- Een service-principal is een identiteit met een beperkte rol die toegang heeft tot Azure-resources. U kunt een service-principal beschouwen als een serviceaccount dat namens u geautomatiseerde taken kan uitvoeren.
- Beheerde identiteiten voor Azure-resources zijn een functie van Microsoft Entra ID die het werken met service-principals vereenvoudigt. Omdat er beheerde identiteiten bestaan in de Microsoft Entra-tenant, kan de Azure-infrastructuur de service automatisch verifiëren en het account voor u beheren.
Beheerde identiteiten vereenvoudigen het werken met service-principals; Maar in deze module gebruiken we verificatie van de service-principal omdat een serviceverbinding automatisch uw Azure-resources kan detecteren en de juiste service-principalrollen voor u kan toewijzen.
Het plan
Andy en Mara zijn klaar om te beginnen. Ze gaan het volgende doen:
- Bouw voort op de bestaande buildconfiguratie van Azure Pipelines.
- Definieer een buildfase waarmee het artefact wordt gemaakt.
- Definieer een implementatiefase waarmee het artefact wordt geïmplementeerd in App Service.
Andy: Is deze tekening juist? We gebruiken Azure Pipelines om te implementeren in Azure-app Service. Hiervoor nemen we het buildartefact 
als invoer voor de implementatiefase 
. De taken in de implementatiefase downloaden het artefact 
en gebruiken een serviceverbinding om het artefact te implementeren in App Service 
.
Mara: Dat gaat over het optellen. Laten we aan de slag gaan.