[development] Solving the dev->staging->live problem

[Zohar Stolar]

Adrian Rossouw wrote:
>
> Actually, I think it would be beneficial for us to discuss this 
> problem on the list, even if it doesn't make it into core per se.
>
> We need to consider this kind of flexibility in our API's. so that we 
> can make it simpler (or even possible) to do this without
> having to patch Drupal, or manipulate data dumps with external tools 
> (that don't have access to such things as the _schema
> hook and any other semantics we might have, or can put in place to 
> help solve this problem).
>
> Perhaps we could then build a module or something for Drush which 
> could handle the dumping and merging of these partial
> data sets in a clean manner. It could use the schema information to 
> 'understand' what it's importing / exporting.
>
> Anyone have any thoughts on the matter (as I know we have ALL been 
> bitten by it before).
>
The problem is not only in dev->staging->production sense, but also in 
the other direction.
When you change code, or config, you want to be able to push the changes 
into production. But on the same time, you also want to test your 
changes on the staging/dev server, with the latest content (for example, 
when changing the structure/theming of a content type).

As yhager proposed, having two DBs instead of one, may ease things a lot.
One DB will hold content: nodes, revisions, files, users...
The second DB will hold configuration: views, cck structure, modules, 
variables... (this list is highly debatable).

This will allow for two-ways updating - content is pulled down, while 
configuration can be easily pushed up.

If there is enough interest, maybe we can still sneak in a BoF session 
in Szeged, although I believe we'll need much more than one meeting to 
solve this issue ;)