
You have a live website and you need to copy a fresh version of the (live) database onto your local machine for development. Next, you need to run through one or more of these rote tasks:
Does this sound familiar? If so, I have good news! I've created a module that will help you automate that process.
Devit allows you to select or create tasks that should be run when your database needs to be deved. You can initiate these tasks via an administrative page, or via Drush.
Devit comes with a submodule that will provide you with the basic tasks, but it also provides an API that allows you to create your own tasks! Ideally, various contrib modules will be packaged with their own Devit tasks. For example:
There are a few ways to choose and execute the selection devit tasks that you'd like to run.
This file must be placed in your site directory, e.g., /sites/default. It contains a simple, flat array keyed by task names:
// Set whether a task should be executed when Devit is run. $tasks = array( // Key rows by task name. 'clear-caches' => TRUE, 'update-file-paths' => FALSE, );
Here's a quick example of deving your site via Drush!
$ drush devit Please enter the new password for all users [password]: new_pass Set files directory path [sites/files]: new_files_dir Files directory path changed to new_files_dir. [success] Site ready for development!
Devit provides an API that works much like the Menu API. The hook_devit_tasks() function allows you to define your own Devit tasks, and gives you the familiar framework to specify details like title, description, task callback, user access callback, file includes, etc.
Here's a quick example:
/** * Implements hook_devit_tasks(). */ function yourmodule_devit_tasks() { $tasks = array(); $tasks['disable-caching'] = array( 'title' => t('Disable core caching features'), 'description' => t('Disables page cache, page compression, block cache, and CSS & JS optimization.'), 'task callback' => 'yourmodule_disable_caching', 'access arguments' => 'administer site configuration', ); return $tasks; } /** * Disables core caching. */ function yourmodule_disable_caching() { variable_set('cache', "0"); variable_set('block_cache', "0"); variable_set('preprocess_js', "0"); variable_set('preprocess_css', "0"); variable_set('page_compression', "0"); }
This module is still very much in development, but I'd like to gauge the level of interest in this tool. Would you use it? Do you have any ideas to contribute?
You could say things like:
Thanks!

Comments
Alex Weber
Mon, 02/25/2013 - 10:36
Permalink
Nice
Seems like a pretty good idea and I for one already have some custom stuff like this I reuse for my own projects so this is definitely something I'd appreciate :)
Chris Burgess
Mon, 02/25/2013 - 11:11
Permalink
Anonymise & switch settings
I've been considering a module to do similar, but with an eye to anonymising data for export to dev environments. Modules could implement hook_anonymise (-ze?) to replace identifiable data with sample content.
Using $conf in settings.php to override eg payment gateway settings for dev setups is handy too, and some of the tasks you mention above might be done there (eg secure site?). Need to look at this in context of Commerce gateways, where I suspect $conf won't do.
greg.1.anderson
Mon, 02/25/2013 - 15:58
Permalink
sync-enable.drush.inc
Have you seen the example Drush post-sql-sync hook sync-enable.drush.inc in the Drush examples folder? It does a subset of these operations after an sql-sync command. You could put a post-sql-sync hook into devit to do the same thing.
Of course, in the case of devit, you have a bit of a chicken-and-egg problem, since (a) devit probably isn't enabled on your live site (ideally), and (b) your post-hook function won't fire if your module isn't enabled. If you enabled devit with sync-enable, then you could potentially use a Drush post-enable hook to run your devit commands (probably only if a specific option appears on the commandline). Then you could set this option as a command-specific option in your dev site alias, and your devit commands would then fire automatically whenever you sql-sync from live to dev.
I like to use options defined in my site alias files to control more than just dev site set up; for example, my backup script consults the target sites alias files to determine what should be done during backup and update operations. I prefer to keep the backup site more or less unchanged, but I enable to environment indicator module for anonymous users. I sometimes like to sanitize the update site, and when I do, I put these options into the alias record for the update site. (For reference, my update script is at: https://github.com/greg-1-anderson/utiliscripts/blob/master/drupal-backu...). So, I have not only 'dev' targets, but also 'backup' and 'update' targets, and the operations that happens on each can vary.
I think that devit could be an interesting way to extend this concept even further, by providing a collection of more useful things to do when a site is migrated. Some example documentation on how to control devit options from a Drush site alias, avoiding the need to keep devit config in the database of the live site, would be a useful addition.
HÃ¥vard Pedersen
Tue, 02/26/2013 - 01:07
Permalink
Love this idea! I'm about to
Love this idea! I'm about to revise our workflow when it comes to development copies and syncing, and devit will definitely be a part of it! :)
Alberto
Tue, 02/26/2013 - 03:26
Permalink
Quite usefull
I think it can be quite usefull. I would use it for some of my projects.
Dieter Blomme
Wed, 02/27/2013 - 06:32
Permalink
Why not a drush plugin
Maybe a stupid question, but why isn't it implemented fully as a drush plugin? :)
madmatter23
Wed, 02/27/2013 - 19:31
Permalink
I'd certainly love integrate
I'd certainly love integrate devit with drush to a greater degree. Making it into a module offers a few advantages, the main one being that it is more easily extended and integrated with other contrib modules via the hook system.
Adam Gerthel
Wed, 02/27/2013 - 22:45
Permalink
Similar module, Tadaa!
Great work! We've developed a similar module, called Tadaa (http://drupal.org/project/tadaa), where you can set up any number of environments, and switch module states and variables depending on the environment. It's all in the UI so users won't have to write code to add their own stuff.
Add new comment