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.
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
Configuration Workflow Local Development Staging ProductionConfiguration Content Staging
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
Content Workflow User Content Content Local Development Staging Production Configuration Officiated Content Content Staging
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
Code• Can be versioned for easy deployment/management (SVN, Git)• Does not conflict with database changes• Does not include database stored code
Deploying Code WithVersioning• Deploy to development through “trunk”• Create a tag for deployment to staging• Either reject the tag and fix bugs, or promote it to production.
Code Workflow Code Repository Trunk Tags Local Development Staging Production Code Rejected
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.
Manual ConfigurationManagement• Developer manually sets configuration options on all servers• Fine for really small implementations• More than one developer causes issues
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
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
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)
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.
The Three Prong Attack:Services• Publish content to lower environments• OAuth Support
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.
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.
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.
The Three Prong Attack: Content DistributionLocal Dev Stage Production Network Drive Content In Users Content Out Config Export Content Staging
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