I have two developers working on local copies of a WP build and deploying to a staging server via capistrano. When we run wpcli:db:push, rather than syncing the database on the server, it completely overrides it.
For example, Dev A makes adds custom fields on his machine and pushes DB to server. Dev B makes changes to a page and pushes to server. Only the Dev B changes remain.
Is this expected behavior? Is there a solution/workflow that accommodates a sync?
wpcli:db:push is not meant to sync a database in the sense you are saying. The description is: Pushes the local WP database to the remote server and replaces the urls.
In WordPress land, there still isn’t a great way to handle database syncs across multiple developers. I would try and keep everything as file based as possible. ACF now has file-based json files that can be created when you create and update files, which seems to work pretty well now. If there are changes in the json files, you can go to the ACF in the admin and “sync” from the json files. You can also look into https://github.com/danielbachhuber/dictator , although that doesn’t handle things like custom fields, AFAIK
The other option is to have the staging be the source of truth. Database or content updates would happen on the staging server, and dev’s wouldn’t do anything but pull from it.
Only other thing I can think of, if you really do want to try your hand at actual database syncing: https://crowdfavorite.com/ramp/ , not exactly cheap, but it does work as advertised in the limited use I’ve tried it.
Never be sorry for pointing things out. Pointing things out is great. Be proud of pointing things out.
I know it’s not a roots project but it is integrated with bedrock-capistrano and I wanted to open the discussion up to more general deployment solutions.
Hosting the database of record on the staging server is probably the way to go but it still gives me the willies.
And, yeah, I usually like to manage ACF fields in a hard-coded acf-config.php file but thought there was a workaround.
Thanks for the input. Will update this thread if I think of anything else that works.
I mean the staging server would be where content edits or anything else that affects the database would be made. Then developers would not push up and overwrite the database, they would only pull the database down to their local environment, make code updates, and deploy their code to staging
I had a question regarding database difference checking and merging only things that don’t exist on the production db.
We are working on a site in which we’ll allow lawyers to create their own listing and then services to offer for sale through the listing. The thing is, this is obviously saved into the production / live database only.
The issue come as follows in this scenario around 2 developers and lawyers creating listings/services:
Developer A makes some changed locally (like adding a contact form 7 form for example) and pushes.
Developer B could easily pull those changes to the db before working on his end which would not allow overwriting on Developer A’s end, but what if he does changes via the database before he even starts working. This still wouldn’t solve the issue if they’re working on it at the same time because they have done a prepull before starting work and they can’t pull right before they push a change because then they would overwrite their own material being implemented.
The 3rd caveat to my situation is you have lawyers as well, who on the live site are signing up and filling out services for their listing also, in the time they pulled changes before working on their own stuff, 5 lawyers have signed up and filled out services. If either of them pushes db changes as well, they will overwrite the lawyers that have just signed up.
How do you build a solution around these scenarios?
Is there a way to do database difference checking and implementing only specific changes upon push?
This is a common and known issue. I think most everyone developing within a team faces this.
Perhaps one workaround is to use Amazon RDS and have all environments point to it. That way you only have 1 master database and never have to worry about migration. I’ve done this before (not with Amazon RDS, but with a server on our network). Make sure you consider the security implications - allowing external connections with your db host can be a security hole if done wrong.
Another obvious problem with this is you can’t necessarily test anything that involves database changes, since if something goes wrong you will also be affecting production. Perhaps keep your dev database local, and have staging/production shared? We’re back to square one
At this point I make careful notes of database changes and manually change them on the production server. Or if I know I’m the only one making db changes, just pull, change, and push the db.