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 timeconsuming, 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/drush Tons 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-yourdevelopment-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
Developer 2: • pull •
Restores from special dump
• Lets Migraine know about new tables (if any) • commit, push
•
Config migrates!
Migraine: workflow Migration from @dev to @test: • Make special dump •
Sync files
•
Migrate DB
Migration 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 core
Disadvantages: • 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
Developer 2 • Pull
•
Enables feature
•
•
Works with config
Enables/revert feature
•
Config migrates!
•
Updates feature
•
commit, push
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: â&#x20AC;˘ Add meta-info and dependencies in .info file â&#x20AC;˘
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 code hook_update() to share with those who work in the same time hook_install() to share with new developers
Contoller feature â&#x20AC;˘ Includes other features as dependencies â&#x20AC;˘ 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-drupalsyncing-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 afedoruk@sterno.ru @sternodevteam http://devteam.sterno.ru