Efficient and easy Drupal 7 Development to Production workflow

Question

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?

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.