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 02/20/2025)

• bump Moped editor package.json version

• schedule release party

• update QA script as needed

• advise users of downtime using template

• merge open PRs

• propose + vote on release names

• cut release branch

• do 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

  • Column additions require rebuilding the connection so dataflow knows about new column but won't break the dataflow; removing columns that the dataflow expects will break the dataflow

  • Do full replace of AGOL dataset if needed

• snap database in RDS

• graphql-engine version bumps (releases & tags)

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

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

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

  • deploy task definition for staging (TD )

  • deploy task definition for production (TD )

• merge RC to prod

• let users know maintenance is over using template

• create issue for next 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

• Update database view documentation sheet if needed

• 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.

• Did this list checklist change? If so, update documentation