« Azure pipeline » : différence entre les versions

De Banane Atomic
Aller à la navigationAller à la recherche
Ligne 138 : Ligne 138 :
     type: git  
     type: git  
     ref: master
     ref: master
</kode>
== [https://docs.microsoft.com/en-us/azure/devops/pipelines/process/conditions?view=azure-devops&tabs=yaml Condition] ==
<kode lang='yaml'>
stages:
- stage: Stage1
  condition: eq('${{ parameters.destination_environment }}', 'CI')
  jobs:
    - job:
      steps:
      - powershell: 'cmd'
        condition: eq('${{ parameters.Param1 }}', 'Value1')
</kode>
</kode>



Version du 2 juillet 2020 à 15:45

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

Links

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
    variables:
      MyVar: 'CI'
    # 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:
    - bash: echo "We are on CI"
    - pwsh: |
        Write-Host "We are on CI"
    - task: PowerShell@2
      displayName: 'PowerShell Script'
      inputs:
        targetType: filePath
        filePath: './$(System.DefaultWorkingDirectory)/Folder/Script.ps1'
        arguments: '-Arg1 "$(MyVar)"'
      # disable the task
      enabled: false

- stage: DEMO
  displayName: DEMO stage
  dependsOn: []
  jobs:
  # use deployment job with environment and strategy to use the approval mechanism
  - deployment: demo_job
    environment: DEMO
    variables:
      MyVar: 'DEMO'
    strategy:
      runOnce:
        deploy:
          steps: ${{ parameters.myStepList }}

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'

# 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

Yaml.svg
resources:
  repositories: 
  - repository: RepoId  # A-Z, a-z, 0-9, and underscore
    name: RepoName  # repository name (format depends on `type`)
    type: git 
    ref: master

Condition

Yaml.svg
stages:
- stage: Stage1
  condition: eq('${{ parameters.destination_environment }}', 'CI')
  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