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 <[email protected]> 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 <[email protected]> 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 > [email protected] > http://ken.therickards.com > -- Ken Rickard [email protected] http://ken.therickards.com
