The structure of configs on the Alawar sites

Hello!
Alawar sites are sites for Russian , American , European and other markets, separate sites for mobile devices, affiliate program sites, etc. All of them are deployed on the same Yii instance, which we already wrote about on our blog .
Today I will tell you how we organized the storage, structure and management of configs of our sites, which at the same time received advantages. And also I will tell how the deployment of our project is carried out in various environments.

Configs

To customize the sites, we applied the following configs structure in Yii:
')

protected/config /console /config.php /import.php /cache.php /log.php … /mobile /config.php /import.php /cache.php /log.php … /sites /alawar.ru.php /iphone.alawar.ru.php /ipad.alawar.ru.php /site.php … /test /config.php /import.php … /web /config.php /import.php /log.php … /~server /amqp.php /crontab.txt /db.php /eauth.php /mongo.php /redis.php /smsgate.php /services.php /comment.php … 

All configuration files were divided into categories according to their purpose:

• web / config.php - config, containing settings and parameters common to all web sites
  

   <?php return array( 'preload' => array( 'log' ), //   'import' => require(dirname(__FILE__) . '/import.php'), 'components' => array( … //   MySql 'db' => require(dirname(dirname(__FILE__)) . '/server/mysql.php'), //   Redis 'redis' => require(dirname(dirname(__FILE__)) . '/server/redis.php'), //   Mongo 'mongo' => require(dirname(dirname(__FILE__)) . '/server/mongo.php'), //  'log' => require(dirname(dirname(__FILE__)) . '/web/log.php'), //   'comment' => require(dirname(dirname(__FILE__)) . '/server/comment.php'), // RabbitMQ 'amqp' => require(dirname(dirname(__FILE__)) . '/server/amqp.php'), //   .  'eauth' => require(dirname(dirname(__FILE__)) . '/server/eauth.php'), … ), 'params' => array( //      'services' => require(dirname(dirname(__FILE__)) . '/server/services.php'), //   - 'smsgate' => require(dirname(dirname(__FILE__)) . '/server/smsgate.php'), … ) ); 

  
  
• site / {site.ru} .php - the final config for the site {site.ru} (specific settings + common config web / config.php):
  

   return CMap::mergeArray( array( 'basePath' => dirname(__FILE__) . DIRECTORY_SEPARATOR . '..'. DIRECTORY_SEPARATOR . '..', 'name' => 'Site', 'theme' => 'site', 'host' => 'site.ru', 'language' => 'ru', // site.ru 'modules' => array( … ), // site.ru 'controllerMap' => array( … ), //   site.ru 'components' => array( … ), // application-level parameters that can be accessed // using Yii::app()->params['paramName'] 'params' => array( //runtime  //: //Yii::app()->params['runtimeData']['css'] -    css  //Yii::app()->params['runtimeData']['js'] -    js  'runtimeData' => @include(dirname(__FILE__).'/runtime/sites/site.ru.php'), 'adminEmail' => 'admin@site.ru', ), ), require(dirname(dirname(__FILE__)).'/web/config.php') ); 

  
  This approach to the formation of the final configuration of the site makes it easy to connect new sites and quite flexible to configure them.
  
• console / config.php - config for console application, similar in structure to web / config.php, but it has its own imports, logging settings, plug-in components, etc.
  
• test / config.php - config for test environment
  

A specific feature of the configs structure is that the protected / ~ server contains “sero-dependent” parameters and settings that are stored in separate repositories for each server (~ server is just a symlink to check out one of the repositories). This structure allows you to easily, quickly and without crutches to deploy the project in a variety of environments.

Depla

At the moment, our project can be deployed on 3 servers:

• dev-server - the server on which the development is conducted
• test server - the server on which tests are run
• prod server - production

Accordingly, each server has its own repository with configs:

• dev-config
• test-config
• prod-config

When deploying a project (we do this with jenkins and phing ), we simply indicate which branch and which repository with configs to raise:

 #  task-xx  dev- phing -Dbranch=task-xx -Dconfig=dev-config deploy #     phing -Dbranch=prod -Dconfig=prod-config deploy 

This is what phing does with it:

 <!--     --> <target name="deploy" depends="-get-properties"> <!--   ,     --> <mkdir dir="${deploy.path}" /> <!--   ,          --> <mkdir dir="${deploy.path}/application" /> <!--   ,        --> <mkdir dir="${deploy.path}/config" /> <echo msg="checkout application and config..." /> <!--   --> <exec command="bzr co ${bzr.branch.path} ./" dir="${deploy.path}" checkreturn="FALSE" returnProperty="bzr.co.return" outputProperty="bzr.co.out" /> <if> <!--    ,  ,     --> <equals arg1="${bzr.co.return}" arg2="3" /> <then> <exec command="bzr co ${bzr.trunk.path} ./" dir="${deploy.path}/application" /> <exec command="bzr switch -b ${bzr.branch.path}" dir="${deploy.path}/application" /> </then> </if> <!--     --> <exec command="bzr co ${bzr.config.path} ./" dir="${deploy.path}/config" /> <!--      runtime --> <chmod file="${deploy.path}/application/protected/runtime" mode="0777" /> <!--     --> <exec command="ln -s ${deploy.path}/config/server server" dir="${deploy.path}/application/protected/config/" level="info"/> <!--    php error log --> <exec command="ln -s ${php.error.log.path} phplog" dir="${deploy.path}/application/protected/runtime/" level="info"/> <!--      css  js       protected/runtime/sites/{site.ru.php} --> <exec command="php ${deploy.path}/application/protected/yiic deploy data=css" /> <exec command="php ${deploy.path}/application/protected/yiic deploy data=js" /> <!--    redis  mysql --> <exec command="php ${deploy.path}/application/protected/yiic deploy data=shardmap" /> </target> 

Thus, after deployment, the structure of the entire project becomes the following:

 application/ #     protected/ … config/ … ~server/ #  config/server … … public/ … config/ #    … server/ … 

Total

The structure of configs used by us allowed:

• easy to deploy and configure new sites
• automate the project deployment
• easy to deploy the project in various environments
• be able to track changes in configuration files

However, of course, the approach with various repositories for configs has its drawbacks, the main one is the synchronization of changes. It is necessary to transfer the changes in one repository to all others, taking into account the settings of the environment.