bleachga said:

I'm developing my first Laravel-based application from scratch, and designing as I go, so the database is changing frequently. I created the tables using migrations, and now I have a lot of additional migrations, one for each change I've made to the database. I get how useful this could be once I release, but it seems like a lot of overhead for these changes, and when I finish, it would be nice to have a single migration for each table with the "official" schema.

What's the best practice? Skipping migrations until you release to real users, or adding a new migration for every change while developing?

Thanks,

-brian

I always use migrations, however I do appreciate it may seem annoying. I usually try do as much in a single migration as possible, but always start a new one after every git commit (migrations are automatically run on testing env after committing).

I always use migrations, however I do appreciate it may seem annoying. I usually try do as much in a single migration as possible, but always start a new one after every git commit (migrations are automatically run on testing env after committing).

i agree with that. never edit an old migration if it's already run by someone else. that would seriously mess up everything if someone else or the server has already run that.

I happily edit old migrations until the first release or other factors make it risky. May not be best practice but I can trash, rebuild and seed my SQLite database 10 times per day. If I am working solo in the early stages it makes no sense to generate new migrations. Best practice can be over-rated and should always play second fiddle to common sense.

As for early stage testing, I tend to build the DB and seed from scratch with every commit.

Obviously this cannot carry on forever, and I revert to earlier opinions.