Hoe gebruik je templates met Azure Pipelines

29 januari 2021 • Technologie • 8 min leestijd

Azure Devops is een Microsoft dienst waar mee code projecten beschikbaar kunnen gesteld worden voor anderen. In deze technische blog geef ik een introductie hoe ik templates hergebruik. De Azure Pipelines werken vrijwel met elke programmeertaal of projecttype. Deze tool combineert Continuous Integration (CI) and Continuous Delivery (CD) om continue het project te compileren en testen. Dit is een methode voor het frequent leveren van applicaties naar (eind)klanten waarbij vrijwel alle stappen geautomatiseerd zijn.

Met Azure Pipelines is het gebruikelijk om de build pipelines in yaml te definieren. Dit zijn tekst bestanden waarin alle stappen worden uitgeschreven. Deze yaml bestanden worden ingecheckt in het versie beheer systeem. Het voordeel van deze werkwijze is dat deze per branch verschillend kunnen zijn, zodat je veranderingen niet op een centraal moment moet doorvoeren.

Vooral bij een complexer project is handig om verschillende onderdelen her te gebruiken voor bijvoorbeeld verschillende onderdelen. In het onderstaande project zijn een aantal onderdelen. Het is namelijk niet altijd nodig dat alles wordt gebouwd, vooral als je er geen veranderingen in heb doorgevoerd.

Een belangrijk voordeel is om het op te splitsen is dat je verschillende templates kunt hergebruiken, dit voorkomt dubbele code en de naam van de bestanden geven al een overzicht van de taken die hierin worden uitgevoerd.

In het project dat ik hier als voorbeeld gebruik hou ik de volgende verdeling aan:

1. Server. De backend van de website, in ons geval is dat is het Sitecore platform
2. Client. Losse front-end frameworks die los staan van de backend.
3. Services. Losse Windows services, die achtergrond taken uitvoeren.
4. Develop CI. Dat is een combinatie van alle bovenstaande pipelines

See English version of this article on Medium

Hieronder een schermafbeelding van hoe de pipeline inrichting eruit ziet.

Develop CI

Ik begin hier bij de Develop CI omdat deze de verschillende onderdelen allemaal bevat. In Azure Devops klik in het pipeline venster op ‘New pipeline’. Vervolgens selecteer ik de locatie van de repository. Dit kan zowel in Azure Devops als op Github zijn. Dan worden er een aantal opties voorgesteld. Ik begin hier met de starter pipeline en kies een locatie. Voor nu ga ik voor de Develop CI uit startpunt: /azure-pipeline/develop-ci.yml Wanneer je op ‘Save and Run’ klikt dan wordt deze ingecheckt. Vervolgens wordt de pipeline uitgevoerd.

Parallel lopende machines met Stages

In het (bovenstaande) starter voorbeeld wordt maar 1 machine tegelijk gebruikt. Voor een groter project is het handiger als onderdelen parallel lopen. Hier zijn wel kosten aan verbonden. Als je pipelines afgeschermd zijn en je gebruikt de gratis variant dan heb je 1 machine per organisatie beschikbaar met een maximum van 1800 minuten per maand. Dit kan veranderen maar dit is de huidige situatie van januari 2021.

De stages in de yaml pipeline zijn bijwijze van spreken de verschillende boeken en jobs de hoofdstukken. De jobs worden op verschillende machines uitgevoerd. De laatste stap ‘Merge’ wacht voordat de Client en Server stages zijn afgerond.

Hieronder de yaml pipeline voor /azure-pipeline/develop-ci.yml


trigger: none

pr:
- development

variables:
  buildPlatform: "Any CPU"
  buildConfiguration: "Release"
  webroot: "$(build.artifactstagingdirectory)/wwwroot"
  serverPool: "windows-latest"
  clientPool: "ubuntu-20.04"
  serverSitecoreArtifact: "server_sitecore"
  serverUnicornDataArtifact: "server_unicorn_sitecore_data"
  serverConfigCollectionArtifact: "server_config_collection"
  clientArtifact: "client"
  mergeArtifact: "merge"
  npm_config_cache: $(Pipeline.Workspace)/.npm

stages:
  - stage: Server
    dependsOn: []
    jobs:
      - template: /azure-pipeline/jobs/server_sitecore.yml
        parameters:
          pool: "$(serverPool)"
          artifact: "$(serverSitecoreArtifact)"

      - template: /azure-pipeline/jobs/server_config_collection.yml
        parameters:
          pool: "$(serverPool)"
          artifact: "$(serverConfigCollectionArtifact)"
          serverUnicornDataArtifact: "$(serverUnicornDataArtifact)"

  - stage: Client
    dependsOn: []
    jobs:
      - template: /azure-pipeline/jobs/client.yml
        parameters:
          pool: "$(clientPool)"
          artifact: "$(clientArtifact)"

  - stage: Services
    dependsOn: []
    jobs:
      - template: /azure-pipeline/jobs/services.yml
        parameters:
          pool: "$(serverPool)"
          solutions:
            - key: service1
              value: "/src/service1.csproj" 

  - stage: Merge
    dependsOn:
      - Server
      - Client
    jobs:
      - template: /azure-pipeline/jobs/merge.yml
        parameters:
          pool: "$(serverPool)"
          artifact: "$(collectionArtifact)"
          serverSitecoreArtifact: "$(serverSitecoreArtifact)"
	   clientArtifact: "$(clientArtifact)"
          mergeArtifact: "$(mergeArtifact)"

Loop door een lijst om verschillende services te bouwen

Wanneer je verder inzoomt op de Services taak. Deze staat hieronder uitgeschreven. De services yaml wordt als template aangeroepen in de ‘Develop CI’ pipeline onder het kopje templates. De uitkomst is dat deze job meerdere artifacts maakt. Een artifact is de uitkomst van een build taak. Dit kan een mapje met dll’s zijn of een mapje met css en javascript.

In de ‘Develop CI’ yaml defineer ik de parameters. In de services yaml staan ook parameters, maar deze worden overschreven. Deze staan er alleen maar voor het geval de parameters niet wordt meegegeven.

Hieronder de yaml pipeline voor /azure-pipeline/jobs/services.yml


parameters:
  pool:
    vmImage: windows-2019
  nuGetVersion: "5.2.0"
  solutionDir: '$(Build.SourcesDirectory)/src/'
  slnFile: '$(Build.SourcesDirectory)/src/Project.sln'
  job: ServicesRabbit
  solutions: 
    - key: service1
      value: "/src/service1.csproj" 
  BuildArguments: "/p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem"

jobs:
  - job: ${{ parameters.job }}
    displayName: "Services "
    workspace:
      clean: all
    pool:
      vmImage: ${{ parameters.pool }}
      demands:
        - msbuild
    variables:
      outputPath: '$(build.artifactstagingdirectory)\is_over_written_default'
    steps:
      - checkout: self
        clean: true
        fetchDepth: 1

      - template: /azure-pipeline/steps/server_net_restore.yml
        parameters:
          solution: ${{ parameters.slnFile }}

      - ${{ each item in parameters.solutions }}:

        - task: PowerShell@2
          enabled: true
          displayName: "[net] update output path"
          inputs:
            targetType: 'inline'
            script: |
              $updateOutputPath = "$(build.artifactstagingdirectory)/${{ item.key }}"
              Write-Output "##vso[task.setvariable variable=outputPath]$updateOutputPath"

        - task: VSBuild@1
          displayName: "[net] Build ${{ item.key }}"
          inputs:
            solution: "$(Build.SourcesDirectory)${{ item.value }}"
            vsVersion: "16.0"
            msbuildArgs: '${{ parameters.BuildArguments }} /p:SolutionDir="${{ parameters.solutionDir }}"'
            platform: "$(buildPlatform)"
            configuration: "$(buildConfiguration)"
            maximumCpuCount: true

        - task: PublishPipelineArtifact@1
          enabled: true
          displayName: "[net] Publish Project ${{ item.key }}"
          inputs:
            artifactName: ${{ item.key }}
            targetPath: $(build.artifactstagingdirectory)/${{ item.key }}
            publishLocation: "pipeline"

Losse stappen binnen de jobs

Om onderdelen her te gebruiken binnen de verschillende jobs, splits je de stappen uit. Dit is bijvoorbeeld handig voor het ophalen van de externe software bibliotheken. Deze stap wordt op meerdere plekken gebruikt. Om dubbele code te voorkomen gebruik deze stap als template.

In het onderstaande voorbeeld restore ik de nuget packages van de solution. Voor dit .NET Framework project wordt de packages.config style gebruikt. In de eerste taak wordt gezocht naar alle ‘packages.config’ bestanden in het project. Hier wordt een hash van gemaakt zodat als er iets in één van deze bestanden iets veranderd er geen gebruik wordt gemaakt van de oude cache map. Als de config bestanden niet veranderen dan blijft de key het zelfde. In Azure Devops is de cache key scoped tot de pipeline en als deze niet binnen 7 dagen wordt gebruikt dan wordt de inhoud verwijderd.

De inhoud van: /azure-pipeline/steps/server_net_restore.yml

parameters:
  verbose: false
  nuGetVersion: "5.2.0"
  solution: '$(Build.SourcesDirectory)\src\Project.sln’

steps:

  - task: Cache@2
    displayName: "[net] Cache NuGet packages"
    inputs:
      key: 'nuget | "$(Agent.OS)" | **/packages.config,!**/bin/**'
      restoreKeys: |
        nuget | "$(Agent.OS)"
      path: '$(Build.SourcesDirectory)/src/packages'

  - task: NuGetToolInstaller@1
    displayName: "[net] Use NuGet ${{ parameters.nuGetVersion }}"
    inputs:
      versionSpec: ${{ parameters.nuGetVersion }}
      
  - task: NuGetCommand@2
    displayName: "[net] NuGet Restore"
    inputs:
      restoreSolution: "${{ parameters.solution }}"
      feedsToUse: config

Merge job

Als laatste stap in het build proces is het combineren van de artifacts voordat deze naar een omgeving worden gereleased. Het is aan jou of je dit in de build stap doet of dat je dit tijdens de release doet. In het onderstaande voorbeeld is het niet te zien maar in mijn geval waren verschillende front-end frameworks die op verschillende locaties staan dus leek het mij slim om dit al voordat de release start alles al bij elkaar te brengen.

Dit is : /azure-pipeline/jobs/merge.yml

parameters:
  pool: "ubuntu-latest"
  serverSitecoreArtifact: "server_sitecore"
  clientArtifact: "client"
  mergeArtifact: "merge"

jobs:
  - job: Merge
    displayName: Merge website artifacts
    pool:
      vmImage: ${{ parameters.pool }}
    steps:
      - checkout: none

      - task: DownloadPipelineArtifact@2
        displayName: "[$(serverSitecoreArtifact)] DownloadPipelineArtifact"
        inputs:
          artifact: $(serverSitecoreArtifact)
          downloadPath: '$(pipeline.workspace)/$(serverSitecoreArtifact)'

      - task: DownloadPipelineArtifact@2
        displayName: "[$(clientArtifact)] DownloadPipelineArtifact"
        inputs:
          artifact: $(clientArtifact)
          downloadPath: '$(pipeline.workspace)/$(clientArtifact)'

      - task: PowerShell@2
        enabled: true
        displayName: rename $(serverSitecoreArtifact) to $(mergeArtifact)
        inputs:
          targetType: 'inline'
          script: |
            Move-Item -Path $(pipeline.workspace)/$(serverSitecoreArtifact) -Destination $(pipeline.workspace)/$(mergeArtifact)

      - task: PowerShell@2
        enabled: true
        displayName: Merge $(clientArtifact) in $(mergeArtifact) (When /assets/client already exist)
        inputs:
          targetType: 'inline'
          script: |
            Get-ChildItem -Path $(pipeline.workspace)/$(clientArtifact) | Copy-Item -Destination $(pipeline.workspace)/$(mergeArtifact)/assets/client -Recurse -Force

      - task: PublishPipelineArtifact@1
        enabled: true
        displayName: Publish $(mergeArtifact) Artifact
        inputs:
          targetPath: "$(pipeline.workspace)/$(mergeArtifact)"
          artifact: $(mergeArtifact)
          publishLocation: "pipeline"

De conclusie dat het goed mogelijk is om pipelines op te splitsen in losse bestanden waardoor het makkelijker wordt om het overzicht te houden. Op deze manier voorkom je dubbele code en automatiseer je de release van de applicatie.

Deze blog verscheen voor het eerst op qdraw.nl