Drupal dev / stage / production setup

Question

Hey, I started developing a new site in drupal6 and I wonder what is the best way to set it up for dev / stage / production enviorment ... svn? online paid service (I saw serval soultions sites that need to be paid per unit) bash script for synchronization? please, help

Answer 1

This is probably one of the questions asked by the Drupal question - this is one area where Drupal is pretty weak.

You may want to take a look at Aegir . This is a Drupal-based platform designed to facilitate deployment and upgrade.

It uses Drush backstage, so if Aegir seems redundant for your needs, Drush may be what you need. Drush is a Drupal command line that allows you to perform actions on a Drupal site using the command line or inside batch scripts.

Between them, these two software components are recommended by Drupal for deployment management.

Please note that Drush (and therefore Aegir) has some features that only work on the Linux platform, so if your Drupal system is hosted on Windows, you may find things a little more complicated.

Answer 2

Here's how we do it: We have 2 production servers 1, and the second, where the environments for each developer and the "intermediate" environment are located. The code is stored in Git, and we constantly keep a leading and live branch.

In a nutshell: the live database is exported and distributed to developers using drush. Configuration and settings are "saved" using both functions hook_update () and hook_install () . We use Feeds

After the depolation, We have a very simple script shell that uses drush to copy a live database from a live server to a stage on the Dev server, and the developers use the same simple shell script to pull out the intermediate db in their own environment.

The configuration and development that takes place in the database is exported through Features and / or through interception of installation and upgrade. Using these three methods, we can easily deploy about 99% of all settings, content types, and other designs that usually exist only in the database. The last 1% are things that are easier to handle with the deployment setup step, rather than writing requests to hook_install and hook_update. 100% deployment is possible, but sometimes it’s not worth the effort.

Finally, there are times when content needs to be deployed from the scene in order to live. This module includes the Feeds module. Using feeds and a simple csv import file, we have successfully created and exported large taxonomic sets and even complex nodes and node sets. Using channels is also useful when you need a standard set of “test” data to populate development databases.

When the time comes to deploy new features or settings, we merge the developer’s changes into the main branch, deploy and test at the stage in which update.php is usually required to run, and then “import” the changes from the new or updated function. If everything passes tests and QA, the changes are merged into a direct branch and deployed to the production environment.

The biggest lessons we learned:

• while you can get it all in a function or upgrade and install it, it’s usually not worth it.
• The easiest way is to bypass the developer database in development and then export when the dust settles, rather than try to export every small change.
• using the diff module along with functions, saved our ass many times.

Answer 3

Look at drush and drush make. Drush is great for file synchronization and don't forget to check the backup module. Also take a look at the Features project, which will help you capture database schemas in code (see also hook_update for this).

Also: Drupal is moving to git in a few weeks. Use git.

Wheeeee!

Answer 4

After setting up multiple environments (dev / stage / prod), you can use git, subversion to save and synchronize code across multiple environments. But after that, you will encounter the following problem: how to pull content between environments. I know this is a very old question because it is also a very old problem. We have been working on this issue for a year at our company, darwoft. Please take a look at our tool. www.drumine.com. Basically, we can assign the same identifier to objects in different environments. We are going to be on December 10, 2015, at http://camp.drupalchile.org/ , explaining how this works.