Off the Treadmill: Building a Drupal Platform for Your Organization


Published on

Drupal Distributions! We know and love Commons, Open Atrium, Open Publish, COD and other off the shelf projects. But what about your organization’s unique needs and use cases? You want to stop building websites and start building a repeatable system of your own. But how?

In this talk I share lessons learned from my time in Drupal consulting, including a one year establishing a common platform at a magazine publisher (30+ titles) as well as what I see on the front lines at Acquia. I want attendees to walk away with a vision to move from site building and into internal product development. For attendees already on this path I want to share lessons from my time in the trenches.

Specific takeaways:

How to get off the site building treadmill and into developing a product. “We don’t have the time” will no longer be an excuse.
How to deal with inconsistencies between sites. Decide what should be unique vs. what should be standardized.
Your love/hate relationship with Features (for example, how to deal with feature overrides).
How to deal with tricky upgrade path issues as your platform matures.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Off the Treadmill: Building a Drupal Platform for Your Organization

  1. 1. Off the Treadmill: Building a Drupal Platform for Your Organization Rick Vugteveen (@rickvug) Pacific Northwest Drupal Summit 2013 Wednesday, 9 October, 13
  2. 2. Hello! • @rickvug on Twitter, etc. • Drupal and I have history: Dev, Business Dev, Technical Architect, Product manager. • Currently work in Solutions Architecture at Acquia. Wednesday, 9 October, 13
  3. 3. What will we be talking about? • Code management strategies. Understanding your options and trade-offs. • How to structure your code into re-usable Platform functionality vs. Site specific code. • How to deal with problems with Features. • Consistency and upgrade path issues. • Whatever you want! Wednesday, 9 October, 13
  4. 4. Things I like but don’t expect to talk about • How branching works or other Git fundamentals • Drush Make • The basics of Features • Strongarm • Exportables Wednesday, 9 October, 13
  5. 5. Setting the stage Wednesday, 9 October, 13
  6. 6. • Duplication of content" • Disparate sources" • Disconnected reporting" • Islands of excellence" Inside Many Large Organizations, 
 the Web Is Broken Wednesday, 9 October, 13
  7. 7. Assemble solutions in Drupal Drupal core! Drupal + recommended! modules! Solution 
 Distributions! Wednesday, 9 October, 13
  8. 8. The Dream Department sites! Data portals! Primary site! Microsites! Collaboration
 Intranet ! Departmental
 Sites! Wednesday, 9 October, 13
  9. 9. Wednesday, 9 October, 13
  10. 10. Wednesday, 9 October, 13
  11. 11. Does this sound familiar? • “All of our Drupal sites have slight differences. It is difficult to keep track of the differences and maintain them all.” • “I feel like we keep on developing the same functionality over and over again.” • “Bug-fixing and fire-fighting never ends. We need to get back to creating new business value”. • “We don’t have time to build things the right way”. Wednesday, 9 October, 13
  12. 12. Wednesday, 9 October, 13
  13. 13. Code management & deployment strategies Wednesday, 9 October, 13
  14. 14. Site (Yellow): /sites/foo/modules/* /sites/foo/themes/* /sites/bar/modules/* /sites/bar/themes/* Platform (Brown): /profiles/foo/modules/* /profiles/foo/themes/* Core (Blue): /modules/* /themes/* /includes ... etc. Drupal Core Platform Theme, Modules & Features Site specific Theme, Modules & Features Wednesday, 9 October, 13
  15. 15. Multi-site model Site B Site A Site C Site D Git Repo Wednesday, 9 October, 13
  16. 16. Vendor branching model Site A Drupal Core Features Site Code Site B Site C Site D Git Repos Sites Platform Wednesday, 9 October, 13
  17. 17. Site B Site A Site C Site D Site A Site B Site C Site D Drupal Core Features Site Code Drupal Multisite Architecture ✓ Makes it easy to keep core and platform changes in sync among many sites - Makes it really hard to test and assure quality on core or platform changes that may affect tens or hundreds of sites - Is difficult to divide responsibility among different teams of developers and testers Independent Drupal codebases ✓ Lets each site be tested, QA'd individually at their own pace ✓ Lets independent teams work on individual sites without breaking others - Can lead to forking of core and platform code - Is difficult to maintain Lots of Code, Lots of Sites, Lots of Compromises Wednesday, 9 October, 13
  18. 18. Mmmmm... Cake Site Stuff Platform Stuff Core Stuff ▪ Segregate responsibility for site-specific development, platform development and QA ▪ Let dev teams use the tools they're used to (git, Github, Drupal) ▪ Combine the benefits of multisite and independent codebases Wednesday, 9 October, 13
  19. 19. How does it do it? Dev Stage Prod Platform/Site Push to production (manual and automated) Site A Site B Site C Site A Site Code Publishing Process Hosting Environments Git Repos Git Repos Drupal Core Features Site Code Managed Cloud Distribution Environment Site A Setup Tag Platform 10Platform 1.4.3 Site Tag 4.3.6 Target Tag newfeaturebranch Target Repo Dev 3 Code Distribution Management Platform 10 Platform 11 Platform 12 Platform 10 Wednesday, 9 October, 13
  20. 20. Who does Layer Cake work for? Site Developer Commits themes, modules to Site repo Platform Developer Commits changes to repos managing Drupal core, platform features and modules Dev Environments Developer sandbox environments Production Hosting Production environment(s) Platform Admin Manages available deployment environments, setup QA Team Tests and pushes approved code to production, for 1 site or 100's Wednesday, 9 October, 13
  21. 21. Developers! Developers Commit to repos they've been granted access to in Github Developer's personal sandbox where they can test against replica of production stack Use Layer Cake to deploy their repos periodically to sandboxes Wednesday, 9 October, 13
  22. 22. Admins! Developer C Sandbox Production Hosting Production HA environments Platform Admin Sets holds the keys to creating new mappings Site A Setup Tag Platform 10Platform 1.4.3 Site Tag 4.3.6 Target Tag newfeaturebranch Target Repo DevCloud 3 Developer A Sandbox Developer D Sandbox Wednesday, 9 October, 13
  23. 23. Quality Assurance! Production Hosting Production HA environments QA Team Tests and pushes approved code to production, for 1 site or 100's Platform 10b Keyword text Filter Sites Deploy Stage -> Prod Site Version 4.5 7.2 3.1 1.0 134.2 Site Site B Site D Platform Version 10b Site C Site E 10b Site A 10b 10b 10b Deploy Cancel Wednesday, 9 October, 13
  24. 24. Site/Code management gotchas • Testing the upgrade path on all sites. Shoot for eventual consistency but beware of the dangers of falling out of sync. • Watch out for update.php, or what we call “the Upgrade Dance”. • When using the Layer Cake approach beware Platform and Site compatibility issues. Wednesday, 9 October, 13
  25. 25. Flexibility vs. Effort • Multi-tenant: One database, one Drupal installation (ie. Domain Access). • Hybrid: Multiple databases, one Drupal installation. (Multi-site, potentially a true Distribution) • Multi-instance: Multiple databases, multiple Drupal installations. (potentially Vendor Branching) Wednesday, 9 October, 13
  26. 26. But I’m already a Cowboy! Wednesday, 9 October, 13
  27. 27. Baby steps • Do an inventory. How many sites do we have? How similar are they? Are we looking at one platform or many? • You can start just by moving modules around. • Then start standardizing the list of modules you are using. • Once modules are standardized, start capturing your common configurations into Features. Wednesday, 9 October, 13
  28. 28. Features. Love them. Hate them. Use them. Wednesday, 9 October, 13
  29. 29. Where I’m coming from 30 magazines, up to 60 sites (long term), ~10 legacy content management systems. Goal: One Drupal Platform. Wednesday, 9 October, 13
  30. 30. Wednesday, 9 October, 13
  31. 31. Wednesday, 9 October, 13
  32. 32. Wednesday, 9 October, 13
  33. 33. Wednesday, 9 October, 13
  34. 34. Wednesday, 9 October, 13
  35. 35. Dennis Publishing Example • Dennis Core: • Base theme • Media Management • WYSIWYG • Image cache settings • Contexts (or Panels) • Base Menus Wednesday, 9 October, 13
  36. 36. Dennis Publishing Example • Optional: • Article • Gallery • Carousel • Video player Wednesday, 9 October, 13
  37. 37. Wednesday, 9 October, 13
  38. 38. Overridden Features • Problem: Feature overridden due to configuration changes done in dev, stage or prod. • Fix: You’re doing it wrong! • Adopt a proper dev-> stage -> prod workflow. • Automatically revert Features on deployments. Script drush fr. • “drush fu” your workflow. (best Drush command ever!) Wednesday, 9 October, 13
  39. 39. Overridden Features because of site differences • Problem: I want to set defaults but I don’t need them enforced on each site. • Example: Comment settings should have a default but may change on a per site basis. • Potential Solution: • Don’t be afraid of .install files, hook_update_N(), variable_set and friends. Only Strongarm variables you don’t want to change. • Or structure your Features differently... Wednesday, 9 October, 13
  40. 40. Structuring Features • Make your Features granular with a proper dependency chain. • Example: Blog Feature and Gallery Feature both depend on the Categories vocabulary. Create a Categories Feature with only that vocabulary. Have other Features depend on that. • Capture your data structure in your Platform. Move display setting into a Site modules. • Example: /profiles/distroname/features/distroname_blog_structure /sites/sitename/features/sitename_blog_display (or have shared base fields as their own Feature) Wednesday, 9 October, 13
  41. 41. Wednesday, 9 October, 13
  42. 42. Wednesday, 9 October, 13
  43. 43. Wednesday, 9 October, 13
  44. 44. What the hell is a Skeleton Feature? • Located at /profile/dennis_distro/modules/skel/* • Naming convention: skel_blog_display, skel_gallery_display etc. • 1. On distro install automatically copy over skel modules from profile/ platformname/modules/skel/* to sites/sitename/modules/features/*. • 2. Automatically find and replace “skel” with “sitename”. Eg. changes hook implementation from skel_blog_display_menu() to sitename_blog_display_menu(). • 3. hook_info_alter() any modules with the prefix “skel_”. You’ll never see them and Features will ignore. • After install: /sites/sitename/modules/features/sitename_blog_display. Wednesday, 9 October, 13
  45. 45. Features upgrade path issues • No silver bullet for data structure changes. Avoid at all costs. Get your hands dirty if needed. • Start with multiple implementations of a Platform Feature to ensure the structure is generic enough. • Push back on asks for site specific data structure. Get creative with Taxonomy. • Adding to data structure on a per site basis is fine. Wednesday, 9 October, 13
  46. 46. Wrapping up. What we (hopefully) learned • Code management strategies. Understanding your options and trade-offs. • How to structure your code into re-usable Platform functionality vs. Site specific code. • How to deal with problems with Features. • Consistency and upgrade path issues. Wednesday, 9 October, 13
  47. 47. Additional Resources • Phase2 Blog post on Features Base Fields: http:// features/ • Patch for Features Base Fields: • Multi-headed Drupal: • The Drupal-Powered Enterprise White Paper: resources/whitepapers/drupal-powered-enterprise Wednesday, 9 October, 13
  48. 48. Thanks! Rick Vugteveen @rickvug PS - I’m hiring! Let’s talk. Wednesday, 9 October, 13