IBM Drupal Users Group Discussion on Managing and Deploying Configuration
4 likes14,617 views
The document discusses managing and deploying configuration in Drupal, emphasizing the importance of distinguishing between configuration and content to improve development workflows. It presents the Features module as a solution to capture configuration into code, allowing for version control and reducing errors during development. The document also outlines best practices and distribution methods for sharing features, highlighting the use of ctools and feature servers for effective deployment.
IBM Drupal Users Group Discussion on Managing and Deploying Configuration
- 1. Managing and deploying configuration ...with exportables and the Features module http://drupal.org/project/features
- 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
- 10. Drupal’s strength is its weakness.
- 11. No distinction between configuration & content.
- 13. Development: where the action happens.
- 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.
- 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.
- 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
- 44. What changed
- 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
- 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
- 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
- 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?