Skip to content
This repository was archived by the owner on Jun 26, 2018. It is now read-only.

release.md

Latest commit

 

History

History
48 lines (42 loc) · 3.97 KB

release.md

File metadata and controls

48 lines (42 loc) · 3.97 KB

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.

Communicate to the team

  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.

Creating the release

  1. Check out the massgov/mayflower dev branch:
    1. git checkout dev
    2. Pull the latest from upstream git pull <remote> dev.
    3. cd styleguide
  2. Create a release branch
    1. 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.
    2. Add release notes to the top of release notes based on the "changelog.txt" files, remove all the "changelog.txt" files and then commit these changes.
    3. Run npm install in case the release includes new packages.
    4. Update the version of the npm package by editing the version field in the package.json with #.#.# for the release.
    5. Commit your version change from package.json.
    6. Push release branch to massgov/mayflower (i.e. git push <remote> release-#.#.#).

Deployment

  1. Wait for the circle build to pass, which will deploy your release branch to staging automagically :).
  2. Verify release notes against the site rendered at: https://mayflower.digital.mass.gov/b/<your-release-branch>/index.html.
  3. Smoke test Mayflower (a quick way to do this is to browse around to some of the different pages in the "pages" menu and do a quick gut check)
  4. 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.
    2. This is a great time to verify one more time that your release is following semantic versioning properly (i.e. not pushing out breaking changes in a minor release).

Create a tag

  1. Create a production release off the master branch in GitHub:
    1. Tag version: #.#.# (your release number)
    2. @ Target: master <<<<<<- important! :)
    3. Release title: #.#.# (your release number)
    4. Describe the release: paste your release notes markdown here, after the release version/date line, add a link to the release PR (protip: type # and you'll get an autocomplete dropdown to get to your pr)
  2. Wait for the circle builds to pass
  3. Smoke test Prod
    • Make sure the home page reflects the date and version

Post Deployment

  1. Open a GitHub Pull Request to merge master into dev (this should only bring an updated release-notes.md, package.json). If a feature was reverted on the release branch, have a peer do the merge after a review.
  2. 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).
  3. Follow the Communicate Releases instructions for Deployment Completed to email Release Notes to the team.
  4. Celebrate!!