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)
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?
@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
Please or to participate in this conversation.