Version control systems
When code is pushed to the VCS, a default trigger is kicked which can be hooked to build and deploy the application and the monitor build's and deployment's results.
Resources
Resources are entities that are consumed anywhere in a pipeline but live outside of the pipeline.
Such resources include
| Agent pools | Used to build or deploy software |
| Variable groups | A variable groups stores named values («variables»). These values are available across multiple pipelines. Variable groups are managed in the Library page under Pipelines |
| Secure files | Stores (encrypted) files such as signing certificates, Apple provisioning profiles, Android keystore files, SSH keys (etc.?) without having to commit then into the source code repository. The content of a secure file is only available during the build or release pipeline by referencing them from a task. |
| Service connections | allows to connect to external and remote services that are used to execute tasks in a job |
| Environments | An application is deployed to an environment (such as Kubernetes clusters, virtual machines, web apps etc.). Typical names for environments include: Dev, Test, QA, Staging and Production |
| Repositories | accesses templates in another repository |
| Artifacts | such as Azure Pipelines or Jenkins |
| Pipelines (huh, is this recursive?) | |
| Containers | For example: Docker hub or Azure Container Registry |
The owner of a resource can define a check that must be satisfied before the pipeline (or more accurately: the stage) can consume the resource. If this check is not satisfied, the stage won't run.
Defining pipelines
A pipeline is either defined with
- YAML (
azure-pipeline.yml), or
- user interface (referred to as «classic»)
A definition of a pipeline is versioned along with the code. Thus, even code branches can have their own pipeline definition.
Typically, there are at least the following two pipeline (types?):
- A build pipeline, that builds and tests the code and publishes artifacts, and
- a release pipeline which consumes and deploys those artifacts to the deployment targets.
Stages
A pipeline consists of one or more stages.
A stage consists of one or more jobs.
Stages organize jobs in a pipeline.
By default, stages run in a sequence.
Approval checks allow to manually control if the next stage should run.
Typical examples of stages are
- build the application
- run test suite xyz
- deploy to UAT
Jobs
A job is a unit of work which is assignable to the same machine.
A job is either agentless or is executed on an agent.
Steps
A step is the smallest building block of a pipeline.
A step runs in its own
process on an agent.
A step has access to the pipeline workspace on the local hard drive.
A step is either
- a script, a
- a task (which is essentially a prepackaged script), or a
- reference to an external template
Running pipelines (triggers)
A pipeline is executed when a trigger causes it to do so.