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

Sam Boyer drupal at samboyer.org
Sun Aug 10 23:56:39 UTC 2008


On Sunday 10 August 2008 11:09:14 Adrian Rossouw wrote:
> On 10 Aug 2008, at 4:41 PM, Sam Boyer wrote:
> > Sorry, I'm not grokking this idea. What's the use case for
> > generating modules
> > and associated update hooks?
>
> checking them into your own revisioning system with your own release
> and qa structures,
> distributing configurations and more.
>
> Basically keeping your releases in line with each other, so you don't
> have the code, and then a floating
> database synch process which doesn't match up directly to your code,
> so you wouldn't have sites trying
> to communicate with each other using different versions of modules
> (which might cause incompatibilities).
>
> This way, you upgrade all the sites and the code the way you normally
> would :
> svn update; run update.php.
>
> Being able to take any site and going 'You are an install profile
> now', AND keeping that
> install profile in synch across later versions without having to have
> to subscribe all the sites
> using the install profile to the main synch. (many of those sites
> might not even be yours)
>
> Basically, the dump to module thing takes the long view. Once you have
> done your development,
> and you actually want to deploy it in one or more places, you have a
> single atomic package
> of everything you need to get the site up and running, to which people
> can add their own content.

Gotcha. Ooooh. That is a nifty direction, and definitely one I hadn't thought 
of. In our 'holy grail' server workflow, I did have the idea that different 
parts of the data would flow differently to different servers - but indeed, a 
natural next step would be extending it to generating install profiles. Deploy 
wouldn't know the difference (nor would it care).

s
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.drupal.org/pipermail/development/attachments/20080810/7d7c5151/attachment-0001.pgp 


More information about the development mailing list