Övning – Skapa flera konfigurationer med hjälp av mallar

11 minuter

I de föregående övningarna implementerade du en pipeline som skapar webbplatsen Space Game . Du började med ett skript som utförde varje byggåtgärd och mappade varje åtgärd till motsvarande pipelineaktivitet. Pipelinens utdata är en .zip fil som innehåller den kompilerade webbappen.

I den här övningen använder du en mall för att definiera bygguppgifter som kan skapa valfri konfiguration som definierats i projektfilen. Med mallar kan du definiera din logik en gång och sedan återanvända den flera gånger. Mallar kombinera innehållet i flera YAML-filer i en enda pipeline.

Dricks

Det här steget i modulen är valfritt. Om du inte vill lära dig mer om mallar just nu går du vidare till nästa steg: Rensa din Azure DevOps-miljö. Mer information om mallar finns i Malltyper och användning.

Vi börjar med att titta hur det går för Mara och Amita.

Demonstrationen

Mara ser fram emot att dela med sig av sitt resultat. Hon letar upp Amita för att visa henne bygg-pipelinen.

Amita: Jag är imponerad av att du fick detta att fungera så snabbt! Faktum är att jag bara kom för att träffa dig eftersom jag fick ett e-postmeddelande som berättade för mig att bygget var redo. Tack! Jag ser att pipelinen endast skapar versionskonfigurationen. Vi använder också felsökningsversioner så att vi kan samla in ytterligare information om appen kraschar. Kan vi lägga till det?

Mara: Absolut. Jag glömde Debug-byggen när jag gjorde det här. Vad sägs om att vi lägger till det tillsammans?

Amita: Du visade mig YAML-filen som definierar byggstegen, men jag är inte säker på att jag vet hur jag ska ändra den.

Mara: Det är okej. Du kan titta på medan jag skriver. Vi tänker igenom det tillsammans.

Hur definierar du båda byggkonfigurationerna?

Överväg följande uppgifter som skapar och publicerar Space Game-webbprojektets Release-konfiguration. (Lägg inte till den här koden i din azure-pipelines.yml-fil.)

- task: DotNetCoreCLI@2
  displayName: 'Build the project - Release'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration Release'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - Release'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration Release --output $(Build.ArtifactStagingDirectory)/Release'
    zipAfterPublish: true

Om du vill skapa felsökningskonfigurationen kan du upprepa dessa två uppgifter, men ersätta Release med Debug.

Om du gör det får du det resultat du letar efter, men vad händer när bygget blir mer komplext eller om kraven ändras? Du skulle behöva leta upp och ändra båda varianterna av varje bygguppgift manuellt. När du har lagt till de ytterligare byggkraven behöver du också skapa två uppgifter, en för felsökningskonfigurationen och en för Release, för att uppfylla dessa krav.

En bättre lösning är att använda en mall.

Vad är mallar?

Med en mall kan du definiera vanliga bygguppgifter en gång och återanvända dessa uppgifter flera gånger.

Du anropar en mall från den överordnade pipelinen som ett byggsteg. Du kan skicka parametrar till en mall från den överordnade pipelinen.

Mara kan definiera uppgifter för att skapa och publicera appen som en mall och sedan tillämpa mallen på varje konfiguration hon behöver.

Definiera mallen

Kom ihåg att med en mall kan du definiera vanliga bygguppgifter en gång och återanvända dessa uppgifter flera gånger. Du anropar en mall från dess överordnade mall som ett byggsteg och skickar parametrar till en mall från den överordnade pipelinen.

Nu ska du skapa en mall som kan skapa alla konfigurationer som har definierats i projektfilen.

Skapa en mallkatalog i roten av projektet från den integrerade Visual Studio Code-konsolen.
```
mkdir templates
```
I praktiken kan du placera en mallfil på valfri plats. Du behöver inte placera dem i mallkatalogen.
I Visual Studio Code väljer du Arkiv > Ny fil. Om du vill spara den tomma filen som build.yml i projektets mallkatalog väljer du Spara fil>. Ett exempel skulle vara ~/mslearn-tailspin-spacegame-web/templates.

Viktigt!

Som tidigare väljer du YAML i listan Spara som-typ i Windows.

I Visual Studio Code lägger du till den här koden i build.yml:

parameters:
  buildConfiguration: 'Release'

steps:
- task: DotNetCoreCLI@2
  displayName: 'Build the project - ${{ parameters.buildConfiguration }}'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration ${{ parameters.buildConfiguration }}'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - ${{ parameters.buildConfiguration }}'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration ${{ parameters.buildConfiguration }} --output $(Build.ArtifactStagingDirectory)/${{ parameters.buildConfiguration }}'
    zipAfterPublish: true

De här uppgifterna ser ut som de som du definierade tidigare för att skapa och publicera appen. men i en mall arbetar du med indataparametrar på ett annat sätt än du arbetar med vanliga variabler. Här följer två skillnader:

I en mallfil använder du avsnittet parameters i stället variables för för att definiera indata.
I en mallfil använder du ${{ }} syntax i stället för $() för att läsa en parameters värde. När du läser värdet för en parameter tar du med parameters avsnittet i dess namn. Exempel: ${{ parameters.buildConfiguration }}

Anropa mallen från pipelinen

Nu ska du anropa mallen som du nyss skapade från pipelinen. Du gör det en gång för felsökningskonfigurationen och upprepar sedan processen för versionskonfigurationen.

I Visual Studio Code ändrar du azure-pipelines.yml som du ser här:

trigger:
- '*'

pool:
  vmImage: ubuntu-latest

variables:
  buildConfiguration: 'Release'
  wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
  dotnetSdkVersion: '6.x'

steps:
- task: UseDotNet@2
  displayName: 'Use .NET SDK $(dotnetSdkVersion)'
  inputs:
    version: '$(dotnetSdkVersion)'

- task: Npm@1
  displayName: 'Run npm install'
  inputs:
    verbose: false

- script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
  displayName: 'Compile Sass assets'

- task: gulp@1
  displayName: 'Run gulp tasks'

- script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
  displayName: 'Write build info'
  workingDirectory: $(wwwrootDir)

- task: DotNetCoreCLI@2
  displayName: 'Restore project dependencies'
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

- template: templates/build.yml
  parameters:
    buildConfiguration: 'Debug'

- template: templates/build.yml
  parameters:
    buildConfiguration: 'Release'

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  condition: succeeded()

trigger:
- '*'

pool:
  name: 'Default' #replace if needed with name of your agent pool

variables:
  buildConfiguration: 'Release'
  wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
  dotnetSdkVersion: '6.x'

steps:
- task: UseDotNet@2
  displayName: 'Use .NET SDK $(dotnetSdkVersion)'
  inputs:
    version: '$(dotnetSdkVersion)'

- task: Npm@1
  displayName: 'Run npm install'
  inputs:
    verbose: false

- script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
  displayName: 'Compile Sass assets'

- task: gulp@1
  displayName: 'Run gulp tasks'

- script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
  displayName: 'Write build info'
  workingDirectory: $(wwwrootDir)

- task: DotNetCoreCLI@2
  displayName: 'Restore project dependencies'
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

- template: templates/build.yml
  parameters:
    buildConfiguration: 'Debug'

- template: templates/build.yml
  parameters:
    buildConfiguration: 'Release'

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  condition: succeeded()

Den här filen ser ut som originalet, förutom att den ersätter bygg- och publiceringsuppgifterna med anrop till mallen som utför samma uppgifter.

Du ser att mallen anropas en gång för varje konfiguration. För att skicka konfigurationsnamnet till mallen använder parameters varje template uppgift argumentet.

Köra pipelinen

Nu ska du skicka ändringarna till GitHub och se pipelinekörningen.

Från den integrerade terminalen lägger du till azure-pipelines.yml och templates/build.yml i indexet, checkar in ändringarna och skickar ändringarna till GitHub.
```
git add azure-pipelines.yml templates/build.yml
git commit -m "Support build configurations"
git push origin build-pipeline
```
Från Azure Pipelines spårar du bygget genom varje steg på samma sätt som tidigare.

När pipelinen körs ser du att processen expanderar uppgifterna i mallen. De uppgifter som skapar och publicerar projektet körs två gånger, en gång för varje byggkonfiguration.
När bygget är klart går du tillbaka till sammanfattningssidan och väljer den publicerade artefakten som du gjorde tidigare. Expandera mappen drop.

Du ser att pipelinen skapar en .zip fil för både felsökningskonfigurationen och versionskonfigurationen.

Sammanfoga grenen till main

Nu har du en fungerande byggpipeline som åstadkommer allt Mara behöver just nu.

I praktiken skickar du en pull-begäran som sammanfogar din build-pipeline gren till grenen main .

Vi hoppar över det steget för tillfället. I nästa modul får du lära dig några sätt att samarbeta med ditt team på GitHub, inklusive hur du skickar, granskar och sammanfogar pull-begäranden.