Comment configurer default.settings.php pour l'utiliser sur des sites de développement, de test et de production?

J'utilise des environnements dev , tst et prd pour la configuration de mon site Drupal 7. J'utilise git pour le contrôle de version.

Je voudrais éliminer une étape manuelle que je dois faire lors du déplacement du site de dev vers tst et de tst vers prd .

Maintenant, je dois mettre à jour settings.php séparément pour les sites dev, tst et prd.

Je voudrais configurer le fichier default.settings.php afin que tous les paramètres pour dev, tst et prd soient stockés dans un default.settings.php et. après avoir copié dans settings.php, Drupal choisira les bons paramètres en fonction de l'environnement.

Je cherche quelque chose comme le pseudo-code ci-dessous:

common.settings 

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

Savez-vous exactement comment faire cela pour Drupal 7?

N'utilisez pas le même fichier de paramètres que celui que vous proposez avec votre pseudocode. Utilisez plutôt trois fichiers de paramètres différents dans trois dossiers différents, chaque dossier correspondant au nom de domaine de chacune de vos instances.

Au minimum, chaque environnement utilise généralement un hôte de base de données distinct. D'autres paramètres qui peuvent différer d'un environnement à l'autre peuvent inclure l'hôte Apache Solr, les paramètres memcached, le dossier temporaire et le dossier de fichiers, pour n'en nommer que quelques-uns. Vous pouvez placer tous ces éléments là-bas. Lorsque vous migrez votre base de données de PROD vers TEST vers DEV, elle récupère automatiquement les paramètres que vous avez spécifiés.

Imaginez que mon site s'appelle myfoobarsite.com. Voici à quoi ressemblerait ma structure de paramètres:

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

J'ai également généralement deux instances locales du site, l'une avec le dernier instantané de base de données de PROD et l'autre où je conserve toutes mes modifications. Ceci est très utile lorsque vous travaillez avec des fonctionnalités et vous permet de tester vos fonctionnalités par rapport à la base de données de production (localement) avant de valider. Voici la structure modifiée:

/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

Quant à vos instances locales, n'oubliez pas de faire les entrées appropriées dans le /etc/hostsfichier et de modifier vos paramètres d'hôte Apache.

Au cas où, j'ai également placé un extrait du fichier settings.php pour obtenir des conseils:

<?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";

Enfin, si vous hébergez avec Acquia, vous devrez aller http://myfoobarsite.com/admin/config/system/acquia-agentet cliquer sur "effacer les clés" à chaque fois que vous migrez la base de données. Cela entraînera Drupal à supprimer les clés fournies avec la base de données importée et à récupérer celles spécifiées dans le fichier de paramètres.

Vous pouvez également utiliser des modules d'environnement qui vous permettent d'utiliser différents modules par environnement.

Instructions

Tout d'abord, vous devez configurer vos sites de développement / de transit / de production avec leur propre settings.php unique (un modèle courant consiste à exiger settings.local.php de settings.php). Si vous n'avez pas ce type de configuration, vous n'avez pas besoin de ce module.

Pour staging / dev, ajoutez quelque chose comme ceci à settings.php, une fois que environment_modules est activé, ces modules seront également activés.

Par exemple

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

Vous pouvez également utiliser un fichier settings.php en utilisant l'exemple suivant:

$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'];