WeCount website release steps

Owned by Gregor Moss
Last updated: Dec 06, 2021
2 min read

This page lays out the steps to follow for each release of the WeCount website. These steps were originally from the 2.7.0 release during a WeCount Tech Check-in meeting on July 15th, 2021, and have been modified to suit releases more generally.

  1. Pre-release testing
    1. Merge latest main into dev, then push back up to remote dev
      1. Commits made by actions-user are GHA, i.e. the branch config CI job, may cause merge conflicts
      2. Get dev site
    2. Test all UIO settings in multiple environments and combinations
    3. Go through every page to make sure all of them are working
    4. Run static pages through an HTML validator, usually W3C
      1. Initiatives page (previously Views) is a dynamic page and is not expected to validate properly
      2. News items link to external resources, so those links don’t need to be validated, but the News page itself does.
    5. A11y validation
      1. Lighthouse PR: https://github.com/inclusive-design/wecount.inclusivedesign.ca/pull/293
        1. When the accessibility score is not 100%, go through the report and investigate the reported issues
        2. To run this:
          1. The PR contains a list of URLs to test, it will only run through those pages
          2. There are two files with URL lists: lighthouse-desktop.yml and lighthouse-mobile.yml, both need to be updated
          3. Changes from the content restructuring will have broken the old list, so that needs to be updated
          4. Get the list of pages from Netlify CMS
          5. The URLs are mostly the same, the only change this time is to remove the “Team” page since it was never migrated to Netlify CMS
          6. Commits should be made to the “lighthouse-ci” branch
          7. Issue 267 captures this PR, the branch is named after this
          8. Merge in the latest dev branch before committing to lighthouse branch
          9. After committing locally, push into jobara’s branch by running for example `git push jobara lighthouse-ci:issue-267`. All collaborators should have write access into that branch
          10. The push will trigger CI tasks in the PR to run and will report the issues
        3. The old URL list pointed to Views page 11, which doesn’t exist on the prod site (there used to be many more test articles before the Netlify CMS migration)
      2. WAVE Evaluation Tool: make sure the things it reports are reasonable
        1. Some a11y issues will be content issues rather than code issues
  2. Release
    1. Check what is in dev and not in main, and what is in main but not in dev
      1. git log main ^dev, git log main ^dev
    2. Push directly to main
      1. git push upstream dev:main (pushes local dev into remote upstream main)
    3. Wait until “update CMS branch configuration” action completes
    4. Test the production site to make sure the changes are deployed
    5. Tag the branch
      1. Checkout local upstream main
      2. Pull upstream main to get updates
      3. .github/CONTRIBUTING.md has release script commands, one for each level of release (MAJOR, MINOR and PATCH)
      4. npm run release:<LEVEL>
        1. The “Pushing everything to remote” task could fail, that’s okay
      5. Push upstream main
      6. Note the commit hash for the version bump
      7. Go to Releases, click “Draft a new release”, give it the new ver. number
      8. Write release notes following Conventional Commits format
      9. Publish
      10. Email the WeCount list to notify them of the new release