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 version

  • Create an issue for the next release

  • Send the release notes to all Moped users

Example Release Issue

PreviousLocal testingNextPatch release process

Last updated

Was this helpful?