Release pipelines (legacy)
- GUI only
- It’s legacy and will be replaced by multi-stage pipelines.
- A release pipeline consists of different stages per environment e.g. QA / Staging / Production
- You can:
- Edit a particular release only (not entire pipeline)
- Specify retention period for the releases
- How many days + minimum number of releases
- Global release retention policy
- For on-premises Team Foundation Server
- ❗ In Azure Pipelines, you can view but not change these settings for your project.
- Maximum retention policy sets the upper limit for how long releases can be retained for all release pipelines
- Default retention policy sets the default retention values for all the release pipelines
- Destruction policy helps you keep the releases for a certain period of time after they are deleted
- Minimum number of releases to retain for each pipeline
Deployment pools & groups
- Deployment pools are environments in a release pipeline.
- exists at the account level & contains agents (targets)
- can be shared in different projects
- Permissions
- Reader: can view
- Creator: can view & creator
- User: can view & use but cannot manage or create
- Administrator: Can administer roles, manage, view and use deployment groups
- Deployment groups
- Layer over pools which makes these targets available to release definitions in a project
- e.g. “Dev”, “Test”, “UAT”, and “Production”.
- Project-scoped: Exists in a single project
- Permissions:
- Reader: Can only view deployment pools.
- Service account: Can view agents, create sessions, and listen for jobs from the agent pool.
- User: Can view and use the deployment pool for creating deployment groups.
- Administrator: Can administer, manage, view and use deployment pools.
- You can deploy gradually to ensure application is available to the customers at all time:
- Configure Maximum number of targets in parallel
Gates
- Not yet available for multi-stage pipelines, see GitHub issue
- Collect information from external services
- then decide if a stage should run or not.
- Use-cases:
- Incident and issues management, e.g. :
- Ensure deployment occurs only if no priority zero bugs exist
- Validate that there are no active incidents takes place after deployment
- Seek approvals outside Azure Pipelines, e.g.:
- Notify legal approval departments, auditors, or IT managers about a deployment by integrating with approval collaboration systems such as Microsoft Teams or Slack
- Quality validation, e.g. :
- Allow release only if code coverage >= 90
- Security scan on artifacts, e.g.:
- Anti-virus checking, code signing, and policy checking..
- User experience relative to baseline, e.g.:
- Ensure the user experience hasn’t regressed from the baseline state
- Change management, e.g.:
- Wait for change management procedures in ServiceNow before deployment
- Infrastructure health e.g.
- Execute monitoring and validate the infrastructure against compliance rules after deployment
- Gate can be:
- An Azure function that returns success or fail
- Based on Azure Monitor alerts
- Invoking an external REST APi to check success or fail
- Query work items in Azure boards
- ❗ Queries must be in “Shared Queries” folder.
- Query compliance from within Azure Policies
- You can have multiple gateways between stages.
- Pre-deployment gates: runs before the deployment stage
- Post-deployment gates: runs after the deployment stage
- Can have delay before evaluation
- E.g. wait for application reach a steady operational state before running penetration tests
- Can have evaluation options that applies to all gates:
- timeout after which gates fail
- time between re-evaluation of gates: sampling interval
- minimum duration for steady results after a successful gates evaluation