Jobs and pipelines - knowlesy/AZ400 GitHub Wiki
Adding multiple jobs to a pipeline lets you:
- Break your pipeline into sections that need different agent pools or self-hosted agents.
- Publish artifacts in one job and consume them in one or more subsequent jobs.
- Build faster by running multiple jobs in parallel.
- Enable conditional execution of tasks.
most pipelines will have these components:
- Name – though often it's skipped (if it's skipped, a date-based name is generated automatically).
- Trigger – more on triggers later, but without an explicit trigger. There's an implicit "trigger on every commit to any path from any branch in this repo."
- Build Azure Repos Git repositories - Azure Pipelines | Microsoft Learn
- Variables – "Inline" variables (more on other types of variables later).
- Job – every pipeline must have at least one job.
- Pool – you configure which pool (queue) the job must run on.
- Checkout – the "checkout: self" tells the job which repository (or repositories if there are multiple checkouts) to check out for this job.
- Steps – the actual tasks that need to be executed: in this case, a "script" task (the script is an alias) that can run inline scripts.
A job has the following attributes besides its name:
- displayName – a friendly name.
- dependsOn - a way to specify dependencies and ordering of multiple jobs.
- condition – a binary expression: if it evaluates to true, the job runs; if false, the job is skipped.
- strategy - used to control how jobs are parallelized.
- continueOnError - to specify if the rest of the pipeline should continue or not if this job fails.
- pool – the name of the pool (queue) to run this job on.
- workspace - managing the source workspace.
- container - for specifying a container image to execute the job later.
- variables – variables scoped to this job.
- steps – the set of steps to execute.
- timeoutInMinutes and cancelTimeoutInMinutes for controlling timeouts.
- services - sidecar services that you can spin up.
Resources let you reference:
- other repositories
- pipelines
- builds (classic builds)
- containers (for container jobs)
- packages
This hierarchy is reflected in the structure of a YAML file like:
• Pipeline
• Stage A
• Job 1
• Step 1.1
• Step 1.2
• ...
• Job 2
• Step 2.1
• Step 2.2
• ...
• Stage B
• ...
A job is a collection of steps run by an agent or on a server. Jobs can run conditionally and might depend on previous jobs.
A stage is a collection of related jobs. By default, stages run sequentially. Each stage starts only after the preceding stage is complete.
Deployment strategies Deployment strategies allow you to use specific techniques to deliver updates when deploying your application.
Techniques examples:
- Enable initialization.
- Deploy the update.
- Route traffic to the updated version.
- Test the updated version after routing traffic.
- If there's a failure, run steps to restore to the last known good version.
runOnce is the most straightforward deployment strategy in all the presented lifecycle hooks.
A rolling deployment replaces instances of the previous version of an application with instances of the new version. It can be configured by specifying the keyword rolling: under the strategy: node.
Using this strategy, you can first roll out the changes to a small subset of servers. The canary deployment strategy is an advanced deployment strategy that helps mitigate the risk of rolling out new versions of applications.
Features Certain pipeline features are only available when using YAML or when defining build or release pipelines with the Classic interface. The following table indicates which features are supported and for which tasks and methods.