preview deployments
Even if Previews just pointed to an empty Convex DB that would work. Don't have to clone production or such. And maybe Preview Convex DBs could be short lived to prevent it from using up your servers. Short lived Preview DBs could actually be a feature. Nice to not have old DBs laying around. Maybe delete Preview DBs after X days or when the PR is merged to main (which ever comes first).
19 Replies
hey @Mikael Lirbank, yeah definitely feel your pain here.
on the workaround side, I don't think there's anything great quite yet. the best I can think of is to set the
CONVEX_DEPLOY_KEY variable in Vercel for the preview environment for specific branches. that way, each developer could set one of their dev Convex deployments for their branches, and simultaneous preview deployments across different users wouldn't try to push to the same deployment. this doesn't really work for a single user having more than one preview deployment at a time, though...
for the design process on our side, can you tell us a bit more about your workflow?
1. do you connect github to vercel directly?
2. are you using a branch based workflow? how many developers are on your team?
3. what would you expect from a convex deployment spun up for a preview? would it have an init script for prepopulating data, fork data from a production deployment, ..?
(feel free to DM if you'd prefer!)Gotcha, I'll look into using our dev envs locked to some specific branches, not great but a lot better.
Answers:
1. We have connected Vercel via their GitHub app
2. We use feature branches and PRs. We are 4 full-time devs currently.
3. I think of this in layers. Better you roll out something light first and then aim for cloning production with deltas and all the shebang that will require down the road. As an intermediary, don't you already have a way to push fixture data to the DB?
Expanding on no 3:
Release 1. Just set up an empty DB for each deployment. It could is deleted after X time or when the PR merge, or never, what ever is easier on your end.
Release 2. Enable scripting to set up default data for the deployments. I guess this can be done without you even doing anything. It's just something to document how one can customize Next.js build step with a data fixture step (only for previews)
Release 3. Enable cloning of the production DB. This is probably pretty involved as the prod database can be huge. And some users may not even want to clone it, so it should be optional I think.
I don't even know if Release 3 is important? See if other Convex users desire it first. For me, if I can get an empty DB per preview deployment and I can run a script to populate that data with some basic fixtures (eg. a user so I don't have to sign up, etc) that would be epic. That would totally solve our pain, copying the prod DB is cool but more a nice to have.
The pain right now is that we can't use previews to quickly review new PRs and discuss new features in progress. Fixing so it deploys is the main objective, everything else is bells and whistles.
cool, this is super helpful. and yeah, also good to hear that release 1 and 2 are still useful w/o the full power of release 3.
Nailing this would make Convex hard to resist for folks that like Neon and don't actually require postgres
@Mikael Lirbank thanks for expressing this. Folks on the team read this, are inspired and we are actively working on previews now.
Just my two cent: please consider forking an existing database (dev or prod) rather than using an empty db for previews. Hasura went that route and it crippled their GitHub integration in my experience. I ended up migrating the underlying db to Neon and investing a good amount of time setting up my own actions to use in place of their integration just to get value out of the previews.
By forking the entire database do you mean including production data or just schemas and some seed data. I think for this initial release we will go up to "Release 2" above. Full prod data forking would require a bit more care and thought and something we can consider for a future release.
I just looked at Neon again, and yes, does look like they provide full data forking via copy-on-write. I can see how that can be useful, but given you ( @erquhart ) feel that this is strongly needed I would love to understand more what this unlocked for you.
The primary difference between seed data and production data in a preview deployment, for me, is seeing what's actually going to happen in production before I deploy. This is especially true when a PR includes migrations - with Neon I was able to run a migration against production before I ran the migration against production, which goes a long way toward confidence in shipping.
Ah yes, that is what I was thinking about on my drive in today. Makes sense. I assume this is also because you have CI/CD going.
Yes, migrations run against the forked db in CI, so tests can be run post-migration against our actual data
Hell yeah! Thank you so much! This is going to be a huge improvement for our team's DX. We push a lot of PRs every day and we're ramping up even more so this is huge!
I am very glad that you decided to do an intermediate release before looking at copying production data. Better to have something working soon than waiting IMO.
That said, @erquhart presents some compelling reasons to clone production data around migrations etc.
One challenge with cloning data as-is that if you changed the DB model in the Preview then the production data will be incompatible anyways. An empty DB will work automatically. But that is where @erquhart is coming from I take. We currently are note doing any migrations, we just wipe the data as we're pretty early still. But in a few weeks we're going to stop wiping the DB so we are soon looking into migrations.
@erquhart what is your experience with Convex DB migrations so far?
Yep. This is a stepping stone that should solve a lot of use cases. First class migrations will be something we'll dig into a little later. Right now we just provide you with the recipe: https://stack.convex.dev/migrating-data-with-mutations
I think if you're doing manual production deploys, the lighter weight preview scheme should be fine. E.g. you can have a branch where you're making lots of breaking changes and then settle on building a migration path before you merge to
main and then pick a time to deploy yourself.
If you are doing continuous deploys off of main however, what @erquhart wants will feel much more seamless. Different teams choose different paths. Continuous deploys off of main is a pretty common pattern. It requires a bit of discipline from the team and/or a very thorough test suite.Migrating Data With Mutations
Using mutations to migrate data in Convex.
Agree, iterative is always the way. @Indy is right, my feedback is for CI/CD usage. I haven't set up proper CI or CD with Convex yet as I'm still prelaunch (all manual migrations so far), but I had it set up prior with Hasura/Neon and loved the confidence gain from literally running schema changes and migrations against prod before running schema changes and migrations against prod.
@Mikael Lirbank regarding prod data compatibility in a PR I think your comment is specific to early iterations where prod can be deleted and restored with seed data or something, but with actual production data the schema changes would have to be backward compatible no matter what.
Yep when you ship your product, you'll want to be very careful about schema changes. The article I linked above talks a bit about this, and there is also a great primer Ian that walks you through what to think about: https://stack.convex.dev/intro-to-migrations
Intro to Migrations
There are as many ways to migrate data as there are databases, but here’s some basic information to set the stage.
We also do CD from main so I agree to all points above. Thanks for the links, I'll read them shortly!
We're building out e2e tests with Checkly and Vercel which is another use case for Convex preview deployments. Just wanted to say how stoked we are that it's in the works! 🤩
Nice! We have it working internally. We're putting in some finishing touches on environment variables and generally simplifying as much as possible. Hope to have it out soon!
@Mikael Lirbank preview deploys are out in 1.5 🎉 https://news.convex.dev/announcing-convex-1-5/
Convex News
Announcing Convex 1.5
Convex 1.5 adds support for preview deployments, improvements to the Convex runtime, and more.
We are VERY excited about this! Will try it very soon!
Thank you so much for prioritizing this! 🙏
This wouldn't have happened this early if you hadn't expressed how critical it was for you. Thanks for the feedback, keep it coming!