Releasing changes to production

We aim to release changes to the live site (https://revenuedata.doi.gov/) regularly. This generally follows a pretty simple process:

Decide to release

We often decide to release at the end of a sprint, when a new feature is ready to go live, or when a bug has been fixed. Before starting the release process, make sure any pull requests that should be part of the release are merged.

Release to staging

1. Change the version number in _config.yml
2. Open a PR from dev to staging
3. Review changes, commits, and the preview to make sure everything looks as expected
4. Fill in the PR description with a list of changes (with links to each of the issues the changes address)
5. Once all looks well, merge!

Review the site on staging

Sometimes this review happens concurrently with the prior and/or following steps.

Use the Federalist preview link for the staging branch to carefully review the site and make sure only the expected things have changed.

• It can be helpful to have the live site open in another window for visual regression testing.
• Check different layouts and interactions, including the homepage, explore data pages, and a range of other templates.
• Make sure data is still present and unchanged (or changed only in expected ways).

Release to the live site

1. Open a pull request from staging to master
2. Copy your list of changes and issues from the PR to staging
3. Do a final review of changes, commits, and the Federalist preview to make sure everything still looks as expected
4. Draft a release, drawing heavily from your list of changes/issues
5. Merge to master
6. Publish your release
7. Make sure Federalist successfully built the site and verify that the changes are live as expected (can take 5-10 minutes)

Celebrate!