-
Notifications
You must be signed in to change notification settings - Fork 2
Deployment
When anticipating the delivery of a new Lab teams must follow the guidelines to follow the auto-deploy features to ensure successful delivery to the public-facing site.
- Feature branches must be merged via a pull request to the dev branch.
- Must be reviewed by Two senior members or 2 Junior developers and 1 Senior developer
- Build must pass for the current JS version
- After this monitor the staging deployment and ensure that it is deployed
- Set the lab to active in the database if the lab does not appear on the home page.
- Review changes and test Lab on Staging URL and direct it to outreach and other teams to provide testing feedback
- Then create a new Pull Request to for final review and after approval deployment will start.
Well, it just does. period. I'm kidding, the two stages of the deployment pipeline take place in two similar actions. These GitHub actions allow for the automatic deployment to the production and staging server after the merge happens to either the dev or prod branches receive a merge commit. This will limit the need for a developer to sign on to the production server or staging server and perform the actions. The steps of the deployment process across the two are both the same, except they are directed to two separate servers with different addresses. This is crucial as it allows the team to see their changes on the dev branch in a production clone environment.
The two actions deployment files are
- Production-Deployment deploy.yaml
- Staging-Deployment staging-deploy.yaml
Developers should be able to handle how to fix if there is a deployment issue.
- Restart and re-run the action to see where the pipeline has errored out or crashed
- If it fails again try reverting the commit and redeploy.