Symfony 2 - конфигурация нескольких серверов

Мы начинаем принимать Symfony 2 для проектов здесь, на работе, это здорово, но есть проблема, над которой я работаю, чтобы решить, что я почти получил, но не совсем.

Symfony рассматривает концепцию среды как отдельную среду выполнения на одном сервере. Это здорово, потому что вы можете переключаться между режимами работы с разными передними контроллерами (web) или с помощью переключателя env (cli) по прихоти.

Однако наш код развертывается на многих серверах как часть процесса разработки. У каждого есть локальная виртуальная машина, затем код распространяется через интеграцию, QA, Staging и, наконец, Production.

Итак, наша концепция среды - это сервер (виртуальный или физический). Вот цели с этой настраиваемой конфигурацией

Поддерживать функциональность Symfony ootb в отношении переключения среды выполнения.
Разрешить публичную (то есть контролируемую разработчиком) конфигурацию для каждого сервера
Поддержание частной (то есть управляемой sysad) конфигурации для каждого сервера
Будет работать как для web, так и для cli

Это означает, что мы не можем на 100% полагаться только на parameters.ini или на любой статически называемый файл, так как разработчику потребуется контролировать конфигурацию для каждого сервера плюс все эти файлы будут жить рядом друг с другом в git.

Итак, я бы хотел сделать это. Добавьте новое значение в параметры .ini, который устанавливает серверную среду. Что-то вроде этого

приложение /Config/parameters.ini

[parameters]
    server="int"

И затем в ядре загрузите дополнительный файл конфигурации на основе этого значения. Например, мне бы хотелось, чтобы это работало, но это не так (поскольку на этом этапе контейнер еще не существует)

приложение /AppKernel.php

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');
  }
}

Это позволит использовать такой файл, как app/config/server/int.yml, который разработчик может использовать для управления значениями, не относящимися к частным (т.е. не параметрам .ini).

Спасибо за чтение и дайте мне знать, если что-то запутывает.

ИЗМЕНИТЬ

Для уточнения, я не могу использовать или полагаться на

* nix переменные среды из профиля пользователя или через export. Зачем? Интеграция, QA и Staging могут находиться в одном ящике
Все в конфигурации vhost (не будет работать для cli)
Статически называемый файл (т.е. только что названный server.ini не будет работать)

ИЗМЕНИТЬ

Ответ 1