Releasing changes to production

We aim to release changes to the live site once a sprint, with rare ad hoc releases as necessary. This generally follows a pretty simple process.

Regular releases

For our regular releases, we follow this process:

1. Before starting the release process, make sure any PRs that should be part of the release are merged into dev.
2. Create a branch for release-releated changes by updating the version in the gatsby-config.js file and updating the what's new section in the WhatsNew.js file. Refer to the current version and the Semantic Versioning Site to determine which version number to use. Here are some examples from our site that relate to the semantic versioning:
   • A bug with icon presentation in IE 11 would be a patch.
   • A routine data update would be a minor version.
   • Re-branding the website from USEITI to NRRD was a major version.
3. Open a PR with the release changes branch and assign a team member to review it. Once it has been reviewed, merge this PR to dev.
4. Open a PR from dev to master(usually done by the product manager or someone acting in that role).

5. Fill in the PR description with a list of major changes in that release as well as a preview link.

6. Draft a new release, drawing heavily from your list of changes/issues in your release PR.
   • Fill in the box for tag version with a “v” and your release number (no spaces).
   • Select master for the target branch. This is the branch where the release will be published.
   • Fill in the version number (with a “v”) and the date for the release title.
   • Save the release as a draft.

7. Use the Federalist preview link for the dev 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).

8. Based on their knowledge and skill sets, assign at least two other team members to review the PR.

9. The assigned team members should review changes, commits, and the preview to make sure everything looks as expected.

10. Once the assigned team members have reviewed and approved the PR, the product manager – or the team member acting in that capacity – will review and merge the PRs to the live site.

11. Publish the draft GitHub release that you set up in step 5.

12. Make sure Federalist successfully built the site and verify that the changes are live as expected (can take 5-10 minutes).

Celebrate!

Ad Hoc or Emergency Releases

Occasionally, we may have a situation, such as an urgent bug fix or data update, that necessitates an ad hoc release. If we have an urgent PR that needs to be released directly into production without going through the process of reviewing and merging all commits in dev, the product manager or a person acting in that capacity will decide to do an ad hoc release. In this case, we will follow the procedures for a release, with these key changes:

1. Change the version number in gatsby-config.js and use the branch that needs to be released for this change.
2. Set the PR up to go from your current branch directly into master.
3. Use the Federalist preview link for your branch to carefully review the site and make sure only the expected things have changed.
4. Assign at least two other team members to review the PR:
   • Code-related changes must have the developer and/or content strategist review them.
   • Content-related changes must have the content strategist, product manager, or program analysts review them.
   • PRs related to new designs must have the user experience designer review them (although these PRs probably will not be urgent and should just go through the normal release process).
   • Visual design-related PRs must have the content strategist or user experience designer review them.

Appendix: things to check while reviewing changes

For all of the things below, compare against the live site, looking for NEW issues or bugs introduced with the in-review PR. If you notice additional bugs that are shared between the live site and new PR, those don't need to be resolved before merging — open a new GitHub issue to describe the issue, and prioritize it for future sprints.

Navigate between pages

• Check several types of location profile page to ensure data and liquid templates are working as expected
• Check links are working correctly
• Check drop downs menu and validate they work

Text

• No misspelling
• Correct spacing
• Correct format
• Accurate dates displayed

Maps

• Appears on the page
• Shaded correctly
• Hover behavior works
• county/offshore area maps: hover behavior and do detail tables open

Data Detailed instructions (limited access)

• Review 1 verified 5-10 sample lines of data--against source data and relevant charts (Assigned commodities)
• Review 2 verified 5-10 sample lines of data--against source data and relevant charts (Assigned commodities)

Bar Charts

• Hover behavior is working
• Data displayed is correct
• Chart changes if you select yearly or monthly

Check all browsers

• Chrome
• Internet Explorer
• Safari
• Firefox
• Edge

Check all devices

• Dell Laptop
• Chromebook
• Macbook
• iPad
• iPhones
• Samsung phones

Check all responsive breakpoints

• < 480 px (switches to one-column layout)
• 600 px (changes bar chart layout from three column to accordion with one column)
• 768 px (converts side navigation from separate column to the right to a select list)
• > 768 (full site layout)

Updating Data files

Use the following checklist to check features on the website when updating data files.

Production Monthly (monthly_production)

• Homepage: monthly bar charts
• Homepage: CY bar charts
• Homepage: FY bar charts
• Download: xls and csv files updated with correct dates and file size

Production Calendar Year (calendar_year_production)

• State pages ( check a state with a lot of production ex: WY or NM, one with a lot of withelds ex: WY or UT, and one with no production ex: Maine): commodities bar charts and by county maps & table
• Offshore pages: commodities bar charts and by offshore area maps & table
• Explore data: Federal bar charts trends by resources
• Download: xls and csv files updated with correct dates and file size

Production Fiscal Year (fiscal_year_production)

• Download: xls and csv files updated with correct dates and file size
• Explore data: Filterable production data table

Revenue Monthly (monthly_revenue)

• Homepage: revenue trends charts
• Homepage: CY bar charts
• Homepage: FY bar charts
• Homepage: monthly bar charts
• Download: xls and csv files updated with correct dates and file size

Revenue Calendar Year (calendar_year_revenue)

• Explore data: Revenue detail by phase
• Explore data: bar charts revenue trends by resource
• State pages: revenue detail by phase
• State pages: commodities bar charts and by county maps & table
• Offshore pages: commodities bar charts and by offshore area map & table
• Download: xls and csv files updated with correct dates and file size

Revenue Fiscal Year (fiscal_year_revenue)

• How it works: Native American revenue table
• Explore data: Filterable revenue data table
• Download: xls and csv files updated with correct dates and file size

Federal Revenue by Company (federal_revenue_by_company_CY2013-CY2018)

• Federal revenue by company: total revenue by type & company data
• Download: xls and csv files updated with correct dates and file size

Disbursements Monthly (monthly_disbursements)

• Homepage: disbursements trends current year comparison
• Download: xls and csv files updated with correct dates and file size

Disbursements Fiscal Year (disbursements)

• Homepage: FY bar chart
• Homepage: disbursements trends sparkline
• Explore data: by recipient table
• State pages disbursements
• Download: xls and csv files updated with correct dates and file size"
• Explore data: Filterable disbursements data table