Azure pipeline

Links

• Azure Pipelines documentation
• Key concepts for new Azure Pipelines users
• Use approvals and gates to control your deployment

Definitions

Term	Definition
Artifact	item from a git repository or a build pipeline
Stages	steps to deploy and validate a software a stage contains jobs
Job	subparts of a stage, contains tasks to execute listed as steps a job runs on a agent or can be manually ran
Tasks / Steps	subparts of a job, those are the concreate action to execute
Release pipeline definition	steps to execute to get the artefacts, install and validate the software template to run a release
Release agent	the one who execute the tasks defined in the release pipeline definition it is the same agent as the one used for the build

Steps of a release

1. Build the software with a pipeline
   • validate product quality (unit tests, SonarCloud)
2. Deploy the software
   • validate runtime stability (compare telemetry with previous version)
3. Release the feature
   • validate feature usage

Release variables

• Predefined variables

Trigger pipeline for PR

1. Azure DevOps → MyProject → Project Settings (bottom left gear)
2. Repos → Repositories → MyRepo
3. Policies → Branch Policies → master
4. Build Validation → +

YAML

• Specify jobs in your pipeline
• Template types & usage
• Approvals in environments with multi-stage YAML pipelines
• YAML schema reference

Create a new pipeline

From an existing YAML file

• Pipelines → New pipeline
• Azure Repo Git YAML → Select your repo → Existing Azure pipelines YAML file

Exemple

# do not trigger the pipeline on events trigger: none parameters: - name: myStepList type: stepList default: - bash: echo "We are on $(MyVar)" # If you have a single stage, you can omit the stages keyword and directly specify the jobs keyword stages: - stage: CI displayName: CI stage # remove implicite depency on the previous stage, the stages will run in parallel dependsOn: [] jobs: - job: ci_job pool: MyPool # If you have a single stage and a single job, you can omit the stages and jobs keywords and directly specify the steps keyword steps: - powershell: Write-Host "We are on CI" enabled: false # disable the task - stage: PROD displayName: PROD stage dependsOn: [] jobs: # use deployment job with environment and strategy to use the approval mechanism - deployment: prod_job environment: PROD strategy: runOnce: deploy: steps: ${{ parameters.myStepList }}

Stage

stages: - stage: stage_name # (A-Z, a-z, 0-9, and underscore) # friendly name to display in the UI displayName: 'Stage name' variables: # ... condition: # ... jobs: [ job | templateReference]

Job

jobs: - job: job_name # (A-Z, a-z, 0-9, and underscore) # friendly name to display in the UI displayName: 'Job name' variables: # ... pool: PoolName dependsOn: job1 dependsOn: - job1 - job2 condition: # ... # what to clean up before the job runs workspace: clean: outputs | resources | all steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]

Task

steps: # step - task: TaskToCall@Version # VSBuild@1 name: StepName # A-Z, a-z, 0-9, and underscore displayName: 'My Step' timeoutInMinutes: 120 inputs: key: 'value' enabled: boolean # runs a script in Bash - bash: | which bash echo Hello $(whoami) # friendly name displayed in the UI displayName: Multiline Bash script # runs a script in PowerShell Core - pwsh: Write-Host Hello $(name) # runs a script in Windows PowerShell - powershell: Write-Host Hello $(name) # checkout git repo - checkout: self | none | repository name # self represents the repo where the initial Pipelines YAML file was found clean: boolean # if true, run `execute git clean -ffdx && git reset --hard HEAD` before fetching fetchDepth: number # the depth of commits to ask Git to fetch

• Shallow fetch

PowerShell task

- powershell: 'cmd' # 4 blank characters before the command - powershell: | cmd1 cmd2 # pwsh runs PowerShell Core, which must be installed on the agent or container. - pwsh: 'cmd' - task: PowerShell@2 displayName: 'PowerShell Script' inputs: targetType: filePath filePath: 'MyScript.ps1' arguments: '-Arg1 "Arg1"' - task: PowerShell@2 displayName: 'PowerShell Script' inputs: targetType: inline script: | cmd1 cmd2

Pool

# if you use a private pool and don't need to specify demands pool: PoolName pool: name: PoolName demands: - myCustomCapability # check for existence of capability - agent.os -equals Darwin # check for specific string in capability

Variables

# scope: root, stage, job variables: variable_name: 'value' variables: - name: variable_name value: 'value' # groups are used to make variables inside that group available across multiple pipelines - group: group_name steps: - powershell: 'echo $(System.StageName) - $(variable_name) - $(group_variable_name)'

• Use predefined variables
• Create a variable group

Runtime parameters

Ces paramètres sont sélectionnable à chaque lancement de la pipeline.

parameters: - name: my_parameter displayName: My parameter type: string default: Value1 values: - Value1 - Value2

Repositories

• Supported source repositories
• Resources in YAML
• Multi-repo checkout

By default current pipeline repo is checked out.

resources: repositories: - repository: RepoId # A-Z, a-z, 0-9, and underscore name: ProjectName/RepoName # repository name (format depends on `type`) type: git ref: master steps: - checkout: self # checkout in C:\agent\_work\1\s\CurrentRepoId - checkout: RepoId # checkout in C:\agent\_work\1\s\RepoId

Single repository: If you have a single checkout step in your job, (or you have no checkout step which is equivalent to checkout: self), your source code is checked out into a directory called s. Ex: C:\agent\_work\1\s Multiple repositories: If you have multiple checkout steps in your job, your source code is checked out into directories named after the repositories as a subfolder of s. Ex: C:\agent\_work\1\s\MyRepo

Condition

# scope: stage, job, task condition: eq(variables.Var1, 'Value1') # parameter condition: eq('${{ parameters.Param1 }}', 'Value1') # or condition: or(eq(variables.Var1, 'Value1'), ne(variables.Var2, 'Value2')) # in condition: in(variables['Build.Reason'], 'IndividualCI', 'BatchedCI')

Template

Insert a template

Reuse stages, jobs ans tasks.

stages-template.yml

stages: - stage: Stage1 jobs: - job: Job1 steps: - script: echo 'stages template'

jobs-template.yml

jobs: - job: Job1 steps: - script: echo 'jobs template'

tasks-template.yml

steps: - script: echo 'tasks template'

my-pipeline.yml

stages: - template: stages-template.yml - stage: Stage2 jobs: - template: jobs-template.yml - stage: Stage3 jobs: - job: ExcecuteTasks steps: - template: tasks-template.yml

Extend from a template

Copy the template in the pipeline.

my-template.yml

resources: repositories: - repository: MyRepo type: git name: MyProject/MyRepo steps: - script: echo "My template"

my-pipepline.yml

extends: template: my-template.yml

Parameters

my-template.yml

parameters: parameterName: 'parameter value' steps: - script: echo ${{ parameters.parameterName}}

my-pipepline.yml

extends: template: my-template.yml parameters: parameterName: 'other value'

Condition on a template

It is not possible to set a condition on a template.

Solution 1: pass a parameter to the template.

steps-template.yml

parameters: enabled: true steps: - script: echo 'Task 1' condition: ${{ parameters.enabled }}

my-pipepline.yml

steps: - template: steps-template.yml parameters: enabled: false

Solution 2: use if.

my-pipepline.yml

steps: - ${{ if eq($(MyVar), 'value') }}: - template: steps-template.yml