Add new comment

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?

Drush Rebuild

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 php-script command.

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:

Note the 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.