[development] Solving the dev->staging->live problem
z.stolar at gmail.com
Sat Aug 9 14:09:56 UTC 2008
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 ;)
More information about the development