Oefening: meerdere configuraties bouwen met behulp van sjablonen

11 minuten

In de vorige oefeningen hebt u een pijplijn geïmplementeerd die de Space Game-website bouwt. U bent begonnen met een script dat elke buildactie heeft uitgevoerd en elke actie aan de bijbehorende pijplijntaak heeft toegewezen. De uitvoer van de pijplijn is een .zip bestand dat de gecompileerde web-app bevat.

In deze oefening gebruikt u een sjabloon om buildtaken te definiëren die elke configuratie kunnen bouwen die is gedefinieerd in het projectbestand. Met sjablonen kunt u uw logica eenmalig definiëren en vervolgens meerdere keren opnieuw gebruiken. Sjablonen combineren de inhoud van meerdere YAML-bestanden in één pijplijn.

Tip

Deze stap in de module is optioneel. Als u op dit moment niet meer wilt weten over sjablonen, gaat u verder met de volgende stap, uw Azure DevOps-omgeving opschonen. Zie Sjabloontypen en -gebruik voor meer informatie over sjablonen.

Laten we beginnen met het inchecken met Mara en Amita.

De demo

Mara, enthousiast om haar resultaten te delen, traceert Amita om haar de build-pijplijn te laten zien.

Amita: Ik ben onder de indruk dat je dit zo snel hebt laten werken! Eigenlijk kwam ik net naar je toe omdat ik een e-mailbericht kreeg dat de build gereed was. Bedankt! Ik zie dat de pijplijn alleen de releaseconfiguratie bouwt. We gebruiken ook Builds voor foutopsporing, zodat we aanvullende informatie kunnen vastleggen als de app vastloopt. Kunnen we dat toevoegen?

Mara: Absoluut. Ik ben vergeten om builds voor foutopsporing te overwegen wanneer ik dit heb ingesteld. Hoe zit het met elkaar zitten en het toevoegen?

Amita: U hebt het YAML-bestand laten zien dat de buildstappen definieert, maar ik weet niet zeker hoe ik het moet wijzigen.

Mara: Dat is oké. Je kunt kijken terwijl ik typ. We kunnen het samen doordenken.

Hoe kunt u beide buildconfiguraties definiëren?

Houd rekening met de volgende taken die de releaseconfiguratie van het Space Game-webproject bouwen en publiceren. (Voeg deze code niet toe aan uw azure-pipelines.yml-bestand .)

- 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

Als u de foutopsporingsconfiguratie wilt bouwen, kunt u deze twee taken herhalen, maar vervangen door ReleaseDebug.

Als u dit doet, krijgt u het resultaat dat u zoekt, maar wat gebeurt er wanneer uw build complexer wordt of uw vereisten veranderen? U moet beide variaties van elke buildtaak handmatig zoeken en wijzigen. Nadat u de aanvullende buildvereisten hebt toegevoegd, moet u ook twee taken maken, één voor de foutopsporingsconfiguratie en één voor release, om aan deze vereisten te voldoen.

Een betere oplossing is het gebruik van een sjabloon.

Wat zijn sjablonen?

Met een sjabloon kunt u algemene buildtaken eenmaal definiëren en deze taken meerdere keren opnieuw gebruiken.

U roept een sjabloon aan vanuit de bovenliggende pijplijn als een buildstap. U kunt parameters doorgeven aan een sjabloon vanuit de bovenliggende pijplijn.

Mara kan taken definiëren voor het bouwen en publiceren van de app als sjabloon en past die sjabloon vervolgens toe op elke configuratie die ze nodig heeft.

De sjabloon definiëren

Houd er rekening mee dat u met een sjabloon algemene buildtaken één keer kunt definiëren en deze taken meerdere keren opnieuw kunt gebruiken. U roept een sjabloon van de bovenliggende sjabloon aan als een buildstap en geeft parameters door aan een sjabloon vanuit de bovenliggende pijplijn.

U maakt nu een sjabloon die elke configuratie kan bouwen die is gedefinieerd in het projectbestand.

Maak vanuit de geïntegreerde Visual Studio Code-console in de hoofdmap van uw project een map met sjablonen .
```
mkdir templates
```
In de praktijk kunt u een sjabloonbestand op elke locatie plaatsen. U hoeft ze niet in de map met sjablonen te plaatsen.
Selecteer bestand > nieuw bestand in Visual Studio Code. Als u vervolgens het lege bestand wilt opslaan als build.yml in de map met sjablonen van uw project, selecteert u Bestand > opslaan. Een voorbeeld hiervan is ~/mslearn-tailspin-spacegame-web/templates.

Belangrijk

Net als voorheen, in Windows, selecteert u YAML in de lijst Opslaan als.

Voeg in Visual Studio Code deze code toe aan 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

Deze taken lijken op de taken die u eerder hebt gedefinieerd om de app te bouwen en te publiceren; maar in een sjabloon werkt u met invoerparameters anders dan met normale variabelen. Hier volgen twee verschillen:

Gebruik in een sjabloonbestand de parameters sectie in plaats van variables invoer te definiëren.
Gebruik ${{ }} in een sjabloonbestand syntaxis in plaats van de waarde van $() een parameter te lezen. Wanneer u de waarde van een parameter leest, neemt u de sectie op in de parameters naam. Bijvoorbeeld: ${{ parameters.buildConfiguration }}.

De sjabloon aanroepen vanuit de pijplijn

U roept nu de sjabloon aan die u zojuist hebt gemaakt op basis van de pijplijn. U doet dit eenmalig voor de foutopsporingsconfiguratie en herhaalt vervolgens het proces voor de releaseconfiguratie.

Wijzig in Visual Studio Code azure-pipelines.yml zoals u hier ziet:

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()

Dit bestand lijkt op het origineel, behalve dat het de build- en publicatietaken vervangt door aanroepen naar de sjabloon die dezelfde taken uitvoert.

U ziet dat de sjabloon één keer wordt aangeroepen voor elke configuratie. Elke taak gebruikt het parameters argument om de configuratienaam door te geven aan de sjabloontemplate.

De pijplijn uitvoeren

U pusht nu uw wijzigingen naar GitHub en ziet de pijplijnuitvoering.

Voeg vanuit de geïntegreerde terminal azure-pipelines.yml en sjablonen/build.yml toe aan de index, voer de wijzigingen door en push de wijzigingen naar GitHub.
```
git add azure-pipelines.yml templates/build.yml
git commit -m "Support build configurations"
git push origin build-pipeline
```
Volg vanuit Azure Pipelines de build via elk van de stappen die u eerder hebt uitgevoerd.

Terwijl de pijplijn wordt uitgevoerd, ziet u dat het proces de taken in de sjabloon uitbreidt. De taken die het project bouwen en publiceren, worden twee keer uitgevoerd, eenmaal voor elke buildconfiguratie.

Schermopname van Azure Pipelines met de uitgevouwen sjabloontaken. Inbegrepen zijn build- en publicatietaken voor zowel de foutopsporings- als releaseconfiguraties.
Wanneer de build is voltooid, gaat u terug naar de overzichtspagina en selecteert u het gepubliceerde artefact zoals u dat eerder hebt gedaan. Vouw de vervolgkeuzelijst uit.

U ziet dat de pijplijn een .zip-bestand produceert voor zowel de foutopsporingsconfiguratie als de releaseconfiguratie.

Schermopname van Azure Pipelines met de verpakte toepassing voor configuraties voor foutopsporing en release.

De vertakking samenvoegen in de hoofdmap

Op dit moment hebt u een werkende build-pijplijn die alles bereikt wat Mara nu nodig heeft.

In de praktijk verzendt u een pull-aanvraag waarmee uw build-pipeline vertakking wordt samengevoegd in de main vertakking.

We slaan die stap voorlopig over. In de volgende module leert u enkele manieren om samen te werken met uw team op GitHub, waaronder het verzenden, beoordelen en samenvoegen van pull-aanvragen.