Estamos começando a adotar o Symfony 2 para projetos aqui no trabalho, o que é ótimo, mas há um desafio para o qual estou trabalhando para resolver que quase consegui, mas não totalmente.

O symfony trata o conceito de um ambiente como um tempo de execução separado em um único servidor. Isso é ótimo porque você pode alternar entre tempos de execução com diferentes controladores frontais (web) ou usando o switch env (cli) por capricho.

No entanto, nosso código é implantado em vários servidores como parte do processo de desenvolvimento. Todo mundo tem uma VM local, então o código se propaga através da Integração, QA, Staging e finalmente Production.

Então, nosso conceito de ambiente é servidor (virtual ou físico). Aqui estão os objetivos com essa configuração personalizada

Manter a funcionalidade de ootb do Symfony em relação à comutação do ambiente de tempo de execuçãoPermitir configuração pública por servidor (isto é, controlada pelo desenvolvedor)Manter configuração por servidor privada (ou seja, controlada por sysad)Vai trabalhar tanto para web e cli

Isso significa que não podemos apenas 100% confiarparameters.ini ou qualquer arquivo com nome estatico, já que o desenvolvedor precisará de controle sobre a configuração de cada servidor, além de todos esses arquivos estarem próximos um do outro no git.

Então, o que eugostar fazer é isso. Adicione um novo valor ao parameters.ini que define o ambiente do servidor. Algo assim

app / config / parameters.ini

<code>[parameters]
    server="int"
</code>

E então, no kernel, carregue um arquivo de configuração adicional baseado nesse valor. Por exemplo, eu adoraria que isso funcionasse, mas isso não acontece (já que o contêiner ainda não existe nesta etapa)

app / AppKernel.php

<code>public function registerContainerConfiguration(LoaderInterface $loader)
{
  $loader->load(__DIR__.'/config/config_'.$this->getEnvironment().'.yml');

  // Per-server config
  $server = $this->getContainer()->getParameter( 'server' );        
  if ( $server )
  {
    $loader->load(__DIR__.'/config/server/'.$server.'.yml');
  }
}
</code>

Isso permitiria o uso de um arquivo comoapp / config / server / int.yml que o desenvolvedor pode usar para controlar valores de configuração não particulares (ou seja, não parameters.ini).

Obrigado pela leitura, e deixe-me saber se alguma coisa é confusa.

EDITAR

Para esclarecimento, as coisas que eunão pode usar ou confiar em

* nix variáveis ​​de ambiente do perfil do usuário ou viaexport. Por quê? Integração, controle de qualidade e preparação podem estar todos na mesma caixaQualquer coisa na configuração vhost (não funciona para cli)Um arquivo com nome estaticamente (isto é, algo chamado apenasserver.ini não vai funcionar)