Is there a way to save data in database after using migrate:rollback or reset?

If it is a dummy data, you may be think of Factory.

Ref: https://laravel.com/docs/5.5/database-testing#introduction

Don't use rollback or reset on a production database. That's madness.

@tisuchi It's not dummy data.

@topvillas I used to get errors from php artisan migrate when adding new Model and such that force me to drop the whole database (local server only) and that's why I'm afraid of losing data when doing that kind of thing on live web app. It would be great to have the web done completely on local but think of my web app as FB where thing need to be fix and make change every single day.

Hmmm, rolling back and reset is definitely not the way to go!

I think I know what you're talking about - you're worried that if a new feature doesn't work, you might have new records added, but of course you can't rollback, as that might delete tables that were added when the feature was introduced.

Some tips:

1. If you can, use a test/staging server. Get a backup of the production database restored to the test setup - you can use this to make sure that migrations run correctly. (Table creation typically will, but if you're adding foreign keys this might work locally, but not in production).
2. Perhaps introduce schema changes in a separate release to feature changes, so you know that the schema changes have worked before the feature is available to users.
3. If you have to deploy to production, can you use feature flags to prevent a button/menu item from appearing? Then you can toggle it on for yourself and a few other colleagues before everyone else starts using it? This can be good if you have 1000s of users, you can roll it out to 5, 10, 25, 100 people etc, and can fix bugs while the user count is small.

There's an argument to say you should never have a migrate down option. Once a table or structure is changed, your application will change the underlying data in the database. At that point you any reverse migration will be from a different state. e.g. You create a table (but it's incorrect due to a bug), you want to change it but there's already data in it... the typical reverse of a CREATE TABLE is DROP TABLE, but you'll loose data. Instead you might have to migrate up with an ALTER TABLE, or another CREATE TABLE and copy data from one table to another.

Putting on my software engineering hat... Do you need more time to test changes before rollout? Are you spending too much time on fixing small issues? Does the code quality need to be improved? I get the impression that there's a level of urgency, but at the moment the software development processes are not adequate or the demands are too great?

@gregrobson wow, That's a really good pattern I should follow. As a junior dev, it's always great to have senior people like you to point out the problem. Many thank to you, mate. I think I understand what you mean and yeah, I'll do no more rollback on server but testing and more testing. Great!!! Cheer