Azure pipeline

De Banane Atomic
Aller à la navigationAller à la recherche

Links

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

Release variables

YAML

Create a new pipeline

From an existing YAML file

Exemple

Yaml.svg
# 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 }}

YAML schema reference

Job

Yaml.svg
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
  condition: # ...

  # what to clean up before the job runs
  workspace:
    clean: outputs | resources | all

  steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]

PowerShell task

Yaml.svg
- 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'

- 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'

Variables

Yaml.svg
# scope: root, stage, job
variables:
  variable_name: 'value'

Runtime parameters

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

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

Repositories

By default current pipeline repo is checked out.
Yaml.svg
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

Yaml.svg
stages:
- stage: Stage1
  condition: eq(variables.Var1, 'Value1')
  jobs:
    - job:
      steps:
      - powershell: 'cmd'
        condition: eq('${{ parameters.Param1 }}', 'Value1')

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