The following are some 'good' patterns within Azure DevOps to allow visibility within Build and Release pipeline. They are not a replacement for symver but could easily be incorporated to increase visibility.
The defaults for AzureDevOps for naming only refer to the Build number without a context - this makes traceability difficult if you wish to use any of the built in reporting.
Modify the Build template in the Options tab:
Change the 'Build number format' to give a context for the build, e.g.
$(TeamProject)_$(BuildDefinitionName)_$(SourceBranchName)_$(Date:yyyyMMdd)$(Rev:.r)
This example will create a build number that contains the following:
- Azure DevOps Team project name
- Build definition name
- Source repository
- Branch of repository
- Build Date
- Instance of builds that day
If you intend to use git tagging to indicate a successful build then apply the following to the build definition.
On the 'Get Sources' option of the build the 'Tag Format' to be:
$(Build.BuildNumber)
This will then use the same build number in the git tagging.
Note: Do not use spaces in the build definition names as Git Tagging does not support this and the associated error messages are not easy to decipher.
To allow visibility of the build numbering within the release pipeline, then add the following to the Options tab of the Release Definition:
Release $(Rev:rrr) for build $(Build.BuildNumber)
This example will create a release number that contains the following:
- Release revision
- Build number of primary artefact
By using the 'Deployment Status' Widget in a Dashboard it is possible to list the releases by environment and their current status.
To configure the 'Deployment Status' widget to show the status of each environment apply the following settings:
| Field | Configuration |
|---|---|
| Build Pipeline | < build definition> |
| Branch | Default branch in build pipeline |
| Linked release pipelines | Release definition and environments that use < build definition> |
| Last Column | Latest deployed |