[development] development, staging, production

[Ken Rickard]

To all that, I will also plug the new Secure Permissions [1] module
that I wrote for D7 (and then backported to D6).

It allows roles and permissions to be managed in code, so that users
can't accidentally expose security weaknesses on the live site.

[1] http://drupal.org/project/secure_permissions

- Ken

On Thu, Dec 24, 2009 at 11:04 AM, Ken Rickard <agentrickard at gmail.com> wrote:
> 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
>



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