8

I use dev, tst and prd environments for my Drupal 7 site set up. I use git for version control.

I would like to eliminate one manual step I need to do when moving site from dev to tst and from tst to prd.

Now I have to update settings.php separately for dev, tst and prd sites.

I would like to set up default.settings.php file so all the settings for dev, tst and prd are stored in one default.settings.php and. after copying to settings.php, Drupal will pick right settings depending on the environment.

I am looking for something like the pseudo code below:

common.settings 

if environment = dev then
   ...
   dev.settings
   ...
else if environment = tst then
   ...
   tst.settings
   ...
else if environment = prd then
   ...
   prd.settings
   ...
end if

Do you know how to do this for Drupal 7, exactly?

11

Don't use the same settings file like you are suggesting with your pseudocode. Instead, use three different settings files in three different folders, each folder corresponding to the domain name of each of your instances.

As a minimum, generally each environment is going to use a separate database host. Other settings that can differ from environment to environment can include the Apache Solr host, memcached settings, temporary folder and files folder, to name a few. You can place all of those there. When you migrate your database from PROD to TEST to DEV, it will automatically pick up the settings you specified.

Imagine that my site is called myfoobarsite.com. This is how my settings structure would look like:

/htdocs
../sites
..../default
....../default.settings.php
..../dev.myfoobarsite.com (DEV)
....../settings.php
..../qa.myfoobarsite.com (TEST)
....../settings.php
..../myfoobarsite.com (PROD)
....../settings.php

I also generally have two local instances of the site, one with the latest database snapshot from PROD and another where I keep all my changes. This is very useful when working with Features, and it allows you to test your features against the production database (locally) before committing. Here's the modified structure:

/htdocs
../sites
..../default
..../dev.myfoobarsite.com (DEV)
..../qa.myfoobarsite.com (TEST)
..../myfoobarsite.com (PROD)
..../mfbs.local (LOCAL ONE)
....../settings.php
..../mfbs2.local (LOCAL TWO)
....../settings.php

As for your local instances remember to make the appropriate entries in the /etc/hosts file and to modify your Apache host settings.

Just in case, I also placed a snippet from the settings.php for guidance:

<?php
$databases['default']['default'] = array(
    'database' => 'myfoobarsite',
    'username' => 'foo',
    'password' => 'bar',
    'host' => '127.0.0.1',
    'port' => '3306',
    'driver' => 'mysql',
    'prefix' => '',
);

/**
 * Apache Solr settings.
 * Use the acquia_identifier/acquia_key when hosting w/ Acquia.
 * Specify only the apachesolr_path key for your local instance
 * or instances that do not use Acquia.
 */
//$conf["acquia_identifier"] = "ABCD-12345";
//$conf["acquia_key"] = "1234f05ab12345dc1234a1234bbc1c12";
$conf["apachesolr_path"] = "http://localhost:8983/solr";

/**
 * Filesystem settings (MAC OS X, LOCAL)
 */
$conf["file_public_path"] = "sites/default/files";
$conf["file_temporary_path"] = "/Users/amateurbarista/tmp";
$conf["file_private_path"] = "/Users/amateurbarista/Sites/tfk/private";

Finally, if you're hosting with Acquia, you'll need to go to http://myfoobarsite.com/admin/config/system/acquia-agent and click on "clear keys" every time you migrate the database. That will cause Drupal to drop the keys that came w/ the imported database and pick up the ones specified in the settings file.

  • I'm probably missing the point, but how is this better than the pseudocode in the question? – Randell Jan 3 '14 at 13:01
  • 1
    Privacy, security, micro-management. Putting settings in different files allows different roles (local developer, sysadmin) to have different permissions to different files. A sysadmin can also deny visibility to prod/qa/dev settings using my suggestion, while the local developer will always retain his local settings. It's also harder to mess things up, with the 'all things in one file' approach, it's easier to mess all your environments at once. With my suggestion you're even setup to have different modules present and enabled per-site. – amateur barista Jan 6 '14 at 7:52
0

You can also use Environment modules which allows you to use different modules per environment.

Instructions

First, you need to have your dev/staging/production sites set up with their own unique settings.php (a common pattern for this is to require settings.local.php from settings.php). If you don't have this kind of set-up, then you don't need this module.

For staging/dev, add something like this to settings.php, once environment_modules is enabled, these modules will be enabled too.

E.g.

$conf['environment_modules'] = array(
  'devel' => 'sites/all/modules/devel/devel.module',
);

You can also use one settings.php by using the following example:

$env = $_ENV['AH_SITE_ENVIRONMENT']; // Acquia way: environment name
$env = $_SERVER['SERVER_NAME']; // or your server name, or whatever
$envModules = array(
    'default' => array( // By default it is development environment
      'devel' => 'sites/all/modules/contrib/devel/devel.module',
      'coder_review' => 'sites/all/modules/contrib/coder/coder_review/coder_review.module',
    ),
    'dev' => array(
      'devel' => 'profiles/mp_singapore/modules/devel/devel.module',
      'coder_review' => 'sites/all/modules/contrib/coder/coder_review/coder_review.module',
    ),
    'test' => array(
      'diff' => 'sites/all/modules/contrib/diff/diff.module',
    ),
    'prod' => array(
      'diff' => 'sites/all/modules/contrib/diff/diff.module',
    ),
);
$conf['environment_modules'] = $envModules[$env] ?: $envModules['default'];

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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