Release process

Follow these steps to release Moped. You can also review our past release issues or see below, which can be used as a template for each release. These can be split up amongst members of the team.

Schedule a recurring "release party" for product management + devs to deploy the release to Production "live" as a group.

• Advise users of downtime. If downtime is expected, let users know ahead of time that Moped will be unavailable. There is currently no mechanism to prevent users from using the system during a release window. You just have to ask nicely that people don't use Moped. :/

• Merge open pull requests into the main branch

• Propose + vote on release names (in Slack)

• Cut the release candidate branch from main

• Add/update tests to a new sheet in the Moped QA Testing spreadsheet and perform QA testing

• Polish the release notes

• Let users know maintenance is starting

• Create a DB snapshot in AWS RDS (just to be safe)

• Apply any Hasura GraphQL Engine version bumps, as needed, to the ECS Fargate deployments. We endeavor to keep production at the second-most-recent minor version, with staging and local dev on the most current minor version of Hasura that's avaialble

• Merge the release candidate to prod

• Bump the Moped editor package.json version to the next minor versin

• Create an issue for the next release

• Send the release notes to all Moped users

Current Release Template (updated 12/11/2024)

• bump Moped editor package.json

• schedule release party

• update QA script as needed

• advise users of downtime using template

• merge open PRs

• propose + vote on release names using current theme

• cut release branch

• do QA testing

• polish release notes

• schedule email to let users know maintenance is starting

• Did we add or remove columns from DB views that the Power BI dataflow depends on?

  • Let the Data Science team know

  • Do full replace of AGOL dataset if needed

• snap database in RDS

• graphql-engine version bumps (releases & tags)

  • cross-check docker hub & graphql-engine releases; confirm image is available

  • update local dev docker compose to latest graphql-engine (Note version)

  • update staging task definition to latest graphql-engine release (Note version)

  • update production task definition to previous staging release version + any patches (Note version)

  • deploy task definition for staging (Note task definition version)

  • deploy task definition for production (Note task definition version)

  • deregister old task definitions

• merge RC to prod

• let users know maintenance is over using template

• create issue for vx.x.x release

• update feature list with any new major features

• send release notes to MUG using template (including reminder to refresh the page)

• update staff accounts if there are any bounced emails

• Check Postgres version with the goal of staying one major version behind what is available through RDS. If we need to upgrade, create an issue.