td devops infrax pipeline
The following document describes the intended implementation CI/CD pipeline.
The following sequence illustrates the stream for a PR from commit to production. It is intended to show the workflow in its entirity assuming validations pass at each stage.
When the pull request validation fails, the pr should be blocked. The contributor should then be notified that the validation failed. The contributor would investigate and push a fix for the validation error. The reviewer should review the fix provided. The pr validation will be repeated. Assuming the validation passes the flow would then continue on as illustrated in the happy path example.
If the automated tests fail upon merging a PR to master, master will now be in a broken state. Any subsequent merges would also fail as a result. Therefore, merges are blocked until master is resolved.
Once the failure occurs, a new defect/bug issue should be created. This issue should be prioritized above all other work as its blocking all other work. Swarm if necessary. The issue once created would repeat the PR workflow illustrated in the happy path sequence above. This would repeate until tests pass in master again. Once tests pass in master, merges from other work can continue
Builds will occur at two stages within the workflow. At each of these stages, a semantic version should be applied to the build to indicate what the build artifacts contain.
The version should follow the semver standard Major, Minor, Patch version. Additionally, builds generated from PR's should have a pre-release modifier to indicate they have not yet been certified for release.
The patch should be the segment incremented by default. This should be incremented +1 of the previous version that was tagged as release on the repo.
For builds triggered by merges into master, the version should follow format [Major].[Minor].[Patch]+[Rev]. Assuming the next major, minor, patch build is 1.0.1 and this is the first build for that number, then the version tagged should be 1.0.1+1. This indicates that the build was triggered from master and is the build of this version.
For builds triggered by pull requests, a pre-release modifier should be attached to the version to indicate the build is not a pre release build.
In the example in the sequences above, the version is [Major].[Minor].[Patch]-pr[PR#].[Rev]. Assuming the next major, minor, and patch build is 1.0.1, the pr number is #3, and this is the first build for the pr, then the version should be 1.0.1-pr0003.1. This will indicates that this build was trigger for PR#3 and is a pre-release version.
The GitVer extension for Azure DevOps pipelines will automate versioning the builds as indicated above. This is being used to apply semantic versioning to builds for this project. The versioning applied can be seen here.
The following yaml demonstrates how the extension applies the version. This should be the first step in the pipeline
steps:
- task: gittools.gitversion.gitversion-task.GitVersion@4
displayName: GitVersion
inputs:
preferBundledVersion: falseThis also makes available build variables that can be referenced from other tasks. Example shows running npm version command with input from GitVer vars.
- task: Npm@1
displayName: version
inputs:
command: custom
workingDir: '$(System.DefaultWorkingDirectory)'
verbose: false
customCommand: 'version $(GitVersion.SemVer) --no-git-tag-version'