Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

automica's avatar

Best practice way of running Migrations when deploying new features

Currently when we deploy changes that require changes to the database, I'd ssh into the server and run

php artisan migrate;
php artisan db:seed --class=NameOfNewSeeder;

We're now setting up CI to allow us to deploy directly to AWS which would mean we'd want to automate this manual step.

As such I'm wondering how I would best approach this? Would it be sensible to add a step in a migration to run any seeders we'd need for that feature, so we can always php artisan migrate; and that would update data too?

Alternatively would adding the call to the seeder just after the schema change (so both db and seeder are run in the same step)?

Any advice?

0 likes
5 replies
Sinnbeck's avatar

Yeah that is indeed viable and I have seen this solution used on several projects (I even do it myself on a non laravel project)

automica's avatar

@Sinnbeck do you create a separate seeder and then call it via artisan or just add the contents of seeder directly into the migration?

Sinnbeck's avatar
Sinnbeck
Best Answer
Level 102

@automica in my none laravel project it's all all just raw sql queries, but if the changed fit together, I keep then together. With laravel I might be more careful with that and split them up (in two migrations), in case I need to prune migrations later on

martinbean's avatar

@automica If you need to populate a new table with default records, then just do it as part of the migration.

The problem with separating seeding default values or whatever in a separate seeder class is, if you’re in an automated environment like CI/CD you can’t say, “Run this migration but after you do, run this seed”. Environments like that just do what they’re instructed. If that’s running migrations, then they’re just going to run migrations.

automica's avatar

@martinbean Recently I've been building the seeder as a separate class and then calling via artisan within the migration but it seems it'd be simpler to keep to a single migration that migrates and then seeds.

This would solve an issue I've had where the migration can't find the seeder class, and I've have to run 'composer dump-autoload' again.

@sinnbeck @martinbean thanks both for your feedback.

Please or to participate in this conversation.