Just finished watching the screencast. There’s a lot to go at here but it all makes sense.
One thing that you didn’t touch on is MySQL: I’m wondering about best practice for moving databases from dev to stage to production and then back to dev again?
I want to manage Wordpress entirely using composer, that is, I don’t want anyone using the standard Wordpress mechanisms for installing and updating plugins and themes. I also want to test Wordpress core upgrades on the staging server before deploying to production.
I’m wondering how I can handle this given that plugin and core upgrades can modify the database.
Also, is it posible to associate a specfic capistrano release with a specific named MySQL database so i can rollback the DB too?
I’m also wondering if it would make sense to add another stage for development, and then define a task that dumps out a copy of the production database, runs a sed command to find and replace the hostname and then updates the MySQL database on my development VM.
I could also use a .maintenance file to temporarily disable the production site while I’m working and prevent anybody from modifying anything.
Obviously I will need to add tasks for the other stages to handle the databases, but that’s fine.
How do you guys handle MySQL for roots.io? Do you store dump files in git?
Also, not sure if it’s just my copy, but the screencast comes to an abrupt end mid sentence!
Thanks for everything!