« Azure pipeline » : différence entre les versions

De Banane Atomic
Aller à la navigationAller à la recherche
Ligne 234 : Ligne 234 :
== [https://docs.microsoft.com/en-us/azure/devops/pipelines/process/templates?view=azure-devops Template] ==
== [https://docs.microsoft.com/en-us/azure/devops/pipelines/process/templates?view=azure-devops Template] ==
=== [https://docs.microsoft.com/en-us/azure/devops/pipelines/process/templates?view=azure-devops#insert-a-template Insert a template] ===
=== [https://docs.microsoft.com/en-us/azure/devops/pipelines/process/templates?view=azure-devops#insert-a-template Insert a template] ===
Reuse stages, jobs ans tasks.
<filebox fn='stages-template.yml'>
<filebox fn='stages-template.yml'>
stages:
stages:

Version du 13 août 2020 à 19:07

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

  • Pipelines → New pipeline
  • Azure Repo Git YAML → Select your repo → Existing Azure pipelines 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

stage

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

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 ]

Pool

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

Step / task

Yaml.svg
steps:

# 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

# task
- task: VSBuild@1
  displayName: Build
  timeoutInMinutes: 120
  inputs:
    solution: '**\*.sln'

PowerShell step and task

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

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

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'

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