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.

1. Off the Treadmill: Building a
Drupal Platform for Your
Organization
Rick Vugteveen (@rickvug)
Pacific Northwest Drupal Summit 2013
Wednesday, 9 October, 13

2. Hello!
• @rickvug on Twitter, Drupal.org 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. 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. 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. Setting the stage
Wednesday, 9 October, 13

6. • Duplication of content"
• Disparate sources"
• Disconnected reporting"
• Islands of excellence"
Inside Many
Large
Organizations,
the Web Is
Broken
Wednesday, 9 October, 13

7. Assemble solutions in Drupal
Drupal core! Drupal + recommended!
modules!
Solution
Distributions!
Wednesday, 9 October, 13

8. The Dream
Department sites!
Data portals!
Primary site!
Microsites!
Collaboration
Intranet !
Departmental
Sites!
Wednesday, 9 October, 13

9. Wednesday, 9 October, 13

10. Wednesday, 9 October, 13

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. Wednesday, 9 October, 13

13. Code management & deployment strategies
Wednesday, 9 October, 13

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. Multi-site model
Site
B
Site
A
Site
C
Site
D
Git Repo
Wednesday, 9 October, 13

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. But I’m already a Cowboy!
Wednesday, 9 October, 13

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. Features. Love them. Hate them. Use them.
Wednesday, 9 October, 13

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. Wednesday, 9 October, 13

31. Wednesday, 9 October, 13

32. Wednesday, 9 October, 13

33. Wednesday, 9 October, 13

34. Wednesday, 9 October, 13

35. Dennis Publishing Example
• Dennis Core:
• Base theme
• Media Management
• WYSIWYG
• Image cache settings
• Contexts (or Panels)
• Base Menus
Wednesday, 9 October, 13

36. Dennis Publishing Example
• Optional:
• Article
• Gallery
• Carousel
• Video player
Wednesday, 9 October, 13

37. Wednesday, 9 October, 13

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. 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. 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. Wednesday, 9 October, 13

42. Wednesday, 9 October, 13

43. Wednesday, 9 October, 13

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. 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. 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. Additional Resources
• Phase2 Blog post on Features Base Fields: http://
www.phase2technology.com/blog/new-field-bases-and-instances-in-
features/
• Patch for Features Base Fields: https://drupal.org/node/1064472
• Multi-headed Drupal: http://palantir.net/blog/multi-headed-drupal
• The Drupal-Powered Enterprise White Paper: https://www.acquia.com/
resources/whitepapers/drupal-powered-enterprise
Wednesday, 9 October, 13

48. Thanks!
Rick Vugteveen
@rickvug
rickvug@gmail.com
rick.vugteveen@acquia.com
PS - I’m hiring! Let’s talk.
Wednesday, 9 October, 13