Most development shops make use of a "development/staging/production" server model. Maintaining code, content, and configurations across multiple environments can be a bit tricky, particularly since drupal doesn't currently provide any native means to separate configuration from content. This session would discuss the various methods to make sure that your development server looks like your production server. We will touch on version control, the backup and migrate module, and the features module, as well as integrating a deployment management software such as hudson or aegir, and how to scale these solutions from a small application to a large enterprise server architecture.
Speaker(s): Nick Hepner
Experience Level: Intermediate
2. Deployment Strategies:
Managing Code, Content, and
Configurations Across Multiple
Environments
Nick Hepner
3. Nick Hepner
• Web Developer since 1998
• Drupal since 2005
• Enterprise Architect since 2008
• Founding and active member Baltimore meetup
• Likes: beer
• Dislikes: PowerPoint Presentations
4. Introduction
• Standard Deployment Model
• Code, Content, Configuration and their workflows
• Problems
• Scalable Solutions for Drupal 6 & 7
8. Configuration
• Consists of Drupal admin and module settings and
presets.
• Imagecache/image styles
• Configuration workflow begins on development
server
o New modules installed
o Existing modules configured
o Content types, fields, and profile structures edited
o Database stored stylesheets, php code
10. Content
• Content workflow begins on the production server
• User Content
o User registrations
o User generated content
o Files and uploads
o Social interactions (e.g. Private Msg, Statuses, etc.)
o Content management
o Site and user administration
• Officiated Content
o News Articles
o Press Releases
o Internal Announcements
11. Content Workflow
User
Content
Content
Local Development Staging Production
Configuration
Officiated
Content
Content Staging
12. Conflicts
• Servers no longer synchronized
o Developers begin developing on different setups
• Data often gets overwritten
• Most recent/accurate data set difficult to keep
track of
• Dogs, Cats living together
13. Code
• Can be versioned for easy
deployment/management (SVN, Git)
• Does not conflict with database changes
• Does not include database stored code
14. Deploying Code With
Versioning
• Deploy to development through “trunk”
• Create a tag for deployment to staging
• Either reject the tag and fix bugs, or promote it to
production.
15. Code Workflow
Code Repository
Trunk Tags
Local Development Staging Production
Code
Rejected
16. Non-Starters
• Migrate – Intended to be used when moving a site
from another framework, such as Wordpress or
Joomla.
• Rsync - *nix command line tool for synchronizing
files. Does not allow for proper staging.
17. Manual Configuration
Management
• Developer manually sets configuration options on
all servers
• Fine for really small implementations
• More than one developer causes issues
18. Strategies:
Backup and Migrate
• Use backup and migrate module to create backup
profile for content and for configuration
• Use versioning to move code
• Configuration must still be entered manually on
development
• Takes some trial and error
19. Strategies:
Launch Manager
• Aegir – Seems to work well for launching initial site
rollouts. Not so much for maintenance updates
• Hudson
o Extensive initial configuration
o Integrates with version control
o Can script specific updates
20. Strategies:
The Three Pronged Attack
• Typically for enterprise environments
• Features
• Content Publication
• File Share
o Mount files drive
o Network-Attached Storage (NAS)
o Content Delivery Networks (CDN)
21. The Three Prong Attack:
Features
• Extracts configurations into code workflow to avoid
database conflicts.
• Allows versioning of configuration
• Great Documentation and support
o http://drupal.org/node/928026
o IRC #drupal-support
• Can manage all configuration exports in this way –
not feasible or scaleable.
22. The Three Prong Attack:
Services
• Publish content to lower environments
• OAuth Support
23. The Three Prong Attack:
Feeds
• Pull content, users, and pretty much anything
exportable by views.
• Can use Data module to map data to where it
needs to go.
• OAuth Support
• Use UUID module when importing to avoid
duplicate content.
24. The Three Prong Attack:
Synching Environments
• For the love of FSM: BACKUP YOUR DATABASES!!!!
• Once content is synched, push dev data
• If file share, Backup & Migrate exports
will be automatically available to all
environments.
• Staging environment pushes will be “easy”. Use B&M
“Restore”. Can be used with Drush.
• In production, push during off peak hours, put site in
maintenance mode and import data.
• This slide has way too much text… sorry.
25. The Three Prong Attack:
A Note on the Deploy Module
• Integrates with services.
• Essential if a content staging environment exists.
• Good for publishing content and approval workflow
• Not built to handle configuration settings, or multiple
workflows.
26. The Three Prong Attack:
Content Distribution
Local Dev Stage
Production
Network Drive
Content In Users
Content Out
Config Export
Content Staging
27. The Three Prong Attack:
Notable Modules
• Features – Export configuration into code.
o Features Tools – Automates feature downloads, and creates versioned
change files.
• Feeds – Import pretty much anything on the web
into Drupal.
o Feeds xPath Parser – Allows xPath style syntax for XML
o Feeds OAuth – OAuth integration selection for feeds module.
o Data – Allows customized data storage and mappings.
• Services – Publish anything in drupal
o OAuth – contains a services integration for OAuth authentication.
• Backup and Migrate