[RFC] Environments overhaul #500
Replies: 3 comments 2 replies
-
Re: Feature Flags with Edge Config, there was some work I did waaaay back to setup https://happykit.dev/ feature flags. It worked pretty well and I managed to get some basic by-user feature flag roll outs. There are also prisma migrations, but I think @basokant had more raw knowledge about it than anyone else. IIRC (and Ben tell me if I'm wrong) Prisma migrations are absolutely fine, it just makes sense for us to start doing migrations once the fever of development subsides a bit so there aren't rampant schema changes. |
Beta Was this translation helpful? Give feedback.
-
yeah i think at least the first actionable item is use a branch for staging |
Beta Was this translation helpful? Give feedback.
-
@anthonyshew does every feature branch end up with a 1:1 planetscale branch? |
Beta Was this translation helpful? Give feedback.
-
Abstract
Typehero needs to be able to conduct database migrations. Currently, we're working with PlanetScale and Vercel so it should be possible for us to pave a path where we can always have Vercel previews with an associated PlanetScale branch that has working schema with the application preview.
This has been solved thus far with two separate Vercel projects and handrolling database migration procedures. At the moment, we have no systematic way to handle migrations. Everything is done ad-hoc, as needed. This has been giving us problems since...well, it gets messed up just about every time, it seems, one way or another. 😄
Problems we need to solve
Production stability
Typehero currently is only a waitlist on production - but has broken a handful of times already in its first week of going live. We need to gain a bit more stability so we can have confidence in our ships.
Database migrations
How do we want to conduct database migrations? How do we bring these migrations from branches to production?
Multiple Vercel projects
At the moment, we have two projects on Vercel...for one project. How do we turn things into one project, shipping to production but still only showing the waitlist to the public?
Multiple PlanetScale databases
We also currently have multiple PlanetScale databases. I haven't quite understood why this is the case but it's unnecessary given PlanetScale's excellent branching functionality.
Goals
Non-goals
Proposed Solution
We'll use one Vercel project and one PlanetScale database and use branches according to the intentions of the various technologies. Additionally, we will automate database migrations using the respective PlanetScale and Vercel CLIs in GitHub Actions.
One Vercel project
We will ship to production under a flag that protects the entire site (except for
/
and/waitlist
) defined in Vercel Edge Config. Since Edge Config has sub-millisecond read times, we won't impact load times for the public-accessible pages. Additionally, we will create two Edge Configs, one for production and one for previews/development, so we can test things on previews before we release. We'll need to make a few code changes to read from Edge Configs inmiddleware.ts
to enable this behavior.Once we have our feature flagging in place, we'll move on the workflow for database migrations.
Database migration workflow
By default, all Vercel previews will be linked to a persistent PlanetScale branch. We'll do this so we don't have to constantly make new branches for the same schema (and stay within PlanetScale branching usage limits).
Getting a preview of changes
schema.prisma
a) Install PlanetScale CLI and Vercel CLI
b) Create a database branch
c) Push Prisma schema and seed database
d) Assign credentials for branch to Vercel branch
We now have a Vercel preview that runs against our new database schema. 🥳
Getting to production
At this point, we will validate that we like our changes and need to deploy to production. To do so a project maintainer needs to do the following:
Shipped! 🥳
Cleanup
Several cleanup actions need to be taken:
Both of these actions can be taken in a GHA action that runs post-merge and a pull request closes.
Possible failure modes
Alternatives Considered
Continue manually rolling - but with documentation
Part of the reason we are seeing instability as we work towards production is that we have to relearn the process to make a migration every time we would like to make one.
If we create a runbook so we can follow a happy path every time, we can still choose to handle migrations by hand. I would say this is the path to take if we are uncomfortable with automating the process and believe it to be error prone. (Hopefully, the Proposed Solution sounds solid enough that we don't need to fall back to here.)
If we were to choose this alternative, I would still recommend that we merge to one Vercel project and one PlanetScale database. I won't write out the entire happy path here but can do so if we start to lean towards this solution.
Happy to hear any feedback! Please add any discussion or questions you may have here.
Once we have a solution that we are happy with we can put together a PR to put our changes into place.
Changelog
type NotYet = typeof null
Beta Was this translation helpful? Give feedback.
All reactions