release.md

Release to Production

Mayflower release managers with the necessary repo permissions can follow these steps to deploy code to production (i.e. do a release).

Note: the following steps assume that your local machine and repository is already set up and functioning according to our Getting Started docs.

1. If there is new code to be delivered, notify the team at least two hours ahead of time that a release is coming. Follow the Communicate Releases instructions for Upcoming Deployments.
2. Pull and checkout the massgov/mayflower dev branch: git fetch upstream && git checkout dev.
3. Create a release branch git checkout -b release-#.#.# where #.#.# is the next version (i.e. 5.0.0). Read more about Mayflower and semantic versioning to ensure that your are creating the right type of version..
4. Document the new release based on the "Upcoming" queue at the top of release-notes.md, and then commit.
5. Bump the version in @pages/readme2.json by updating the version and date text in errorPage.type, and then commit.
6. Push release branch to massgov/mayflower (i.e. git push upstream release-#.#.#).
7. Deploy release branch to your personal fork's GH-Pages by running ./scripts/deploy-gh-pages.sh -b <your-release-branch-name> -t <your-github-username> from the repo root.
8. Verify release notes against the site rendered on your GH-Pages: <your-github-username>.github.io/mayflower.
9. Smoke test most Mayflower featureset. (@todo define Mayflower featureset)
10. Open a Github Pull Request to merge (no squash!) the release branch into the master branch.
    1. Add the relevant release notes to the PR notes.
11. Create a production release off the master branch in GitHub, remember to add the release notes!
12. Pull down and checkout the your release tag by running git pull --tags && git checkout <your-release-tag> (Note: you should see a message from git that you are in a detached head state and that is okay.)
13. Deploy release tag to Prod by running ./scripts/deploy-gh-pages.sh -b <your-release-tag> -t massgov -c mayflower.digital.mass.gov from the repo root, where:
    • -b is the build source (required): your git branch or tag name.
    • -t is the target remote repo owner (required): massgov for prod.
    • -c is the custom cname (domain) for Prod (required for prod deployment): mayflower.digital.mass.gov
    1. When prompted, confirm your prod deployment by typing: y
14. Smoke test Prod
    • Make sure the home page reflects the date and version
    • Ensure Mayflower featureset (@todo define) is functional
15. Open a GitHub Pull Request to merge master into develop (this should only bring an updated release-notes.md, @pages/readme2.json). If possible, have a peer do the merge after a quick review. If no peers are available, proceed with your merge into develop, but ask for a review the following day. If it doesn't pass review, you may have to rollback the delivery.
16. In JIRA Go to the DP project.
    1. Click on the Releases icon on the left side (it looks like a boat/ship).
    2. Add a new release version with today's date.
    3. Go to each shipped JIRA issue and update the Fix Version/s field.
    4. Go to the list of issues contained within the release version and copy the URL (link to this issue from release notes).
17. Follow the Communicate Releases instructions for Deployment Completed to email Release Notes to the team.
18. Celebrate!!

Rollback

In the event that a release needs to be rolled back from production, follow these steps:

1. Pull down and checkout the prior release tag and check it out by running git pull --tags && git checkout <prior-release-tag> (Note: you should see a message from git that you are in a detached head state and that is okay.)
2. Deploy release tag to Prod by running ./scripts/deploy-gh-pages.sh -b <prior-release-tag> -t massgov -c mayflower.digital.mass.gov from the repo root
   1. When prompted, confirm your prod deployment by typing: y
3. Validate rollback by browsing to Prod and verifying that the home page reflects the prior version