A workflow to synchronise changes before pushing to production

[martin-josef]

Hello everyone,

I wonder how to best deal with changes on the production site during the time it takes to push local changes. Two scenarios:

1. For a magazine-style website where people frequently comment, contributors add articles, accounts are created etc. I export all these changes from production and import them into the local instance to then push the entire local site to production.
2. The same applies to WooCommerce, I export the changes from production and import them to my local environment.

The challenges are

• the manual nature of exporting / importing changes which seems inherently prone to errors and
• figuring out what is changed and has to be synced up at all

To export / import I use WP All Import, which has a CLI that could be used as part of wordmove hooks. I consider automating that to some extent.

I'd love to hear some thoughts.

[alessandro-fazzi]

I'd try to swap the point of view: the production is where contents resides. Full stop.
What are my (the developer) changes worth to be pushed to production?

My points are:

• it's absolutely easier to know what are your development-related changes
• it's absolutely counterproductive and as error prone as doing things manually to pretend to have an affordable "diff" of a (somewhat) complex DB populated in the wild of the internet

My workflows never involve to push the DB to production. But if I'd need I'd prepare a script, to be ran contextually to the deploy, programmatically creating contents needed to support my feature. The script could be ran on production, but also locally with a "pull+seed-new-data+push" while in maintenance.

Obviously scripting the creation of over-complex contents could be over-budget.

Guys from delicious brains have a really interesting project here https://github.com/deliciousbrains/wp-migrations aiming to bring real frameworks practices about database updates to WP. I've never had the chance to use it (when working with WP I prefer to avoid complexities at all because I don't feel comfortable/confident enough with its architecture) but the idea of working on WP as I'd be working on Laravel/Symphony/Rails really tickles me :)

Best

[electricarts]

My workflows never involve to push the DB to production.

The problem for me would always be that I don't know exactly which tables are involved in my changes. I use Oxygen (https://oxygenbuilder.com) as a page builder. When I make changes (layout/design/content) via Oxygen, I have to sync the DB back to the live site. Otherwise I have to go through all the changes there again.

[martin-josef]

I have the same issue. This is all very interesting to me, but I will have to think about it for a bit longer.

@pioneerskies your approach is much more sensible, I haven't thought about it this way.

[alessandro-fazzi]

I see your points :) I never work on projects with visual builders, so I'm really ignorant about how they work internally. Probably my approach is assisted/enforced by this fact.