Level 6
I use a github repository along with Forge to manage my production site. With Forge when you run a deployment from their UI it pulls the most recent copy from my github account and automatically runs a migration.
It's just like magic. :)
Oct 4, 2019
4
Level 11
Managing DB Schema changes on a production Database
I have an existing Laravel application in production with an existing Database. I'd like to know what process others use to manage schema changes on a production DB, where the data is kosher and needs to be preserved after schema changes are applied.
Adding tables is relatively easy, because that table doesn't exist yet on production. But what process do you use to:
- Delete a table (how do you tell the code to 'not try to migrate the data from that table'?)
- add a column to one or more DB tables (say if the column has a required field? how do you tell the code to migrate the existing data after the schema changes are applied, without erroring out?)
- remove a column from a DB table (how do you tell the code to 'not try to migrate the data from that column'?)
I obviously have used migrations a lot for local development, but I (think I) am missing some key concepts around how to manage Laravel data.
Is there a way to do all of this with Laravel migrations programmatically? ie without having to do a manual export of the DB and subsequent import?
Level 11
@dalma thanks for the reply. It's interesting to see what others are doing successfully to manage their production data. How does Forge handle the 3 use-cases above with existing production data?
Btw I am not using Forge and don't plan to move to it, so I'd be very interested in what others in a similar boat are doing.
Level 75
-
First BACKUP the data from production.
-
Second make sure it backed up, view it, whatever necessary
-
Do a trial run of changes in local development mysql
If data is properly preserved their and new changes are there, perhaps you added a field or had to mass update a column, all should be good.
- Then do the changes on production
You could probably just have the site down a short time while doing this,
Me I don't use migrations, no need, I use sqlyog in development and phpmyadmin in production. If for example in development I have to "backup" all I use sqlyog, I can attach a date to the backup file.
So it is no problem restoring to a certain state. I have used migrations in the past, but to me it's much easier backing up.
Just the way I do it, and had no problems yet.
1 like
Level 11
@jlrdw thanks for the reply. This workflow involving manual backups sounds pretty bulletproof (and is the safe way to go), the downside is the manual checks and it doesn't rely on Laravel's abilities.
I'm wondering if there is a way to improve on this workflow in an automated way, using things like migrations etc. for the use cases I mentioned above. Not sure if this is possible, but I am ever curious to see if someone has a better way to do this.
1 like
Please or to participate in this conversation.