IBM Drupal Users Group Discussion on Managing and Deploying Configuration

17,334 views

Published on

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.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
17,334
On SlideShare
0
From Embeds
0
Number of Embeds
551
Actions
Shares
0
Downloads
68
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

IBM Drupal Users Group Discussion on Managing and Deploying Configuration

  1. 1. Managing and deploying configuration ...with exportables and the Features module http://drupal.org/project/features
  2. 2. Jeff Miccolis, Development Seed
  3. 3. We build websites
  4. 4. We build web apps
  5. 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. 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. 7. This presentation is about making Drupal better at dealing with these problems.
  8. 8. In four parts 1. Problem 2. Solution 3. Best Practices 4. Distributing
  9. 9. 1. The Problem
  10. 10. Drupal’s strength is its weakness.
  11. 11. No distinction between configuration & content.
  12. 12. The Workflow Problem
  13. 13. Development: where the action happens.
  14. 14. Staging: where it’s reviewed.
  15. 15. Production: http://www.mysite.com
  16. 16. FYI, developing on the live site is a bad idea, always.
  17. 17. This is a story... http://developmentseed.org/blog/2009/jul/09/development- staging-production-workflow-problem-drupal
  18. 18. Round one goes fine. Developer, designer & client get the site out the door.
  19. 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. 20. Round two is a PITA. Requires extensive note taking Prone to human error Loads of repeated tasks
  21. 21. Not having a distinction between configuration and code is bigger that just this one aspect.
  22. 22. 2. The Solution IMHO
  23. 23. Make a distinction between configuration & content
  24. 24. ...and write the configuration to code.
  25. 25. What’s in code goes in version control.
  26. 26. fig 1: Configuration components of a feature. This belongs in your codebase.
  27. 27. Features module semantics
  28. 28. Feature: module that contains collection of Drupal parts that do something specific.
  29. 29. Features: Drupal module that allows for the capture of configuration into code.
  30. 30. feature: something you want your website to do.
  31. 31. features: a set of things you want your website to do.
  32. 32. Yes, I’m sorry. It seemed like a good idea at the time.
  33. 33. The Features module makes Feature modules, which have...
  34. 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. 35. Contrib support Contexts Views ImageCache Ctools* * Ctools is special
  36. 36. Ctools is special Strongarm, Panels, Feeds, Data, etc...
  37. 37. Features is a system to capture these components,
  38. 38. ...these components are the configuration that describes how your site behaves.
  39. 39. Features should be used throughout the development process,
  40. 40. ...it won’t fight back, once you get the hang of it.
  41. 41. Create a Feature
  42. 42. Status of Features
  43. 43. Status of Feature
  44. 44. What changed
  45. 45. Create, Update, Revert
  46. 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. 47. How this can work in development:
  48. 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. 49. Views changes are made only once. Each change has a commit log.
  50. 50. Less room for dumb errors. More accountability.
  51. 51. It’s easier to do things right.
  52. 52. Not having a distinction between configuration and code is bigger that just this one aspect.
  53. 53. Briefly: Adding exportables to your module.
  54. 54. First: sequential IDs on configuration is the enemy.
  55. 55. the enemy
  56. 56. Machine name (poor man’s UUID)
  57. 57. Second: when in doubt, use Ctools http://civicactions.com/blog/2009/jul/24/ using_chaos_tools_module_create_exportables
  58. 58. Ctools’ export.inc crash course...
  59. 59. Your job: * Database schema * Saving * User Interface
  60. 60. Ctools’ job: * Loading * Exporting
  61. 61. Q: What’s left? Dependency detection.
  62. 62. hook_features_export() * add modules * add components * delegation
  63. 63. 3. Best Practice
  64. 64. Kit http://drupal.org/project/kit
  65. 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. 66. Specifications: Feature Specification (kitf 1.0-draft) Theme Specification (kitt 1.0-draft)
  67. 67. kitf Namespaces User roles & Permissions Variables Paths & Menu items Block visibility & theme regions Dependencies Problematic components
  68. 68. kitt Regions Page template variables Element attributes
  69. 69. These are working documents, based on developer feedback.
  70. 70. 4. Distributing
  71. 71. How do I share a feature?
  72. 72. Are Open Atrium’s features appropriate on drupal.org?
  73. 73. Can I always share my configuration?
  74. 74. How can I get that nifty update status thing behind the firewall?
  75. 75. Feature Servers
  76. 76. http://code.developmentseed.org/ featureserver/
  77. 77. Feature Server allows you to create projects, make new releases... subscribe to updates via the Update status module...
  78. 78. It is simple by design... For greater integration with version control systems or for automatic packaging consider using the Project module.
  79. 79. Based on Drupal’s implicit standards. * update status xml * exportables * drush make
  80. 80. Demo/Questions?

×