Sincronizarea bazei de date între mediile de dezvoltare/staging și producție

Dacă este vorba doar despre mai mult din același tip de date (noi articole pe blog, comentarii noi), nu sunt sigur de ce ai nevoie să le sincronizezi cu adevărat. Nu este ca și cum ar schimba modul în care funcționează codul pe site, deoarece este doar mai mult din același lucru. De obicei, nu mă îngrijorez în privința asta decât dacă este un tip nou de date.

Eu doar mă asigur întotdeauna că am un eșantion bun de date pentru site, nu neapărat fiecare articol, pagină sau comentariu de pe site-ul live.

As soon as you touch the topic of doing changes in parallel you touch the area of configuration management. With lots of patterns, own communities (http://www.cmcrossroads.com/) and tools not so much for version management (as svn/git) but for support of configuration management (patterns) like clearcase. (totally different areas).

In this case it is still a simple situation and you will find it to work with some limitations and some manual work and some lists.

The scenario I am thinking of to make it more descriptive of the ideal solution: multiple developers working on the same codebase, multiple test environments, multiple acceptance environments, multiple production acceptance environments possibly in all corners of the world.

If you would want to do this a little bit more professional:

a) write down a list of all Configuration Items you encounter, this could be the WordPress code itself, plugins from externals, content, metadata and decide which ones of these you want to bring under some kind of "management", which ones matter.

b) describe the workflows that can happen e.g. what happens with a fix, what happens with something new being development, in what case do you change content on your side, what is that called, and who does it, who is the owner of it e.g. a new post or a new plugin.

c) for parallel working first describe which CI's you want to manage, decide if the flow is always from development to production or if it is really needed to do all of it two ways.

d) for each of the CI types under (a) write a resolution. E.g. for ALL that is text ( or exported text like php files but ALSO plain text in XML files) merging is possible. This is really no problem but you need a good merge tool. e.g. With ClearCase you would get in a 3 way merge the following situations: 1) trivial merges: it will do these automatically 2) non trivial automatic: it will do these automatically BUT you need to check it 3) non trivial non automatic: this is a conflict e.g. on 1 line several changes have been made. The non trivials are the minimal part that you need to care of manually, a good merging tool will lead you in this e.g. the one in clearcase (which also does word merging and where you can link in other commercial or non commercial mergers for specific file types). Furtermore if you have identified under (a) files that should be copied-only then their behaviour would be to not be merged but just be copied one way overwriting the other version without a merge (e.g. plugins that you have not modified). Many of these types are possible with different behaviours. But write down relations between CI's,

Then for the non text based merges you need to make a decision on how to handle them e.g. images that have been changed in 2 places. You could decide here that production always has preference (at least that is what i would think), which makes it simple.

So... to solve this problem you need a version management tool that support different streams. Each stream would represents one part. (this can be immensely complex depending on your needs but in this case I think it is very simple).

If you now can manage to have these streams under you WordPress installations and sync them also with the content of the database, etc... then you can perform the merges in the CM / versioning tool and then export it back in the other environment.

Thing is... you need to write this down first. This is not a technical hack. It is a default pattern around Config Management so nothing strange here also but you need to write it down. You might find e.g. that an installed plugin makes changes in the database with some data that is different in another environment, so you need to have an extra procedure around this.

Technically almost always everything is possible check http://www.cmcrossroads.com/forums for scenario's that are dozens or hundreds of times more complex though always using the same approach and using the same set of CM patterns.

in short: put a version management layer under it, automate the merges and handle the conflicts, then import in target environment. Think up a stream strategy that fits here and write it down. Perform a teeny weeny bit CM management. That would be the professional solution otherwise install some db copy hack, scripts etc...

Tocmai am publicat un articol despre cum sincronizez datele noastre de producție cu mediul de staging. Citește postarea mea de blog despre acest subiect la: http://blog.wp.weightpoint.se/2012/01/04/synchronizing-wordpress-multisite-database-from-production-to-staging-enviorment/

Dacă dorești să sincronizezi și codul și alte elemente, aș recomanda crearea unui repository Git sau Mercurial cu fișierul .ignore corespunzător.

Dacă vrei să faci actualizări diferențiale de la staging către producție, atunci cred că crearea de scripturi de migrare este cea mai sigură și mai bună metodă.