[development] development, staging, production

[Ken Rickard]

The "no downtime" issue is a tough one, as the push-everything-to-code
approach requires very small periods of update lag.  It also doesn't
(so far as I know) allow for reverse workflows of
production->staging->development. And as Alex mentioned, it can't
handle content staging.

Another issue to consider is "who is pushing the changes." A
put-everything-in-code approach works great for engineers, sysadmins,
and command-line junkies. But for normal users, it's not really an
option.

Greg Dunlap (heyrocker) and team are doing great things with Deploy
[1] and Services [2] modules, which allows for real-time two-way
communication between multiple servers. See [3] for some details.

The major difference is that Deploy is a UI-based tool that site
within Drupal's admin interface, and allows editors to control change
management. It handles most configuration tasks and most types of
content, and is an extensible system built on a solid API.

For ForeignAffairs.com, we have a system in place that never requires
editors to log in to the live site. You can read about at [4] under
'technical details.' Essentially, they are able to test new features
in dev, manage content in staging (including review of user-submitted
content), and then push changes to live.

Down the road, I'd love to see Services / Features / Strongarm /
Exportables / Deploy merge into one big system for change management
through the UI _and_ the CLI.

[1] http://drupal.org/project/deploy
[2] http://drupal.org/project/services
[3] http://www.palantir.net/blog/bringing-deployment-capability-drupal
[4] http://palantir.net/experience/foreign-affairs

- Ken Rickard
agentrickard

On Thu, Dec 24, 2009 at 10:05 AM, Alex Barth <alex at developmentseed.org> wrote:
>
> We here at Development Seed capture all configuration (Views, content types,
> variables) in code using Features and Strongarm. Once its in code you can
> version control it. Pushing code between dev/staging/prod. is a non-issue.
>
> This approach accounts for 99% of configuration tasks - our roll out check
> lists when pushing live got very short. Of course, content staging is not
> covered by this approach, but we rarely face such a requirement.
>
> Alex
>
> On Dec 24, 2009, at 9:50 AM, Ashraf Amayreh wrote:
>
>> Hello all,
>>
>> I'm currently working with a company that's aiming to convert their .NET
>> portal to Drupal (yes, good luck to me on migration strategy!), the portal
>> gets nearly 30 million page views per month. I've done a lot of reading
>> about development->staging->production scenarios, looked at a lot of modules
>> like Drush, Aegir, etc but I want to see where efforts have reached
>> regarding this issue and possibly join forces with others. There are more
>> than ten developers/themers working on the portal.
>>
>> What reads/modules do you recommend? How are people managing this
>> difficult task? Have we gotten to a stage where no downtime in the
>> production server is possible in the process?
>>
>> Also, I like to learn from others, how does ROR handle this? How do other
>> systems handle this? Any one out there to share his experience?
>>
>> --
>> Ashraf Amayreh
>> http://aamayreh.org
>
> Alex Barth
> http://www.developmentseed.org/blog
> tel (202) 250-3633
>
>
>
>
>



-- 
Ken Rickard
agentrickard at gmail.com
http://ken.therickards.com