Azure-pipelines CI/CD-basislijnarchitectuur

Dit artikel bevat een basislijnarchitectuur voor het bouwen van een CI/CD-pijplijn (continue integratie en continue implementatie) met Azure-pipelines. Gebruik deze architectuur als uitgangspunt als u het bouwen, testen en implementeren van toepassingen in faserings- en productieomgevingen in Azure wilt automatiseren. De architectuur definieert drie pijplijnen, pull-aanvraag (PR), continue integratie (CI) en continue implementatie (CD) en laat zien hoe ze samenwerken met Azure-opslagplaatsen, Azure Key Vault en Azure Monitor om uw apps veilig te valideren, bouwen en implementeren.

Architectuur

Download een Visio-bestand van deze architectuur.

Notitie

Hoewel dit artikel betrekking heeft op CI/CD voor wijzigingen in toepassingen, kunnen Azure-pipelines ook worden gebruikt om CI/CD-pijplijnen te bouwen voor wijzigingen in infrastructuur als code (IaC).

Gegevensstroom

De gegevens stromen als volgt door het scenario:

PR-pijplijn - Een pull-aanvraag (PR) naar Azure-opslagplaatsen Git triggert een PR-pijplijn. Deze pijplijn voert snelle kwaliteitscontroles uit. Deze controles moeten het volgende omvatten:
- Het bouwen van de code, waarvoor afhankelijkheden uit een afhankelijkheidsbeheersysteem moeten worden opgehaald.
- Het gebruik van hulpprogramma's voor het analyseren van de code, zoals statische codeanalyse, linting en beveiligingsscans
- Eenheidstests
Als een van de controles mislukt, eindigt de pijplijnuitvoering en moet de ontwikkelaar de vereiste wijzigingen aanbrengen. Als alle tests slagen, moet de pijplijn een pull request beoordeling nodig hebben. Als de pull-aanvraagbeoordeling mislukt, eindigt het pijplijnproces en zal de ontwikkelaar de nodige wijzigingen moeten doorvoeren. Als alle controles en PR-beoordelingen zijn geslaagd, wordt de PR succesvol samengevoegd.
CI-pijplijn - Een samenvoeging naar Azure-opslagplaatsen Git activeert een CI-pijplijn. Deze pijplijn voert dezelfde controles uit als de PR-pijplijn, aangevuld met integratietests. De CI-pijplijn voert integratietests uit in plaats van de PR-pijplijn om twee redenen:
- Integratietests kunnen resource-intensief zijn, dus het uitvoeren ervan na een samenvoeging zorgt voor een balans tussen de ontwikkelsnelheid en foutdetectie.
- Het slagen voor tests in een PR garandeert niet dat ze na het samenvoegen nog steeds slagen, omdat wijzigingen in de main-branch nieuwe problemen kunnen introduceren die alleen door tests na het samenvoegen worden ontdekt.
Voor deze integratietests is het niet nodig om de oplossing te implementeren, omdat de buildartefacten nog niet zijn gemaakt. Als voor een test geheimen zijn vereist, haalt de pijplijn deze op uit Azure Key Vault. Als er een controle mislukt, eindigt de pijplijn en moet de ontwikkelaar de vereiste wijzigingen aanbrengen. Een succesvolle uitvoering van deze pijplijn genereert en publiceert de buildartefacten.
CD-pijplijntrigger: het publiceren van artefacten activeert de CD-pijplijn.
CD-release naar staging: de CD-pijplijn downloadt de build-artifacten die zijn gemaakt in de CI-pijplijn en implementeert de oplossing in een testomgeving. De pijplijn voert vervolgens acceptatietests uit voor de faseringsomgeving om de implementatie te valideren. Als een acceptatietest mislukt, eindigt de pijplijn en moet de ontwikkelaar de vereiste wijzigingen aanbrengen. Als de tests slagen, kan een handmatige validatietaak worden geïmplementeerd om een persoon of groep te vereisen om de implementatie te valideren en de pijplijn te hervatten.
CD-release naar productie: als de handmatige interventie wordt voortgezet of als er geen handmatige interventie is ingevoerd, wordt de oplossing door de pijplijn naar de productie gebracht. De pijplijn moet rooktesten uitvoeren in productie om te bevestigen dat de release naar verwachting werkt. Als een handmatige interventiestap resulteert in een annulering, mislukt de release of de betrouwbaarheidstests mislukken, wordt de release teruggedraaid, wordt de pijplijn beëindigd en moet de ontwikkelaar de vereiste wijzigingen aanbrengen.
Bewaking : Azure Monitor verzamelt waarneembaarheidsgegevens, zoals logboeken en metrische gegevens, zodat een operator status-, prestatie- en gebruiksgegevens kan analyseren. Application Insights verzamelt alle toepassingsspecifieke bewakingsgegevens, zoals traceringen. Azure Log Analytics wordt gebruikt om al die gegevens op te slaan.

Onderdelen

Een Azure-opslagplaatsen Git-opslagplaats fungeert als een codeopslagplaats die versiebeheer en een platform voor samenwerkingsprojecten biedt.
Azure-pipelines biedt een manier om toepassings- en infrastructuurcode te bouwen, testen, verpakken en vrijgeven. In dit voorbeeld zijn drie afzonderlijke pijplijnen met de volgende verantwoordelijkheden:
- PR-pijplijnen valideren code voordat een pull-aanvraag kan worden samengevoegd via linting, bouwen en eenheidstests.
- CI-pipelines draaien nadat de code is samengevoegd. Ze voeren dezelfde validatie uit als PR-pijplijnen, maar voegen integratietesten toe en publiceren build-artefacten als alles slaagt.
- CD-pijplijnen implementeren buildartefacten, voer acceptatietests uit en release naar productie.
Azure-artefacten feeds kunt u softwarepakketten beheren en delen, zoals Maven, npm en NuGet. Met feeds kunt u de levenscyclus van uw pakketten beheren, waaronder versiebeheer, promotie en buiten gebruik stellen van pakketten, zodat uw team de nieuwste en veiligste versies van uw afhankelijkheden gebruikt.
Key Vault- biedt een manier om beveiligde gegevens voor uw oplossing te beheren, waaronder geheimen, versleutelingssleutels en certificaten. In deze architectuur wordt het gebruikt om toepassingsgeheimen op te slaan. Deze geheimen worden geopend via de pijplijn. Geheimen kunnen worden geopend door Azure-pipelines met een Key Vault-taak of door geheimen te koppelen vanuit Key Vault.
Monitor is een waarneembaarheidsresource waarmee metrische gegevens en logboeken, toepassingstelemetriegegevens en metrische platformgegevens voor de Azure-services worden verzameld en opgeslagen. Gebruik deze gegevens om de toepassing te bewaken, waarschuwingen, dashboards in te stellen en hoofdoorzaakanalyse van fouten uit te voeren.
Application Insights is een bewakingsservice die realtime inzicht biedt in de prestaties en het gebruik van uw webtoepassingen.
Log Analytics-werkruimte een centrale locatie biedt waar u gegevens uit meerdere bronnen kunt opslaan, opvragen en analyseren, waaronder Azure-resources, toepassingen en services.

Alternatieven

Hoewel dit artikel zich richt op Azure-pipelines, kunt u deze alternatieven overwegen:

Azure DevOps Server kan worden gebruikt als een lokale alternatief.
Jenkins- is een opensource-hulpprogramma dat wordt gebruikt voor het automatiseren van builds en implementaties.
GitHub Actions kunt u uw CI/CD-werkstromen rechtstreeks vanuit GitHub automatiseren.
GitHub-opslagplaatsen kunnen worden vervangen door de codeopslagplaats. Azure-pipelines kan naadloos worden geïntegreerd met GitHub-opslagplaatsen.

Dit artikel is gericht op algemene CI/CD-procedures met Azure-pipelines. Hier volgen enkele rekenomgevingen waarvoor u kunt overwegen om te implementeren:

App Service- is een HTTP-service voor het hosten van webtoepassingen, REST API's en mobiele back-ends. U kunt zich in uw favoriete taal ontwikkelen en toepassingen eenvoudig uitvoeren en schalen in zowel Windows- als Linux-omgevingen. App Service ondersteunt implementatiesites zoals fasering en productie, zodat u een toepassing kunt implementeren in een staging-site en deze kunt vrijgeven aan de productiesite.
Azure Virtuele Machines werkbelastingen verwerkt waarvoor een hoge mate van controle is vereist, of die afhankelijk zijn van onderdelen en services van het besturingssysteem die niet mogelijk zijn met App Service.
Azure Power Platform is een verzameling cloudservices waarmee gebruikers toepassingen kunnen bouwen, implementeren en beheren zonder dat hiervoor infrastructuur of technische expertise nodig is.
Azure Functions is een serverloos rekenplatform dat u kunt gebruiken om toepassingen te bouwen. Met Functions kunt u triggers en bindingen gebruiken om services te integreren. Functies ondersteunen ook implementatieslots zoals staging en productie. U kunt een toepassing implementeren in een staging-site en deze vrijgeven aan de productiesite.
AKS - (Azure Kubernetes Service) is een beheerd Kubernetes-cluster in Azure. Kubernetes is een opensource-containerindelingsplatform.
Azure Container Apps kunt u toepassingen in containers uitvoeren op een serverloos platform.

Scenario-details

Het gebruik van bewezen CI- en CD-procedures voor het implementeren van wijzigingen in toepassingen of infrastructuur biedt verschillende voordelen, waaronder:

kortere releasecycli - Geautomatiseerde CI/CD-processen stellen u in staat om sneller te implementeren dan met handmatige procedures. Veel organisaties implementeren meerdere keren per dag.
Betere codekwaliteit : kwaliteitspoorten in CI-pijplijnen, zoals linting en eenheidstests, resulteren in code van hogere kwaliteit.
Verminderd risico van vrijgeven : de juiste CI/CD-procedures verlagen het risico op het vrijgeven van nieuwe functies aanzienlijk, omdat de implementatie kan worden getest vóór de release.
Verhoogde productiviteit : met geautomatiseerde CI/CD kunnen ontwikkelaars niet meer werken aan handmatige integraties en implementaties, zodat ze zich kunnen richten op nieuwe functies.
Terugdraaibewerkingen inschakelen: hoewel de juiste CI/CD-procedures het aantal bugs of regressies verlagen dat wordt uitgebracht, vinden ze nog steeds plaats. CI/CD kan geautomatiseerde terugdraaiacties naar eerdere releases inschakelen.

Mogelijke gebruiksvoorbeelden

Overweeg Azure-pipelines- en CI/CD-processen voor:

De ontwikkelings- en implementatielevenscycli van toepassingen versnellen.
Kwaliteit en consistentie bouwen in een geautomatiseerd build- en releaseproces.
De stabiliteit en uptime van toepassingen vergroten.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die u kunt gebruiken om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Frameworkvoor meer informatie.

Operationele uitmuntendheid

Overweeg om IaC- (Infrastructure as Code) te implementeren om uw infrastructuur te definiëren en te implementeren in uw pijplijnen.
Gebruik releasevariabelen in uw releasedefinities om configuratiewijzigingen van uw omgevingen aan te sturen. Releasevariabelen kunnen worden beperkt tot een volledige release of een bepaalde omgeving. Wanneer u variabelen gebruikt voor geheime informatie, moet u ervoor zorgen dat u het hangslotpictogram selecteert.
Overweeg zelf-gehoste agents te gebruiken als u implementeert naar resources die in een beveiligd virtueel netwerk worden uitgevoerd, of als u een groot aantal builds uitvoert. Zelf-hostende agents kunnen u helpen bij het versnellen van builds op een kostenefficiënte manier op schaal.
Overweeg het gebruik van Application Insights en andere bewakingshulpprogramma's zo vroeg mogelijk in uw release-pijplijn. Veel organisaties beginnen alleen te bewaken in hun productieomgeving. Door uw andere omgevingen te bewaken, kunt u fouten eerder in het ontwikkelproces identificeren en problemen in uw productieomgeving voorkomen.
Overweeg het gebruik van afzonderlijke bewakingsbronnen voor productie.
Overweeg het gebruik van YAML-pijplijnen in plaats van de klassieke interface. YAML-pijplijnen kunnen worden behandeld als andere code. YAML-pijplijnen kunnen bijvoorbeeld worden ingecheckt bij broncodebeheer en versiebeheer.
Overweeg het gebruik van YAML-sjablonen om hergebruik te bevorderen en pijplijnen te vereenvoudigen. Pr- en CI-pijplijnen zijn bijvoorbeeld vergelijkbaar. Er kan één geparameteriseerde sjabloon worden gebruikt voor beide pijplijnen.
Overweeg omgevingen te maken buiten fasering en productie om activiteiten te ondersteunen, zoals handmatig testen van gebruikersacceptatie, prestaties en belastingstests en terugdraaiacties.

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatievoor meer informatie.

Azure DevOps-kosten zijn afhankelijk van het aantal gebruikers in uw organisatie dat toegang nodig heeft, samen met andere factoren, zoals het aantal gelijktijdige build-/releases dat vereist is en het aantal testgebruikers. Zie Prijzen voor Azure DevOpsvoor meer informatie.

Deze prijscalculator biedt een schatting voor het uitvoeren van Azure DevOps met 20 gebruikers.

Azure DevOps wordt gefactureerd per gebruiker per maand. Er kunnen meer kosten in rekening worden gebracht, afhankelijk van de benodigde gelijktijdige pijplijnen, naast eventuele extra testgebruikers of basislicenties van gebruikers.

Veiligheid

Houd rekening met de beveiligingsvoordelen van het gebruik van door Microsoft gehoste agents bij het kiezen of u door Microsoft gehoste of zelf-hostende agents wilt gebruiken.
Zorg ervoor dat alle wijzigingen in omgevingen worden uitgevoerd via pijplijnen. Implementeer op rollen gebaseerd toegangsbeheer (RBAC) op basis van het principe van minimale bevoegdheden, waardoor gebruikers geen toegang hebben tot omgevingen.
Overweeg stappen in Azure-pipelines te integreren om afhankelijkheden bij te houden, licenties te beheren, beveiligingsproblemen te scannen en afhankelijkheden up-to-date te houden.

Volgende stappen

Uw eerste pijplijn bouwen, testen en implementeren .NET Core-projecten bouwen en implementeren een Node.js-web-app

Feedback

Is deze pagina nuttig?

Last updated on 2026-09-18