How would you put large existing Drupal 7 production site in some simple Development-Staging-Production workflow ?

I read through various documentation about the issue, but would like to know more efficient real life examples.

It is environment where only one person changes Drupal code (for now), and several editors do content publishing (they can edit content on live site and it seems it is ok to allow them).

I have in control Debian box with admin privleges (production site), and recently I did set up local Development/Staging Server (also a Debian box).

I am fond to Drush (haven't took advantage of drush make, though, but I had migrated some Drupal sites from server to server). I haven't used Features module, but I could implement it if neccessary. I have not used GIT yet, but I had read about it in theory. I am not sure is it a must for me to go with GIT, considering only one developer commits code.

My concern is about database updating, as I understood, GIT does not do that, and there could be enormous and critical differences between dev and production DB (settings change, site user inputs (registrations, comments etc, node creation etc)

Any advices?

  • 2
    I am pretty sure this is a dup, but I don't have time to search. We really need a canonical questions for this topic.
    – mpdonadio
    Commented Jan 26, 2013 at 13:31
  • I agree, this topic has been beaten to death on both d.o and dse. Commented Jan 26, 2013 at 14:30
  • 1
    I think the biggest reason it keeps popping up is because there is no complete answer out there that covers "all of the bases" of the workflow. You can piece together some tutorials to DIY your own deployment strategy but there should be a definitive, all encompassing documentation to bring Drupal to modern web development. Commented Aug 17, 2016 at 15:14

1 Answer 1


In short, I would:

  • Use features to get my configuration in code.
  • Use git to manage my code.
  • Use drush to manage my databases.

Why to use git to manage code:

  1. Drupal.org uses git to manage the Drupal project and all the modules.
  2. Version control of code allows you to easily see what changes have been made to your code over time. Without this, debugging/rolling back to a known good state is much harder.

When using git, I personally avoid complicated features (like submodules for Drupal modules) and simply commit all my code (Drupal core, contrib modules, patches, and my features) to a single repository.

If you already have dev and staging servers set up, getting git to push code to all three machines shouldn't be too hard to set up.

Why to use features to get configuration into code:

If you do dev/staging/live, you are going to have three sites now, not just one. Keeping track of configuration changes among three sites is a mess.

You basically have two options:

  1. Write down all your changes in a text file and apply them site-by-site manually.
  2. Use features.

Although #2 is harder to set up, it's much easier to deal with in the long run. A command like drush @mylivesite fd will quickly reveal how the configuration on your live site differs from the code in the features (managed by git).

In addition, as an added benefit of getting everything in features, you can edit the features code directly with a text editor; sometimes this is faster than using the Drupal admin UI.

Why to use Drush to manage databases:

Drush has a number of commands for syncing databases. It can be a bit of pain to get your servers set up to do this, but once you do, the time savings are tremendous. Google for tutorials for details.

In conclusion:

With this setup, most of your configuration will be in code (thanks to features). Your code will be version-controlled and easily pushed between servers (via git). What git can't handle, the database, will be taken care of with drush.

  • Can this solution handle staging content, too?
    – mpdonadio
    Commented Jan 26, 2013 at 13:32
  • Sorry, no this solution cannot handle staging content. (previous comment deleted b/c I didn't carefully read your comment) I tried the Migrate module, but it was far too much trouble to set up for what I needed. Commented Jan 26, 2013 at 14:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.