IBM Drupal Users Group Discussion on Managing and Deploying Configuration

Post on 14-Dec-2014

13.560 views 0 download

description

Presentation to the IBM Drupal Users Group on improving configuration management in Drupal using the Features module and exportables. This is becoming a best practice for configuration management.

Transcript of IBM Drupal Users Group Discussion on Managing and Deploying Configuration

Managing and deploying configuration

http://drupal.org/project/features

...with exportables and the Features module

Jeff Miccolis,Development Seed

We build websites

We build web apps

“...we decided to host our Drupal environment using virtualization. This allowed us to build and test the Drupal environment locally and easily ship the entire virtual machine to the production hosting platform.”

19 Dec 2006

http://www.ibm.com/developerworks/ibm/library/i-osource12/

Using open source software to design, develop, and deploy a collaborative Web site, Part 12: Hosting and deploying

http://www.ibm.com/developerworks/ibm/library/i-osource12/

This presentation is about making Drupal better at dealing with these problems.

In four parts

1. Problem2. Solution3. Best Practices4. Distributing

1. The Problem

Drupal’s strength is its weakness.

No distinction betweenconfiguration & content.

The Workflow Problem

Development:where the action happens.

Staging:where it’s reviewed.

Production:http://www.mysite.com

FYI, developing on the live site is a bad idea, always.

Round one goes fine.Developer, designer & client get the site out the door.

Round two is a PITA.New views build on developmentRebuild on stagingRebuild on developmentRebuild on stagingRinse, Repeat.Rebuild on production.

Round two is a PITA.Requires extensive note takingProne to human errorLoads of repeated tasks

Not having a distinction between configuration and code is bigger that just this one aspect.

2. The SolutionIMHO

Make a distinction between configuration & content

...and write the configuration to code.

What’s in code goes in version control.

fig 1: Configuration components of a feature.

This belongs in your codebase.

Features module semantics

Feature: module that contains collection of Drupal parts that do something specific.

Features: Drupal module that allows for the capture of configuration into code.

feature: something you want your website to do.

features: a set of things you want your website to do.

Yes, I’m sorry. It seemed like a good idea at the time.

The Features module makes Feature modules, which have...

Core exportablesDRUPAL 6

Content typesPermissionsInput filtersMenu items

DRUPAL 7

Content typesFields

PermissionsInput filtersMenu itemsImage stylesVocabularies

Contrib supportContexts

ViewsImageCache

Ctools*

* Ctools is special

Ctools is special

Strongarm, Panels, Feeds, Data, etc...

Features is a system to capture these components,

...these components are the configuration that describes how your site behaves.

Features should be used throughout the development process,

...it won’t fight back, once you get the hang of it.

Create a Feature

Status of Features

Status of Feature

What changed

Create, Update, Revert

Drush commands

features List all the available features for your site.

features-export Export a feature from your site into a module.

features-update Update a feature module on your site.

features-revert Revert a feature module on your site.

How this can work in development:

Alex makes a feature.Jeff adds a couple views.Young adds theme overrides.Alex fixes Jeff ’s and Young’s bugsRolled out.Jeff makes views adjustments

Alex makes views adjustments, to fix Jeff ’s...Rolled out.

Young touches up the views styling

Rolled out.

Views changes are made only once.

Each change has a commit log.

Less room for dumb errors.

More accountability.

It’s easier to do things right.

Not having a distinction between configuration and code is bigger that just this one aspect.

Briefly: Adding exportables to your module.

First: sequential IDs on configuration is the enemy.

the enemy

Machine name (poor man’s UUID)

Ctools’ export.inc crash course...

Your job:

* Database schema* Saving* User Interface

Ctools’ job:

* Loading* Exporting

Q: What’s left?

Dependency detection.

hook_features_export()

* add modules* add components* delegation

3. Best Practice

“The goal is to offer a straightforward base packagefor building state-of-the-art Drupal sites while specifying how Features builton top of Kit can be compatible.”

Specifications:Feature Specification (kitf 1.0-draft)Theme Specification (kitt 1.0-draft)

kitfNamespacesUser roles & PermissionsVariablesPaths & Menu itemsBlock visibility & theme regionsDependenciesProblematic components

kittRegionsPage template variablesElement attributes

These are working documents, based on developer feedback.

4. Distributing

How do I share a feature?

Are Open Atrium’s features appropriate on drupal.org?

Can I always share my configuration?

How can I get that nifty update status thing behind the firewall?

Feature Servers

Feature Server allows you to create projects, make new releases... subscribe to updates via the Update status module...

It is simple by design... For greater integration with version control systems or for automatic packaging consider using the Project module.

Based on Drupal’s implicit standards.

* update status xml* exportables* drush make

Demo/Questions?