Agreed upon Due Date: Friday, October 24

Staging Environment Goals

• As a developer, I’d like to be able to have a preview deployment of my PR (full system) running where I can login and test it
  • So I can ensure my DB migrations apply cleanly to a fresh DB instance
  • I’d like to have a link inserted somewhere into my PR page on GitHub that links directly to this temporary staging instance
• As multiple developers, I’d like to be able to have unique parallel preview deployments of different PRs able to exist and run side-by-side
  • Unique DB, backend, frontend
• As a developer I want a useful set of seeded data for testing my staging deployment
  • Can we create an anonymized version of the production DB to seed?
  • Or do we just create a set of data only for staging (i.e. several fictional companies, users, coaching sessions, etc)?
• As Jim, I have a preference for using my RPi5 for the solution for this, but I’m open to other hosted solutions that don’t use it if they’ll be easier to set up and maintain in the short run and long run
  • I have a preference for not introducing any major new technology that deploying to production doesn’t already use, preference for continuing to use Docker Compose (e.g. Kubernetes, Terraform)
  • I’d also like to be able to have this system be easily reproducible on any new Ubuntu Linux box just in case my RPi5 ever breaks and needs to be replaced.

Important Notes

• GitHub is not set up to connect to the RPi5 over Tailscale yet, this needs to be done exactly like we do for production deployment to the DO Droplet (both boxes are Ubuntu 24.04 LTS)
• New auth token(s) and ssh keys will be needed so that GitHub Actions can connect to the RPi5 box
  • These will need to be added to the GitHub staging environment variables in the backend repo