Nurse Job Board Release Process

UNDER CONSTRUCTION

TODO:

• Automated Tests as part of pipeline deployments

  • Likely need some FE infra/deployment adjustments with ECM’s help

• Hot Fix/Release Candidates definitions and process

The purpose of this document is to define the release process for the Super Nurse project (Java Springboot backend and/or Craft/Vue frontend).

Release Cadence

• Prior to releasing Production we will copy the code from production branch to the demo branch – This ensures reliability of the demo environment because all code on demo will have existed on Production for 2 weeks.

• We will release to Production bi-weekly.

  • Code will deploy the first Thursday of a sprint, after Sprint Review is completed Wednesday morning.

• Staging will be deployed twice during the release: The second Thursday of a sprint, and the second Tuesday of a sprint.

  • There will need to be clear communication/reminders that NO NEW WORK should be merged into QA that cannot be fully tested prior to these deployments to Staging.

• Code freeze to Staging after 5PM on Wednesday (in preparation for Thursday releases)

• Magento dependency

  • If there is no dependency on Magento for this release (i.e. if they don’t have to go out at the same time), then the Super Nurse release can be during business hours.

  • If there is a dependency on Magento and they need to be released at the same time, then the release will need to be at 9PM due to downtime requirements for Magento.

Environment Definitions and Uses:

• Demo Environment

  • https://demo-www.nurse.com/jobs/

  • Code is deployed here upon a merge to demo

  • The Sales team will use this environment to client demos and thus needs to be extremely stable

  • Demo will be one sprint cycle behind production to ensure stability for sales demo

    • As part of each release, before code is deployed to production, the production branch will need to be deployed up to the Demo Environment

• QA Environment

  • https://qa-www.nurse.com/jobs/

  • Code is deployed here upon a merge to integration

  • The QA team will manually test tickets as part of the sprint within this environment

  • Once a ticket is passed by the QA team here, it is moved to “Development Done” on the sprint board.

• Staging Environment

  • https://stage-www.nurse.com/jobs/

  • Code is deployed here upon a merge to staging via a manually triggered pipeline in Bitbucket

  • We will deploy to this environment the second Thursday and second Tuesday of each sprint

  • The PM team will manually review tickets in this environment

  • Once a ticket is successfully PM reviewed, it is “Queued for Release” to Production

Foundations of a Successful Release:

• Roles and responsibilities

  • Release owner – Engineering Manager who is responsible for

    • Creation and ownership of the release’s CHM ticket

    • Coordinating with the QA and PM teams for Staging Verification, Product Review, and readiness for Production release

    • Communicating in #sprint-releases and #nextrelease when a release begins and is marked as complete

    • Communicating as needed in any alerts channels if downtime alerts are triggered

  • Code owner – Software Engineer who is responsible for

    • Creating the git tag to mark code planned to be released

    • Code deployments to Staging

    • Working with ECM to deploy code to Production

  • Product Manager who is responsible for

    • Communications around the release to internal and external stakeholders as appropriate

    • Selection of tickets to be released

    • Scheduling release calls

    • Determining response to bugs found in Staging Verification/Product Review as needed

    • Completing Product Review in Staging prior to Production release

  • A QA engineer who is responsible for

    • Ensuring each ticket is functionally tested as part of the sprint in the QA environment

    • Communicating any concerns related to releasing to production uncovered in sprint testing or upper level regression

    • Selecting high-risk tickets to be functionally tested in Production

    • Running and communicating results of automated tests