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
Monday | Tuesday | Wednesday | Thursday | Friday |
|
---|---|---|---|---|---|
| Final Day of Sprint A | Sprint Review and Planning First Day of Sprint B | Sprint A code deploy to Production |
|
|
|
|
| Craft CMS team will merge to Staging in AM and complete verification First Staging deploy of Sprint B EOD, once Craft code is merged through. |
|
|
| Final Day of Sprint B Second Staging deploy of Sprint B | Sprint Review and Planning First Day of Sprint C | Sprint B code deploy to Production |
|
|
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
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
, theproduction
branch will need to be deployed up to the Demo Environment
QA Environment
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
Code is deployed here upon a merge to
staging
via a manually triggered pipeline in BitbucketWe 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