Best Practices for mid-project Database Migration changes

Migrations are especially useful when you want to add extra columns to your table. Lets say you have a migration for your user.

public function up()
{
    Schema::create('users', function (Blueprint $table) {
        $table->increments('id');
        $table->string('name')->nullable();
        $table->string('email')->unique();
        $table->string('password', 60);
        $table->dateTime('password_updated_at')->nullable();
        $table->rememberToken();
        $table->timestamps();
    });
}

public function down()
{
    Schema::drop('users');
}

Now if you want to add an extra column you can simple create a new migration that will add that column

public function up()
{
    Schema::table('users', function (Blueprint $table) {
        $table->date('birthday')->nullable();
        $table->boolean('active')->default(0);
    });
}

public function down()
{
    Schema::table('users', function (Blueprint $table) {
        $table->dropColumns(['birthday', 'active']);
    });
}

As you can see in the down method we remove the columns again. This is really useful when developing, so you can rebuild your database from a certain point.

I actually never had to revert a migration on producten, as long as you test it good enough on your local environment ;)

If you have more questions just let me know!

I'm probably not the best to answer just getting back into using php and laravel after a long break.

I'm not sure where you are rolling back. Once you got live data in the system I would imagine rollbacks are not a good option if on tables that are in use.

Where I see the beauty of migrations is if you have a team of developers each using their own development box. Migrations allow you to keep the same test data in place for development. Once you have live data in the database I don't think a rollback (and definitely not a migrate:refresh) are a good option.

You can add a new migration and put the changes in it using the change() method. Then you can use migrate to apply those changes and if no live data is in those changed fields you could rollback I guess but I'd test this on a development box first.

I had to do some major changes about 2 years ago to a live database that had very different structure from what I wanted. I installed both databases on a development box. And then wrote a seed script to migrate all the live data correctly into the new database. When that worked well I ran it on the production server and then changed the webserver to point to the new site.

Not sure if that helps any.

Thanks @bobbybouwmann ... That was exactly what I was wondering. I was trying to edit the existing file with no success. So, If I passed this project along to build from scratch, I wouldn't need to alter the "Create" migration if I leave the "Update" migration in the Migration queue, correct? Basically, artisan migrate will run the create migration and then run the update migration?

Yes, the migrations will have a prefix with a date. So they will be run based on the date. So the one you create first will be run first.

Now Laravel keeps a migration table in your database which will keep up which migrations have run. So if you have a new migration on a new deploy it will only run the migrations that haven't been run yet.