Drupal release management and Deployment BoF
UPDATE: You can see the presentation online.
I will be leading a birds-of-a-feather session at DrupalCon SF next week. This talk is taking place Monday at 4:15pm in rm 272.
We are interested in a new approach to tackle the stickiest Drupal issues we face: Deployment and release management.
We will begin by discussing the pros and cons of the most popular approaches:
* Simple db dumping
* Exportables with features
* manual coding of hook_update_N() functions
* DBscripts
We will then outline what we view as an optimal approach:
* Automatic tracking of all configuration changes
* Automatic conversion of these changes into code placed into modules utilizing hook_update_N() functions.
We are very intrigued with using the form API as already accomplished by Jonathan Pugh's Custom Module Tools and Macro.
We are interested in collaborating with others who are similarly frustrated with the state of current deployment options in Drupal to develop a solution. If that sounds like you, please get in touch so we can let you know when the BoF is happening!
This work is sponsored by WebStandard and Colingo Labs.
Comments
Mitchell:
Here's a link to our project on d.o http://drupal.org/project/package_builder
and the latest work is at http://code.drupalpm.org/twistor/package_builder/file/340470ec0e5f
Our latest development is best if you want to read the code, and if you want to run it, download the latest beta-2 releas on d.o
Gareth Price:
Birds of a Feather on Release Management – 272
Slides: here
Achilles heel of Drupal for larger sites.
Smaller sites usually work pretty well, just do a database dump (Backup Migrate), Features exportables – wrap things into a “ball of wax”, dump it to another site as a module. Features also integrates with Drush.
Can do hook_update_n functions, create a module that executes.
DBScripts: Drupal.org/project/dbscripts Lets you dump all tables separately, diff and merge. Idea is that you can take your configuration settings from a staging database and merge them with your production database.
Problems with Existing Solutions
Database dump – does not work with a complex site, treats data as one solid block. Cannot merge. Cannot keep incremental changes (can’t see where something went wrong). Difficult when more than one developer.
Exportables – great idea, but module has to be integrated with Features to actually do anything,
Hook_update_n – Cool approach, incremental, different developers can do this if numbering is right. Problem is that the recommendation is to make these files manually. Have to rewrite if you screw up the hook_update. Have been the way to go for enterprise level stuff so far, but we can do better.
DBScripts – Attracted as totally comprehensive, but has drawbacks. (Feedback: Java DBDeploy maintains changelog with a particular version, has manually written update scripts, mix of logic and content).
Other Solutions Mentioned in the Room
Install Profile API – helps with hook_update_n writing, but still need to write the update script manually.
Package Builder - http://drupal.org/project/package_builder
Deploy Module – for content, doesn’t copy configuration data. Looking into trying to do macro-style recording, but it has become non-trivial as there are problems with needing to match up source code (deprecated functions etc).
Solutions to Discuss
Two approaches; Right Solution and Right-Now Solution.
Rails Migration – up and down DB deployment scripts. Ability to revert if you screw up. Whenever you change database, you write a migration script.
Is the ideal to generate diff/macro files, or is it to work towards a separation of content and logic? Deploy module has been looking at the former, as there are ambiguities where one person’s content is another’s configuration (eg. Taxonomy terms, variables)
Problem is very closely tied to Drupal’s identity crisis of CMS vs Framework.
Ideal tracking:
1. Automatic tracking of configuration changes.
2. Ability to decide if a given change should be tracked or not tracked (like Revisioning already does for saving content)
3. Not have to do work to figure out code to make that change happen.
4. Automatic conversion of changes into code.
5. Ability to track changes by multiple developers. Can we integrate with SVN, Drush?
6. Schema changes?
Feedback: SVN integration should be very important so we’re not building version control inside version control.
Problem: Dependency chains with selective placing of config updates. Do we want to do large, complete files we have to chop down or smaller, more compact files and worry about missing stuff?
Ben’s Solution so Far
Hook into FormAPI, record changes from a certain point.
Not the most elegant solution, but neither is Drupal! We need one that works in this context.
A lot of this has already been done; Custom Module Tools exists already. Stupid generic name which probably has a lot to do with why it hasn’t really been picked up so far.
Bugs found so far: Does not work with TableDrag stuff.
What do we do about ID tracking? This is coming with Deploy but it is a fundamental problem, difficult to solve.
Macro recording generates a lot of code. Difficult to debug and work through if something’s not working. Should there be an uninstall/unplay way to roll back?
Group: Packaging and Deployment group exists to discuss long-term.
Will be using #drupalcon.deploy hashtag to follow this conversation on Twitter.
Feedback: Can we compare existing modules? Different shops and projects may have different solutions.
Post new comment