Release Tickets & V&V

Every production change needs a paper trail. The PO prepares the information; the Release Manager (RM) submits the NGD tickets.

This applies to automated deployments too. Auto-deploy changes who pushes the button and when the ticket is submitted — it does not remove the ticket requirement. See Automated Production Deployments.

Preparing for the V&V Report (DHSS)

For DHSS projects, before a release goes out to production, the V&V report needs to be done and approved. The RM submits the V&V report as part of submitting the NGD tickets, but the PO also needs to make sure certain things are updated so the report will be correct. The PO should work with the PM to have the correct fix version on all tickets in the upcoming release.

The V&V report is generated from the vv.yaml file, this file is updated during the build and uses vv.properties. These properties need to be kept up to date with each release:

  • versionInProduction: The current version in production

  • productionReleaseType: major, minor, or patch

  • oisCodeReviewLink: The Jira ticket for the OIS Code Review

  • vamfatId: The Jira ticket for the VAMFAT review

  • targetAudience: A string describing the audience for the service (e.g.: Veteran, Staff, Admin, Other (System to System))

Creating Release Tickets

While the Platform team handles all deploys, vault, route and database updates for SQA and Production, and the Release Manager (RM) submits all the appropriate NGD tickets to make this happen, the PO is responsible for preparing the information and handing it off to the RM to be scheduled with the platform (CCP) team.

Ryan Britt has created Jira automation to make creating the PO release tasks for the RM as easy as possible! When you’re ready to use this automation,

  1. Go to a story related to the release in Jira

  2. Click on the “More” dropdown

  3. Scroll down to the bottom and look for the appropriate PO option for what you need to do:

    1. PO: <project> Consul update

    2. PO: <project> DB update

    3. PO: <project> Route update (see Route Updates)

    4. PO: <project> Vault update

    5. PO: <project> Deploy task

      1. The PO: Deploy Task will create a placeholder task with sections for SQA and Production. If this is the first release for a new component you will need to go through the process with SQA first and then Production - setting up Vault, Routes and Database as needed. For regular production updates for an already service, you will only need to fill in the production section and can remove the SQA section.

  4. This will run the automation to create the PO release task for the RM with the appropriate fields / information that they will need to submit the NGD ticket(s).

  5. Fill in the relevant details on the generated task and assign the task to the RM (@Kelley Wilds). This should include the fix version, branch, special instructions, etc.

  6. Create a new post in #releases tagging the RM and including the component name, type of update (vault, deploy version, etc), the git tag being deployed (for deployments, e.g. v1.1.0-conf01) and Jira ticket ID.

    1. Example: @Kelley Wilds ssoi-sts prod deploy version 1.1.0 (tag v1.1.0-conf01) CKM-123

After that the RM will create the NGD ticket(s) needed that will be submitted to the platform team to do the work. The RM will post back on the thread with the NGD ticket information and scheduled date and time (if applicable). Any questions, issues with v&v, etc will be threaded on that post in #releases.

POs should only release a new version to production when all relevant stories for that component are complete and everything is ok in staging. Once a new Release branch is created, it is worth verifying in CAG that it was successfully deployed to staging. It is easy to miss minor Consul/Vault/DB changes that will prevent a deployment in staging so checking it first is necessary.