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

[arthur]

On Aug 9, 2008, at 4:10 PM, Adrian Rossouw wrote:

>
> 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.

Adrian- I think you're right that it isn't a perfect solution (as it  
currently stands). Beyond what you've mentioned, there are dependency  
chains for users, content and configurations that could get really  
really messy.

That being said, I think it's pretty clear that many people in the  
Drupal community are really interested in a solution for this. A sense  
of agreement of how this problem could be tackled could really foster  
progress. Perhaps I'm being naive, but it does seem like some of the  
tools that various folks in the community are using are getting closer  
to being quite functional for lots of people. With some focused  
development time (a sprint perhaps?), it seems as though some of the  
more daunting pieces (reverting changes for example) might be  
approachable.

Anyway, I was just hoping to bring some awareness to one of the tools  
that does exist now, and could potentially serve as a model to build  
from. Of course, I'm not even the author, so maybe Greg should chime  
in :)



---------------------------------------------------
arthur at civicactions.com