Cutting the Release

Cutting a release means tagging the version and creating (or updating) the release branch, which kicks off the SQA build and deployment.

Version Tagging

  • The current process is manual, but by adding enableTagRelease: true to the jenkins.yaml, this can be an automated process now.

  • Automatic tagging only happens on release branch builds if that tag does not already exist

  • Jenkins Shared Library (JSL) now deploys based upon the tag and not what is the latest on the release branch. This means that if you have already deployed a version, and have updates to configuration (Kustomize/K8s files) you will need to manually delete/re-tag that release with a later commit otherwise a redeploy will not pick up the new changes.

Cutting the Release / Deploying to SQA

  • This can be done locally or directly in Bitbucket

  • New Minor Release:

    • Create a new branch named "Release/<major>.<new minor version>" (e.g.: Release/1.5) from the version tag - the naming of the branch is important because Jenkins is configured to look for certain patterns.

  • New Patch Release:

    • Merge the changes in the version tag to the minor branch that the patch updates

  • This process will kick off a build / deployment in SQA

  • Check status in VA PPG Slack (#deploy-staging-sqa and #builds-staging) or by logging into CAG and looking at K8s/SBA

As a PO, you may have one component go through several versions in SQA before making a release to production because the changes weren’t important enough to merit a production release. This can be normal as long as the gap between SQA and Production isn’t too large.

If your component is set up for automated production deployments, manifest.json should not exist on main, so there is nothing to carry over when you cut the release branch. You add it to the release branch later, once the release has passed SQA and you are ready for the production deploy — adding it is what triggers the deployment. See Automated Production Deployments.