« Azure pipeline » : différence entre les versions
De Banane Atomic
Aller à la navigationAller à la recherche
Ligne 115 : | Ligne 115 : | ||
== [https://docs.microsoft.com/en-us/azure/devops/pipelines/process/runtime-parameters?view=azure-devops&tabs=script Runtime parameters] == | == [https://docs.microsoft.com/en-us/azure/devops/pipelines/process/runtime-parameters?view=azure-devops&tabs=script Runtime parameters] == | ||
Ces paramètres sont sélectionnable à chaque lancement de la pipeline. | |||
<kode lang='yaml'> | <kode lang='yaml'> | ||
parameters: | parameters: |
Version du 2 juillet 2020 à 15:03
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 |
Release variables
YAML
Links
- YAML schema reference
- Specify jobs in your pipeline
- Template types & usage
- Approvals in environments with multi-stage YAML pipelines
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 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
- 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
# scope: root, job variables: variable_name: 'value' |
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
resources: repositories: - repository: RepoId # A-Z, a-z, 0-9, and underscore name: RepoName # repository name (format depends on `type`) type: git ref: master |
Steps of a release
- Build the software with a pipeline
- validate product quality (unit tests, SonarCloud)
- Deploy the software
- validate runtime stability (compare telemetry with previous version)
- Release the feature
- validate feature usage