Hi! Yes, running drizzle generate before deployment to set up migrations is a solid approach. A common practice is to place it in a prebuild or predeploy step in your CI/CD pipeline or script, so it always runs before the actual deployment begins.

Depending on your setup, you could:

Use npm scripts with a prebuild hook.

Add it as a step in your CI workflow.

Or use a shell script to run drizzle generate and then your build/deploy commands.

thanks!

Would it work fine if I changed my package.json to have "build": "next build && drizzle-kit migrate"?

While I have experience with GH Actions, I would prefer to not use exclusively for this. "prebuild" might be bad if the build fails, so it would do to the migration but would have a non-matching code

I highly disagree with the suggestion. Application code and databases cannot be deployed atomically together and as such you will have a moment wherein they are incompatible with one another. Deploying changes to two systems at once introduces even more potential things that go wrong. What if your build succeeds, the migration doesn't and your app starts but has issues communicating with the database? What if the migration succeeds but the app won't start? If you attempt to revert the app to its previous version it won't be compatible with the database either.

In many cases you should apply changes to a database that support both the old and the new version of your application before cleaning up afterwards once you've ensured things work as expected.