drupal - the workflow
DESCRIPTION
How to organize development process when working with DrupalTRANSCRIPT
Drupal development: The workflow
Anna Fedoruk, Sterno.ru
Table of contents
Dark side of Drupal's power What's the problem and how to deal with
settings in DB Approach 1: migraine-powered workflow Approach 2: features-driven development
Why developers cry?
Drupal is great:• Flexible• Build whatever you want• Powerful tools like CCK, Views, Rules, Panles
etc.So what the problem?
Why developers cry?
OMG, the settings in DB!• Enabled modules and their settings• Blocks, taxonomy vocabularies, CCK content
types• User roles, permissions• Views, Rules, Contexts, Panels...
Why developers cry?
A simple workflow:• A developer works on his own local server, he
needs to share his work with others.• Test server: we need to migrate settings and
content.• Production server: we need to migrate settings
leaving content alone.Migrations of DB-ed settings are very time-
consuming, boring and error-prone
What can we do?
We need to:• Track configuration changes• Migrate these changes
Approaches:• Migrate changes in DB via versioned dumps• Move settings into code: Features ecosystem
The developer's best friend: Drush
http://drupal.org/project/drushTons of useful tools:• Modules enabling, disabling, downloading• Updates• Cache clearing• Dumps, backups, sync• ...• + modules add-ons
Approach 1: versioned DB dumps
Our experience with Migraine
• Migraine by Noosphere Networks http://ashearer.com/software/server-administration/migraine
• D6 modification by mukesh.agarwal17 http://www.blisstering.com/migraine-synchronize-your-development-staging-and-production-sites-databases-drupal-6
• drush• drush add-on by Danil Semelenov
The point of Migraine
Migraine knows how to deal with different types of tables:•Config tables•Content tables•Temporary tables•Cache tables•Ignore tables
Migraine Drush add-on
A wrapper for migraine commands:• Create local DB dump• Restore DB from local dump• Full site migration including source code and
DB• Sync files on local server with remote server
Differencies in installations
Individual settings and variables for every installation:•/sites/xxxx/settings.php•aliases.drushrc.php: aliases @dev, @test, @prod
Migraine: workflow
Developer 1:• Works with code and
configuration• Makes special dump • Lets Migraine know
about new tables (if any)
• commit, push
Developer 2:• pull• Restores from
special dump• Config migrates!
Migraine: workflow
Migration from @dev to @test:• Make special dump• Sync files• Migrate DBMigration from @dev to @prod:• Migration doesn't affect content tables• One should manually correct content tables
schema
Migraine: pros and cons
Advantages:• As all tables are classified, no need to think • Doesn't require special interfaces from
modules or coreDisadvantages:• Hard to resolve conflicts in dumps• Chaos reigns• In fact you still need to think
Approach 2: code-driven development
Features
• Code-driven development: put all the settings into code
• Features know how to deal with Views, CCK, Imagecahe, node types, user roles and permissions, Panels, Contexts, Rules and more
Features ecosystem
• Features • Ctools exportables• Strongarm — variables• Boxes — custom blocks (replaces core «add
block») • Context — blocks, breadcrumbs and so on • Diff — a tool for work with features states
Feature is a module
• .info — meta-info, dependencies• .module — place your code here• .install — usual install file• .features.inc
Configuration blocks:• feature_name.<smthng>.inc — generated by
Features module
Feature state can be:
• Default — config in code = config in DB• Overriden — config in code != config in DB
(needs revert or update)• Needs review — config in code != config in DB,
code was changed
A feature workflow
Developer 1• Creates feature• Enables feature• Works with config• Updates feature• commit, push
Developer 2• Pull• Enables/revert
feature• Config migrates!
Features management
Web UI Drush commands:
view features list creates new feature updates code state from DB updates DB state from code (revert) view differencies between code and DB states
Features without UI
To create feature or add component:• Add meta-info and dependencies in .info file• Update feature
What about our coworkers?
feature is a module, so one can use hook_install() и hook_update() to:•Enable modules•Add roles, url aliases etc.•Any custom codehook_update() to share with those who work in the same timehook_install() to share with new developers
Contoller feature
• Includes other features as dependencies• hook_install() and hook_updates() relfect
general changes in the site's state
Features: The Workflow
• Custom .profile: enables essential modules and Controller Feature
• Change code, enable modules, change settings, build new features
• Keep Controller Feature .install file up-to-date.• Update features in time• The project history in repo as code!
Features: advantages
• Easy to work with code in VCS• Features are reusable• Beautiful
Features: disadvantages
• Requires more efforts to keep system's state up-to-date
• Complex dependencies• Some components aren't exportable
Useful links
Подробнее про Migraine http://www.slideshare.net/drupalindia/migraine-
drupal-syncing-your-staging-and-live-sites-presentation
Подробнее про Features http://developmentseed.org/blog http://nuvole.org/blog/code-driven-development http://openatrium.com/
Contacts
Anna Fedoruk,Sterno.ru
@sternodevteam
http://devteam.sterno.ru