There's version control for databases that expresses your database schema as code, and changes as code that is applied incrementally, such as Liquibase or Sequelize Migrations. When you create a new DB you are just running a command to build it from that code to the exact same state as your application needs. I'm partial to just bundling this within the backend project so it's available for CI, tests and local development too.
Basically, you have a starting state where you create a users table and sessions table, and then you have a change file whenever you added some column or made some modification or added another table. Sequelize also manages populating data which they call seeding it so if you had like a geoip dataset you would have a file that inserts it.
I have used both of these for dev/staging/production and local dev on teams up to 8 devs.
Interesting, I didn't know about liquibase, thanks for sharing!
How about the data itself, do you usually seed it for local development, or PR/staging environments? Or do you get production subset for example? And if you do, do you deidentify the prod data to use in the non-production environments?
Trying to understand any pain points related to that the product development workflow (i.e. local dev, PR, QA, demo, etc.).
There's version control for databases that expresses your database schema as code, and changes as code that is applied incrementally, such as Liquibase or Sequelize Migrations. When you create a new DB you are just running a command to build it from that code to the exact same state as your application needs. I'm partial to just bundling this within the backend project so it's available for CI, tests and local development too.
https://www.liquibase.com/
https://sequelize.org/docs/v6/other-topics/migrations/
Basically, you have a starting state where you create a users table and sessions table, and then you have a change file whenever you added some column or made some modification or added another table. Sequelize also manages populating data which they call seeding it so if you had like a geoip dataset you would have a file that inserts it.
I have used both of these for dev/staging/production and local dev on teams up to 8 devs.
Interesting, I didn't know about liquibase, thanks for sharing!
How about the data itself, do you usually seed it for local development, or PR/staging environments? Or do you get production subset for example? And if you do, do you deidentify the prod data to use in the non-production environments?
Trying to understand any pain points related to that the product development workflow (i.e. local dev, PR, QA, demo, etc.).
Thank you!