valentinocossar / trellis-database-uploads-migration

Ansible playbook for Trellis that manages database and uploads migration.
MIT License
94 stars 13 forks source link

Workflow #12

Closed edflips closed 6 years ago

edflips commented 6 years ago

Hey, This isn't a bug or feature request; I'm just struggling slightly with my understanding of how to integrate database migrations with the existing Trellis workflow. I should mention that I'm new to Trellis, and found this project recently which, in my mind, solves a huge hole in the Trellis concept. I think a greater understanding of the ramifications of this may be useful for the readme.

If I follow a 'downstream' ideal for the database (ie. the Production db is the single source of truth), would the Dev and Staging vaults become irrelevant? Is there a problem in doing that when perhaps reprovisioning in the future or does the vault get used only once during setup?

Sorry, I realise that this strays into the Trellis side of things, but I appreciate any guidance!

valentinocossar commented 6 years ago

Hi, in our experience, we are using the database and uploads migration in our company to deal go-lives and keep up to date our local environments with production. So if we have to reproduce bugs we just have to pull database and uploads and check what's wrong. We don't use push on production (only sometimes on staging) because you could overwrite some user-generated content in the database or the uploads folder.

I think a greater understanding of the ramifications of this may be useful for the readme.

Trellis itself is not made to be used only with a specific workflow, if you search Roots Discourse forum you'll find a lot of different workflows. So this tool provides an easy way to pull and push database and uploads to let people use it with the workflow they prefer, based on the type of project.

If I follow a 'downstream' ideal for the database (ie. the Production db is the single source of truth), would the Dev and Staging vaults become irrelevant?

This is up to you. In our experience, every new feature developed locally that modify something in the database is replicated manually in the production database, to prevent overwrites (a plugin like Mergebot from Delicious Brains do this automatically with a sort of diff between the two databases). But when you are working on a project that still has to go-live maybe you could use your development database as the source of truth, considering you are working alone on a project, otherwise you should consider staging as the source of truth. Finally, there are a lot of use cases, I recommend you to read some of the threads about this topic in the Roots Discourse forum and then evaluate which is best for you.

Is there a problem in doing that when perhaps reprovisioning in the future or does the vault get used only once during setup?

If you reprovision staging or production the database isn't overwritten with the one in development. On the first provision (staging and production) Trellis creates only an empty database and is up to you to import the database, you could use Sequel Pro (making a dump and then import it with the proper search and replace), a plugin like WP Migrate DB Pro, or this tool. Each provision after the first time doesn't modify the database.

For further doubts, I suggest you refer to the forum because it is something more related to Trellis than to this specific tool.

Hope I have helped you. 😊

edflips commented 6 years ago

Many thanks for taking the time!

I think I've had an epiphany. Stand back everyone. I was thinking that vault variables like vault_mysql_root_password and db_password were database specific without actually thinking about it. Obviously (now, anyway) they are mysql/mariadb user passwords, and as such, moving databases between environments wouldn't change anything.

Sorry for the confusion, and many thanks for jolting me in the right direction!