Skip to content

Staging Directions

Jump to bottom
Kylee Fields edited this page Dec 18, 2024 · 2 revisions

Staging Directions

Staging For Contributors

The develop branch is our source of truth, not main.

Overall, use our staging site whenever possible. Using the staging site means that your usage/testing doesn’t impact our metrics. E.g. if you signed up for a new account on the live site then we would count that as one more Bumble user who signed up. The staging site usage data is not tracked.

Our staging site works almost exactly like our live website, except for:

  • When you open chat, it will show a fake set of ‘chat team’ members available
  • When you send a chat, no-one will reply
  • We might have also set the chat text to be different on staging, if we are testing options
  • When you go to book a therapy session, you will see fake therapists
  • When you book a therapy session, it won’t actually book a session with anyone

Testing the staging preview is helpful for making front-end design changes:

  1. Creating a pull request will trigger GitHub Actions to automatically run build and linting tasks. A vercel preview url will also be created, to act as a staging environment for this branch
  2. Test the new branch on the vercel preview url, and ensure all new changes working as expected
  3. Request a code review from a staff member who will manage the merge and deployment flow.

Staging Merge and Deployment Flow Directions for Maintainers

  1. When a pull request is approved, squash and merge the pull request into develop. Merging a pull request into develop will trigger a deployment to the staging preview url. A new pull request Merge Develop onto Main will be automatically created when develop is ahead of main

  2. This new Merge Develop onto Main pull request will be aligned to the staging preview url and should be retested where multiple changes have been made - this may not be required where changes are unrelated and were all tested individually

  3. When changes are ready to be released to production, merge the new Merge Develop onto Main pull request. This will merge develop into main and trigger an automatic deployment to production via the Github <-> Vercel integration which aligns to the main branch

Using the Staging and Preview URLSs:

Using the preview urls means that your usage/testing doesn’t impact our metrics. For example, if you signed up for a new account for testing on the live site, then we would count that as one more user who signed up. To prevent testing data mixing with user data, the preview urls usage data is not tracked.

You should be using the preview urls whenever possible.

To use the preview urls, navigate to them and click 'Get Started' in the homepage to create a new account with any email and password.

If you already have an account, please login using the email and password you already set. If it says your account it already registered and you can’t remember the password, use the password reset flow. If you want to create multiple accounts, you can add a +1 to your email like <hello+1>@chayn.co and it will treat it as a new email address (but the emails still go to your inbox, magic ✨)

Our preview urls work almost exactly like our live website, except for:

  • When you open messaging, it will show a fake set of ‘chat team’ members available.
  • When you send a message, no-one will reply.
  • We might have also set the message text to be different on staging/preview, if we are testing options.
  • When you go to book a therapy session, you will see fake therapists.
  • When you book a therapy session, it won’t actually book a session with anyone.
  • When you get the email confirmation of a therapy session, it won’t show the same email as we send to Bumble/Badoo users.

You might want to use the live site if:

  • You want to test something about messaging
  • You want to book a therapy session with one of the therapists as part of their onboarding
  • A bug has been reported but you can’t see it on preview, so you want to see if it’s only affecting the live site
  • To test features that only work on production e.g. Hotjar
Clone this wiki locally