drupal - the workflow

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

afedoruk@sterno.ru

@sternodevteam

http://devteam.sterno.ru