Azure - Pipeline - Template
In Azure DevOps, a CI/CD (Continuous Integration/Continuous Deployment) pipeline is organized into the following hierarchical structure:
Stages:
- A stage is a major division within a pipeline that represents a logical phase or environment in your CI/CD process.
- Each stage typically corresponds to a major step in your software delivery process, such as building, testing, deploying to a staging environment, and deploying to production.
- Stages are executed sequentially by default, and each stage can have its own jobs.
Jobs:
- A job is a unit of work within a stage and represents a set of tasks that need to be executed on the same agent (or group of agents).
- Jobs within a stage can run in parallel to optimize pipeline execution.
- Jobs can depend on the success or failure of other jobs in the same or previous stages.
Tasks:
- A task is the smallest unit of work within a job and represents a single action or command to be executed.
- Tasks can include actions like building code, running tests, deploying applications, or performing other automated actions.
- Each task has specific inputs and can run on a designated agent or group of agents.
Here's an example of how these components fit together in an Azure DevOps pipeline:
trigger:
- '*'
pr:
- '*'
stages:
- stage: Build
jobs:
- job: BuildJob
steps:
- task: UsePythonVersion@0
inputs:
versionSpec: '3.x'
- script: echo "Building the application"
displayName: 'Build Step'
- stage: Test
jobs:
- job: UnitTests
steps:
- script: echo "Running unit tests"
displayName: 'Unit Test Step'
- stage: Deploy
jobs:
- job: DeployToStaging
steps:
- script: echo "Deploying to staging environment"
displayName: 'Deploy to Staging Step'
- job: DeployToProduction
dependsOn: DeployToStaging
steps:
- script: echo "Deploying to production environment"
displayName: 'Deploy to Production Step'
explain these two
trigger:
- '*'
pr:
- '*'
The trigger and pr sections in an Azure DevOps pipeline YAML file define when the pipeline should be triggered and under what conditions it should run.
trigger Section:
- The
triggersection specifies the events or conditions that should trigger the pipeline to run. - In the example you provided:
trigger:
- '*' - The
triggersection has a single event specified using the*(asterisk) wildcard. - The
*wildcard means that the pipeline should be triggered for any type of event. This includes events like code commits, branch updates, pull requests, etc. - Essentially, this configuration instructs the pipeline to run whenever there is any change or event in the repository it is associated with.
In summary, these sections define when the pipeline should automatically run:
- The
triggersection specifies the conditions for regular code changes and events in the repository, such as commits to branches. - The
prsection specifies the conditions for running the pipeline when pull requests are created, updated, or have changes made to them.
The use of the * wildcard means that the pipeline will respond to all events of the specified type, ensuring it stays up to date with changes in the repository or pull requests. Depending on your requirements, you can customize these sections to trigger the pipeline based on specific branches, tags, or other criteria
SEARCHING :

Comments
Post a Comment