[development] Solving the dev->staging->live problem
adrian at bryght.com
Sat Aug 9 20:10:51 UTC 2008
On 09 Aug 2008, at 9:53 PM, arthur wrote:
> I think a really interesting project is the deploy module (http://drupal.org/project/deploy
> ) which I think is an interesting abstract approach to this issue.
> It won't meet everybody's needs, and isn't functionally sufficient
> yet (for content at least), but is a good start, and worth starting
> a more serious conversation of how this problem might be addressed
> from the larger Drupal community. Some of the concepts that Greg has
> already got in place are critical for the staging issue. You can
> check out a talk Greg did on the deploy module at the Seattle Drupal
> User Group here: http://blip.tv/file/1033300
Deploy uses macros, essentially. It captures form submissions and
resubmits them to the other sites.
The entire drupal_execute / macro functionality was one of the
tertiary goals of the initial design of fapi, unfortunately we didn't
design water tight, so it was possible (easy in fact) to write forms
which didn't work with macros. We would have to vet all the existing
and tighten up the API to force it to work consistently across all
forms, to make deploy work in all cases. A good example of this not
is that cck 1.x forms. cck_import broke most of the time because the
forms weren't built to work consistently with drupal_execute.
Additionally, deploy only works one way. Which doesn't help in cases
like this (where content/configuration needs to be moved both
The moment you modify anything on the live site, you run into the
problem where it's impossible to merge the changes back, without
staging / dev database, and resubmitting everything.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the development