Azure DevOps YAML-pijpleidingen bieden een rigoureuze, versiegestuurde aanpak van continue integratie en continue levering (CI/CD) die perfect aansluit bij de moderne softwareleveringspraktijken. Door de gehele pijpleidingdefinitie in YAML-bestanden die naast de toepassingscode zijn opgeslagen, bereiken teams transparantie, herhaalbaarheid en hoorbaarheid die grafische redacteuren niet kunnen overeenkomen. Deze aanpak transformeert de pijpleiding van een zwarte doos in een eersteklas burger van de codebase, onder voorbehoud van dezelfde beoordeling, tracking en geschiedenistracking als de broncode zelf.

Of u nu bouwt voor een microservice architectuur, het implementeren van infrastructuur als code, of orkestreren complexe multi-environment release workflows, Azure DevOps YAML pijpleidingen geven u de controle, flexibiliteit en schaalbaarheid die nodig zijn om software betrouwbaar te verzenden. Dit artikel biedt een diepgaande blik op wat YAML pijpleidingen zijn, hoe ze te creëren, geavanceerde patronen, en bewezen beste praktijken die uit productie-omgevingen.

Wat zijn Azure DevOps YAML Pijpleidingen?

Azure DevOps YAML-pijpleidingen zijn declaratieve configuratiebestanden die de stappen, stadia, banen en afhankelijkheden die nodig zijn om toepassingen te bouwen, testen en implementeren definiëren. In tegenstelling tot de klassieke editor die pijplijndefinities opslaat in de Azure DevOps-servicedatabase, bestaan YAML-pijpleidingen als tekstbestanden in uw repository . . . . . . . . of geplaatst onder een directory. Dit bestand bevat de volledige pijplijndefinitie met behulp van een gestructureerd formaat dat Azure DevOps ontleedt op runtime.

Het pipeline bestand kan andere YAML bestanden (templates) verwijzen naar herbruikbare logica, voorwaardelijke verklaringen, dynamische variabelen bevatten en zelfs verschillende gedragingen op basis van branch-, tag- of padfilters veroorzaken. Dit maakt het CI/CD-proces volledig scripteerbaar en in staat om complexe real-world scenario's zonder handmatige interventie te verwerken.

Kerncomponenten van YAML Pijpleidingen

Een YAML-pijpleiding bestaat uit verschillende hiërarchische elementen die samenwerken: [triggers, variabelen, fases, jobs, ]stappen[] en templates[]. Het begrijpen van deze bouwstenen is essentieel voor het schrijven van onderhoudende en efficiënte pijpleidingen.

Stages, banen en stappen

Stages vertegenwoordigen belangrijke afdelingen in de pijplijn, zoals Build, Test, en Deploy. Ze kunnen sequelly of parallel lopen. Binnen elke fase, jobs] definiëren de uitvoeringsomgeving (agent pool of container) en bevatten een reeks stappen[. Stappen zijn de kleinste eenheid van werk .. een script uit te voeren, een taak uit te voeren, of een template om in op te nemen. Azure DevOps biedt honderden ingebouwde taken voor gemeenschappelijke operaties zoals het installeren van afhankelijkheden, het uitvoeren van tests, of het publiceren van artefacten.

Drempels

Triggers bepalen wanneer de pijpleiding automatisch moet starten. De meest voorkomende is de CI-trigger, die zich inzet voor bepaalde branches (bv. , ). U kunt ook PR-triggers gebruiken voor pull verzoekvalidatie, schema-triggers voor nachtelijke builds en padfilters om het activeren van wijzigingen in specifieke mappen te beperken. Geavanceerde triggerconfiguraties stellen u in staat om wildcards te gebruiken, paden uit te sluiten of voorwaardelijk te draaien op basis van tags.

trigger:
 branches:
 include:
 - main
 - releases/*
 paths:
 exclude:
 - docs/*
 - README.md

Variabelen en parameters

Variabelen slaan waarden op die gedurende de gehele pijpleiding gebruikt kunnen worden . .connectie strings, versienummers of omgevingsnamen. Ze kunnen gedefinieerd worden op het niveau van de pijpleiding, het stadium of het werkniveau, en kunnen worden overschreven tijdens de wachtrij. De parameters zijn een krachtiger mechanisme voor het invoeren van runtime keuzes (bv. welke omgeving om naar uit te zetten) en zijn vooral nuttig in sjablonen. Parameters ondersteunen standaardwaarden, typebeperkingen en voorwaardelijke logica.

Azure DevOps ondersteunt ook geheime variabelen, die worden gecodeerd en nooit in logs worden blootgesteld. Voor productie-kwaliteit geheimen, integreren met Azure Key Vault met behulp van de "Azure Key Vault" taak of de variabele groep referentie.

Sjablonen voor herbruikbaarheid

Sjablonen zijn een van de meest krachtige kenmerken van YAML-pijpleidingen. Ze laten je toe om de gemeenschappelijke logica uit te rekenen in afzonderlijke YAML-bestanden en ze in meerdere pijpleidingen op te nemen. Er zijn twee soorten: jobsjablonen en ]stepsjablonen. Jobsjablonen inkapselen een hele taak (inclusief pool, variabelen en stappen), terwijl stapsjablonen een groep van stappen hergebruiken in banen of stadia.

Sjablonen ondersteunen parameters, waardoor ze flexibel zijn. Bijvoorbeeld, kunt u een "build-node-app.yml" template maken die een Node.js versie als parameter neemt en npm install, build en test. Elke pijpleiding die een Node.js app nodig heeft kan die sjabloon eenvoudig met de juiste versie opnemen. Dit elimineert duplicatie en zorgt voor consistentie tussen projecten.

# templates/build-node-app.yml
parameters:
- name: nodeVersion
 type: string
 default: '18.x'

steps:
- task: NodeTool@0
 inputs:
 versionSpec: ${{ parameters.nodeVersion }}
- script: npm install
 displayName: 'Install dependencies'
- script: npm run build
 displayName: 'Build application'
- script: npm test
 displayName: 'Run tests'

Belangrijkste voordelen van door versie gecontroleerde CI/CD

De goedkeuring van YAML-pijpleidingen biedt verschillende concrete voordelen ten opzichte van klassieke, op de UI gebaseerde pijpleidingen:

  • Volledige versiebesturing: Elke verandering in de pijpleiding wordt gevolgd in dezelfde repository als de toepassingscode. U kunt pijpleidingwijzigingen diffen, commentaar geven en terugrollen met standaard Git-workflows. Dit elimineert het mysterie "wie de pijpleiding heeft veranderd" en zorgt ervoor dat de pijpleidingdefinitie altijd in sync staat met de code die het opbouwt.
  • Reproduceerbaarheid en auditeerbaarheid: Omdat de pijpleiding wordt gedefinieerd als code, kunt u elke commit opnieuw opbouwen met precies dezelfde stappen, variabelen en afhankelijkheden als toen het voor het eerst werd gebouwd. Dit is van cruciaal belang voor het debuggen van productieproblemen en voldoen aan de nalevingseisen.
  • Automatie verder dan bouwt: YAML-pijpleidingen ondersteunen voorwaardelijke logica, loops en complexe expressies met behulp van de expressietaal van Azure DevOps. U kunt geavanceerde workflows implementeren zoals het inzetten naar meerdere regio's parallel, het uitvoeren van rooktests alleen op release branches, of het activeren van downstream pijpleidingen.
  • Portabiliteit: YAML-pijpleidingen kunnen worden gekopieerd tussen projecten, worden hergebruikt tussen teams en worden zelfs gebruikt om CI/CD op te starten voor nieuwe repositories. Templates verbeteren deze portabiliteit door teams in staat te stellen de gemeenschappelijke pijpleidinglogica centraal te delen en te onderhouden.
  • Collaboratie en code review: Pijpleidingwijzigingen zijn onderworpen aan hetzelfde pull request proces als broncode. Dit stimuleert beste praktijken zoals peer review van infrastructuurveranderingen, vermindert verkeerde configuraties en bevordert een cultuur van DevOps samenwerking.

Een versiegestuurde YAML Pipeline aanmaken

Het instellen van een YAML-pijpleiding vanaf nul is eenvoudig. Hieronder vindt u de aanbevolen stappen:

  1. Bepalen op een bestandsstructuur. Je kunt je hoofdpipeline bestand plaatsen bij de root van de repository () of in een speciale map zoals . Deze laatste benadering schalen beter wanneer je meerdere pijpleidingen hebt.
  2. Schrijf de pijpleidingdefinitie. Begin met een minimaal geldig YAML-bestand dat een trigger, een pool (agent VM-afbeelding of container) en ten minste één taak bevat. Voorbeeld:
  3. Stel het bestand in je repository. Commit en push naar de remote, om er zeker van te zijn dat het bestand zich in de branch bevindt die je wilt gebruiken als standaard branch voor de pipeline.
  4. Maak de pijplijn in Azure DevOps. Navigeer naar Pijpleidingen > Maak Pijplijn, selecteer "Azure Repos Git" (of uw gekozen bron), kies de repository, en selecteer vervolgens "Bestaande Azure Pijpleidingen YAML-bestand." Wijs naar het bestandspad dat u net hebt gemaakt (bijv. ). Azure DevOps zal de YAML ontleden en een voorbeeld tonen.
  5. Bevestigen en uitvoeren. Klik op "Rennen" om de pijplijn voor het eerst uit te voeren. U kunt de uitvoer in real time monitoren. Volgende committen aan de triggerende branches zullen automatisch nieuwe runs starten.

Voor bestaande projecten die al een klassieke pijpleiding hebben, kunt u migreren naar YAML door de pijpleidingdefinitie te exporteren of door deze te herscheppen met de YAML-editor. Microsoft biedt een migratiegids om de transitie te vergemakkelijken.

Monsterpijpleiding doorloop

Laten we een meer realistische pijplijn bekijken voor een Node.js webapplicatie die een artefact bouwt, test, publiceert en in een staging-omgeving inzet. Dit voorbeeld toont meerdere fasen, variabelen en voorwaardelijke implementatie.

trigger:
 branches:
 include:
 - main
 - develop
 paths:
 exclude:
 - 'README.md'

variables:
 nodeVersion: '18.x'
 artifactName: 'webapp'

stages:
- stage: Build
 displayName: 'Build and Test'
 jobs:
 - job: BuildJob
 pool:
 vmImage: 'ubuntu-latest'
 steps:
 - task: NodeTool@0
 inputs:
 versionSpec: $(nodeVersion)
 - script: npm install
 displayName: 'Install dependencies'
 - script: npm run lint
 displayName: 'Lint code'
 - script: npm run build
 displayName: 'Build application'
 - script: npm test
 displayName: 'Run unit tests'
 - task: PublishBuildArtifacts@1
 inputs:
 PathtoPublish: 'dist'
 ArtifactName: $(artifactName)

- stage: DeployStaging
 displayName: 'Deploy to Staging'
 dependsOn: Build
 condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
 jobs:
 - deployment: DeployJob
 pool:
 vmImage: 'ubuntu-latest'
 environment: staging
 strategy:
 runOnce:
 deploy:
 steps:
 - download: current
 artifact: $(artifactName)
 - script: echo "Deploying artifact to staging server..."
 displayName: 'Deploy step'
 - script: echo "Running smoke tests..."
 displayName: 'Smoke test'

Deze pijpleiding toont:

  • Trigger met paduitsluiting . . . documentatiewijzigingen zullen niet leiden tot een volledige opbouw.
  • Variabelen bovenaan gedefinieerd voor herbruikbaarheid.
  • Twee fasen .Bouw (niet-werkgelegenheid) en DeployStage (werkplaatstaak).De implementatiefase loopt alleen als de brontak is en de bouw geslaagd.
  • Werking met behulp van het trefwoord, dat traceerbaarheid, goedkeuringen en poorten mogelijk maakt.
  • Het publiceren en downloaden van artefacten .De build-uitvoer wordt opgeslagen en later opgehaald door de inrolfase.

Geavanceerde patronen

Multi-fase met handmatige goedkeuring

Azure DevOps YAML-pijpleidingen ondersteunen omgevingen met handmatige goedkeuringscontroles. U kunt specifieke gebruikers of groepen vragen om een implementatie goed te keuren voordat deze verder gaat. Dit wordt gedefinieerd in de YAML door een omgeving te verwijzen die goedkeuringen heeft geconfigureerd.

- stage: DeployProduction
 dependsOn: DeployStaging
 condition: succeeded()
 jobs:
 - deployment: ProdDeployment
 pool:
 vmImage: 'ubuntu-latest'
 environment: production
 strategy:
 runOnce:
 deploy:
 steps:
 - script: echo "Deploying to production..."

Voorwaardelijke uitvoering

Gebruik expressies als om te bepalen welke stadia, banen of stappen worden uitgevoerd. Azure DevOps ondersteunt een rijke expressietaal met functies voor stringmanipulatie, logische operators en verzamelingscontroles.

Containers gebruiken

In plaats van een VM-image te gebruiken, kunt u volledige taken uitvoeren in een container. Dit is ideaal voor het garanderen van consistente omgevingen in ontwikkeling en CI/CD. Geef gewoon een element onder de taak of pool.

pool:
 vmImage: 'ubuntu-latest'
container: node:18-alpine

Beste praktijken voor YAML Pijpleidingen

Tekening van productie-implementaties, hier zijn de belangrijkste praktijken om uw pijpleidingen robuust en onderhoudbaar te houden:

  • Gebruik sjablonen liberaal. Uitpakken van gemeenschappelijke stappen in geparametriseerde sjablonen. Dit vermindert duplicatie en maakt het gemakkelijk om standaarden af te dwingen (bijvoorbeeld een security scan template die alle projecten moeten uitvoeren).
  • Houd YAML-bestanden klein en gefocust. Een monolithisch bestand wordt moeilijk te lezen en te debuggen. Splitsing in meerdere bestanden georganiseerd per fase of functie (bijv. , , ).
  • Beveiligde geheimen met Azure Key Vault. Vermijd hardcoding wachtwoorden, API sleutels, of certificaten. Gebruik variabele groepen gekoppeld aan Key Vault, en referentie ze in uw pijplijn. Azure DevOps zal automatisch halen de nieuwste waarden op runtime.
  • Valideer YAML syntax voordat u commit. Gebruik een linter of IDE-plugin om inspringfouten en ontbrekende sleutels te vangen. Azure DevOps biedt ook een "Validate" knop in de pipeline editor.
  • Naambronnen duidelijk. Geef stadia, banen en stappen betekenisvol waarden. Dit verbetert de leesbaarheid in logs en visualisaties aanzienlijk.
  • Gebruik pijpleidingcaching om de opbouw te versnellen. Cache afhankelijkheden zoals of NuGet pakketten om te voorkomen dat ze opnieuw worden gedownload op elke run. Azure DevOps biedt hiervoor een taak.
  • Early failment implementeren. De pijpleiding zo snel mogelijk uit laten gaan. Controles uitvoeren voor dure integratietests. Gebruik de optie in scripttaken om waarschuwingen te vangen die in fouten zijn omgezet.
  • Documenteer uw pijpleiding. Inclusief opmerkingen in het YAML-bestand waarin niet-duidelijke keuzes worden uitgelegd, vooral bij het gebruik van expressies of voorwaardelijke logica. Overweeg om een README naast de pijpleiding bestanden te behouden.

Integratie met andere gereedschappen

Azure DevOps YAML-pijpleidingen integreren inheems met tal van diensten. Gemeenschappelijke integraties omvatten:

  • SonarQube voor continue codekwaliteitscontrole . Voeg een SonarQubePrepare taak toe voordat u bouwt en een SonarQubeAnalyseer taak erna.
  • Docker voor containerbouwt
  • GitHub . . YAML-pijpleidingen kunnen worden geconfigureerd om te werken met GitHub repositories, niet alleen Azure Repos. Selecteer GitHub als uw bron tijdens het aanmaken van de pijpleiding.
  • DienstNu voor veranderingsbeheer .De uitbreiding van het beheer van de ServiceNow Change Management maakt het mogelijk pijpleidingen om verzoeken tot wijziging te creëren en bij te werken tijdens implementaties.

Zie voor een volledige lijst van beschikbare taken de Azure Pijpleidingen Taken documentatie.

Vaak Pitfalls en hoe ze te vermijden

Zelfs ervaren teams lopen af en toe problemen met YAML pijpleidingen. Hieronder staan frequente fouten en hun oplossingen:

  • Ongeldige YAML syntax . .Trailing spaties, inconsistente inspringing (YAML staat geen tabs toe). Gebruik een validatietool in uw editor of Azure DevOps' YAML parser.
  • Onduidelijke variabele scoping
  • Misgeconfigureerde triggers . . vergeten om een trigger resultaat in de pijplijn alleen die op handmatige of geplande triggers. Controleer de trigger sectie dekt uw beoogde takken en paden.
  • Ontkenning van de poolcapaciteit van de agent . . . met behulp van een pool van particuliere middelen zonder dat voldoende agenten vertragingen of storingen kunnen veroorzaken. Overweeg om Microsoft-gehoste middelen te gebruiken voor een betere elasticiteit.
  • Niet testen van pijpleidingwijzigingen . . Doe altijd een test bouwen op een tak voordat merging naar hoofd. Zelfs kleine wijzigingen aan templates kunnen tientallen pijpleidingen stil breken.

Conclusie

Azure DevOps YAML-pijpleidingen vertegenwoordigen een volwassen, code-eerste benadering van CI/CD die van kleine projecten naar enterprise-level release engineering schalen. Door pijpleidingdefinities onder versiecontrole te plaatsen, krijgen teams transparantie, reproduceerbaarheid en een naadloze brug tussen ontwikkeling en activiteiten. De YAML-syntax is expressief genoeg om complexe workflows te modelleren, maar toch gestructureerd genoeg om leesbaar en onderhoudbaar te blijven wanneer ze gekoppeld zijn aan templates en beste praktijken.

Het adopteren van versie-gecontroleerde pijpleidingen is niet alleen over automatisering . . het gaat over het behandelen van de leveringsproces met dezelfde rigor als de toepassingscode. Voor teams die op zoek zijn naar een verhoging van de inzet frequentie, het verminderen van handmatige fouten, en het verbeteren van de samenwerking, Azure DevOps YAML pijpleidingen zijn een bewezen basis. Begin met het definiëren van een eenvoudige pijplijn voor uw project, vervolgens incrementele toe te voegen stadia, templates, en integraties als je volwassenheid groeit.