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

[Adrian Rossouw]

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  
make the
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  
forms,
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  
working
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  
directions).
The moment you modify anything on the live site, you run into the  
problem where it's impossible to merge the changes back, without  
wiping the
staging / dev database, and resubmitting everything.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080809/b9f0c26d/attachment.htm