Como configuro o default.settings.php para usá-lo em sites de desenvolvimento, teste e produção?


8

Eu uso os ambientes dev , tst e prd para o meu site Drupal 7 configurado. Eu uso o git para controle de versão.

Gostaria de eliminar uma etapa manual que preciso executar ao mover o site de dev para tst e de tst para prd .

Agora eu tenho que atualizar o settings.php separadamente para sites dev, tst e prd.

Gostaria de configurar o arquivo default.settings.php para que todas as configurações para dev, tst e prd sejam armazenadas em um default.settings.php e. Depois de copiar para settings.php, o Drupal selecionará as configurações corretas, dependendo do ambiente.

Estou procurando algo como o pseudo-código abaixo:

common.settings 

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

Você sabe exatamente como fazer isso no Drupal 7?

Respostas:


11

Não use o mesmo arquivo de configurações que você está sugerindo com seu pseudocódigo. Em vez disso, use três arquivos de configurações diferentes em três pastas diferentes, cada uma delas correspondendo ao nome de domínio de cada uma de suas instâncias.

No mínimo, geralmente cada ambiente usará um host de banco de dados separado. Outras configurações que podem diferir de ambiente para ambiente podem incluir o host do Apache Solr, configurações do cache de memórias, pasta temporária e pasta de arquivos, entre outras. Você pode colocar todos lá. Quando você migra seu banco de dados do PROD para o TEST para o DEV, ele seleciona automaticamente as configurações especificadas.

Imagine que meu site se chama myfoobarsite.com. É assim que minha estrutura de configurações se pareceria:

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

Geralmente, também tenho duas instâncias locais do site, uma com o instantâneo mais recente do banco de dados do PROD e outra em que mantenho todas as minhas alterações. Isso é muito útil ao trabalhar com Recursos, e permite testar seus recursos no banco de dados de produção (localmente) antes de confirmar. Aqui está a estrutura modificada:

/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

Quanto às instâncias locais, lembre-se de fazer as entradas apropriadas no /etc/hostsarquivo e modificar as configurações do host do Apache.

Por precaução, também coloquei um trecho do settings.php para obter orientação:

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

Por fim, se você estiver hospedando no Acquia, precisará acessar http://myfoobarsite.com/admin/config/system/acquia-agente clicar em "limpar chaves" toda vez que migrar o banco de dados. Isso fará com que o Drupal solte as chaves fornecidas com o banco de dados importado e escolha as especificadas no arquivo de configurações.


Provavelmente estou perdendo o ponto, mas como isso é melhor do que o pseudocódigo na questão?
Randell

11
Privacidade, segurança, microgestão. A colocação de configurações em arquivos diferentes permite que diferentes funções (desenvolvedor local, sysadmin) tenham permissões diferentes para arquivos diferentes. Um administrador de sistema também pode negar visibilidade às configurações de prod / qa / dev usando minha sugestão, enquanto o desenvolvedor local sempre reterá suas configurações locais. Também é mais difícil mexer nas coisas, com a abordagem 'tudo em um arquivo', é mais fácil mexer em todos os seus ambientes ao mesmo tempo. Com a minha sugestão, você ainda está configurado para ter módulos diferentes presentes e ativados por site.
barista amador

0

Você também pode usar módulos de ambiente, o que permite usar diferentes módulos por ambiente.

Instruções

Primeiro, você precisa ter seus sites de desenvolvimento / teste / produção configurados com seus próprios settings.php exclusivos (um padrão comum para isso é exigir settings.local.php de settings.php). Se você não possui esse tipo de configuração, não precisa deste módulo.

Para o estadiamento / dev, adicione algo assim a settings.php, assim que environment_modules estiver ativado, esses módulos também serão ativados.

Por exemplo

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

Você também pode usar um settings.php usando o seguinte exemplo:

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

Nenhuma versão d8 deste módulo até a data.
Vishal Kumar Sahu
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.