Rebuilding a local development environment for a Drupal site can often be a chore - see the last post, "Workflow and tools for developing with install profiles and Drush Make", for a complex example.
In theory, you should be able to just get the code from the production or staging site onto your local machine, get a dump of the database, and off you go.
drush sql-sync and
drush rsync are two very powerful commands that can accomplish this for you in no time at all.
But that's usually not enough to get your dev environment up to date, because then you need to disable Google Analytics, CSS/JS aggregation, caching, and enable the Devel module, etc.
Further, each site might have its own set of modules that need to have settings adjusted. For example, the Salesforce module should connect to a Sandbox, not the production instance, when it's enabled on the local development environment.
To make things more complicated, each site can have a different structure. Here at DesignHammer, we have sites built using Drush Make, sites where the entire codebase is in Git, others where the codebase is in SVN, and still others where only our custom code is in the repository, and we symlink to a Drupal directory.
Once you go through all of the steps of rebuilding your dev environment, then each co-worker needs to go through the same tedious process. Depending on the complexity of the site, this can take quite a while. If you stop development on a site for a couple months, you find you've forgotten half the steps and need to go through the whole process again.
How can we get rid of repetitive and tedious tasks in rebuilding a local development environment and make this process simpler?
I wrote a simple utility, Drush Rebuild, to help me manage the process of rebuilding a local development environment. Drush Rebuild doesn’t make assumptions about your repository structure (Drush Make, entire codebase in repo, etc), nor does it care about extra steps you need to take when configuring a development environment, like disabling caching, adjusting connections with 3rd party services, and so on.
Instead, the utility provides a framework for executing rebuild scripts for a given site, using the power of Drush aliases and the drush
How does Drush Rebuild work?
Download the Drush Rebuild extension to your
~/.drush directory. In your terminal, type
drush help rebuild to test that installation succeeded and to get an overview of the options.
Edit your local dev site alias (run
drush topic docs-aliases if you are not familiar with aliases), and add an entry under the
path-aliases array for
%local-tasks. It should look something like this:
rebuild array in the alias, which can be used to store paths or values specific to your site rebuild script.
In your local tasks directory, create a file called
tasks.php. This where you implement the logic specific to a given site rebuild so that when you run
drush rebuild @mysite.dev, the
tasks.php file in local tasks is executed.
This means that you can create rebuild task scripts for your different sites, yet have a single mechanism to trigger a rebuild:
drush rebuild @mysite.dev.
Your themer or site builder doesn’t have to know about
drush rsync or
drush sql-sync, or the 20 steps you would take to change module and theme settings, they can just run the rebuild command and have a working local development environment up and running. You can save your rebuild script in the repository so six months from now, you don't have to dig through notes or try to remember the steps you took to set up an environment, you can simply run the command and be ready to go.
Here is an example script to demonstrate some of what you can do:
One nice thing about this approach is that the
tasks.php file can exist in your site's version control, while the database and paths specific to a given developers environment are defined in the drush alias.
If you don't like drush scripts, your
tasks.php file can call bash scripts, or anything else for that matter.
By default, Drush Rebuild will create a backup of your environment by using Drush 5’s archive-dump command, so if your rebuild fails, you can restore your previous environment. You can also pass the
--view-script option to have a look at the rebuild script before you run it, which is good to refresh your memory on the particulars of the local environment and how it might differ from your staging or production site.
That's all there is to say about Drush Rebuild for now. It's a small utility and its scope is modest, but I think it will help our team save a lot of time. Please try it out, let me know if you find it useful, and if you have additional example scripts or functionality to add to the project, please post them in the issue queue.
thanks for the blog.
fyi, you can remove the loop and call pm-disable once with the whole list of modules as an argument (comma separated). this reduces the overhead of calling out to drush and drupal multiple times.
I wanted to let you know that the Gist code for the sample is broken. I remember it being inlined code but not sure if was supposed to be a link now.
Thanks for writing up this great article on Drush Rebuild. Scripting in php is a powerful way to customize your development site after sql-sync. There is an example in the Drush-5 examples folder to show how to automatically enable and disable modules post-sync; see:
It is not necessary to use a post-sync hook, of course; it is perfectly valid to make a wrapper script such as you have done to roll all of the operations together, and it is, in fact, probably easier to understand the way you have done it. Looks good.
Thanks for the feedback! The post-sync hook looks really useful, I didn't know about it. I'm constantly amazed at all the new functionality that gets added to Drush, thanks for all your work on it.
This looks fantastic. I was literally about to start work on something like this for my devshop initiative. I really suggest promoting this to a full project on drupal.org
I am going to roll this out to a team and I'll let you know how it goes!
Rize is one of the active members of the Drupal developer community and has developed and supported various modules based on Drupal
Thanks Jon! Please keep posting feedback to the project issue queue. After some issues get sorted out and a few different examples are contributed I'll think about promoting to a full project.