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.

1. Managing and deploying
configuration
...with exportables and the Features module
http://drupal.org/project/features

2. Jeff Miccolis,
Development Seed

3. We build websites

4. We build web apps

5. “...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/

6. 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/

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

8. In four parts
1. Problem
2. Solution
3. Best Practices
4. Distributing

9. 1. The Problem

10. Drupal’s strength is its
weakness.

11. No distinction between
configuration &
content.

12. The Workflow Problem

13. Development:
where the action happens.

14. Staging:
where it’s reviewed.

15. Production:
http://www.mysite.com

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

17. This is a story...
http://developmentseed.org/blog/2009/jul/09/development-
staging-production-workflow-problem-drupal

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

19. Round two is a PITA.
New views build on development
Rebuild on staging
Rebuild on development
Rebuild on staging
Rinse, Repeat.
Rebuild on production.

20. Round two is a PITA.
Requires extensive note taking
Prone to human error
Loads of repeated tasks

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

22. 2. The Solution
IMHO

23. Make a distinction
between configuration
& content

24. ...and write the
configuration to code.

25. What’s in code goes in
version control.

26. fig 1: Configuration components of a feature.
This belongs in your codebase.

27. Features module
semantics

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

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

30. feature: something you
want your website to do.

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

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

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

34. Core exportables
DRUPAL 6 DRUPAL 7
Content types Content types
Permissions Fields
Input filters Permissions
Menu items Input filters
Menu items
Image styles
Vocabularies

35. Contrib support
Contexts
Views
ImageCache
Ctools*
* Ctools is special

36. Ctools is special
Strongarm, Panels, Feeds, Data, etc...

37. Features is a system to
capture these
components,

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

39. Features should be
used throughout the
development process,

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

41. Create a Feature

42. Status of Features

43. Status of Feature

44. What changed

45. Create, Update, Revert

46. 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.

47. How this can work in
development:

48. Alex makes a feature.
Jeff adds a couple views.
Young adds theme overrides.
Alex fixes Jeff’s and Young’s bugs
Rolled out.
Jeff makes views adjustments
Rolled out.
Alex makes views adjustments, to fix Jeff’s...
Young touches up the views styling
Rolled out.

49. Views changes are
made only once.
Each change has a
commit log.

50. Less room for dumb
errors.
More accountability.

51. It’s easier to do things
right.

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

53. Briefly:
Adding exportables to
your module.

54. First: sequential IDs on
configuration is the
enemy.

55. the enemy

56. Machine name (poor man’s UUID)

57. Second: when in doubt,
use Ctools
http://civicactions.com/blog/2009/jul/24/
using_chaos_tools_module_create_exportables

58. Ctools’ export.inc
crash course...

59. Your job:
* Database schema
* Saving
* User Interface

60. Ctools’ job:
* Loading
* Exporting

61. Q: What’s left?
Dependency detection.

62. hook_features_export()
* add modules
* add components
* delegation

63. 3. Best Practice

64. Kit
http://drupal.org/project/kit

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

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

67. kitf
Namespaces
User roles & Permissions
Variables
Paths & Menu items
Block visibility & theme regions
Dependencies
Problematic components

68. kitt
Regions
Page template variables
Element attributes

69. These are working
documents, based on
developer feedback.

70. 4. Distributing

71. How do I share a
feature?

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

74. Can I always share my
configuration?

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

77. Feature Servers

79. http://code.developmentseed.org/
featureserver/

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

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

84. Based on Drupal’s
implicit standards.
* update status xml
* exportables
* drush make

86. Demo/Questions?