Alavarサイトの構成の構造

みなさんこんにちは！
Alawarサイトは、 ロシア 、 アメリカ 、ヨーロッパなどの市場向けのサイト、モバイルデバイス用の個別のサイト、アフィリエイトプログラムのサイトなどです。これらはすべて、ハブのブログで既に書いた同じYiiインスタンスにデプロイされています。
今日は、サイトの構成のストレージ、構造、および管理をどのように整理したかを説明します。 また、さまざまな環境でプロジェクトを展開する方法についても説明します。

構成

サイトを構成するために、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 … 

すべての構成ファイルは、目的に応じて分類されています。

• web / config.php-すべてのWebサイトに共通の設定とパラメーターを含む構成
  

   <?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-サイト{site.ru}の最終構成（特定の設定+一般的な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') ); 

  
  最終的なサイト構成の形成に対するこのアプローチにより、新しいサイトを簡単に接続し、非常に柔軟に構成できます。
  
• console / config.php-web / config.phpと構造が似ていますが、独自のインポート、ログ設定、プラグインコンポーネントなどを備えたコンソールアプリケーションの構成
  
• test / config.php-テスト環境の構成
  

構成構造の特徴は、保護された/〜サーバーに「シルバー依存」のパラメーターと設定が集中し、各サーバーの個別のリポジトリに保存されることです（〜サーバーはリポジトリの1つをチェックアウトする単なるシンボリックリンクです）。 この構造により、松葉杖を使わずに簡単に、すばやく、さまざまな環境でプロジェクトを展開できます。

展開する

現時点では、プロジェクトを3つのサーバーに展開できます。

• dev-server-開発が行われているサーバー
• テストサーバー-テストが実行されるサーバー
• prodサーバー-生産

したがって、各サーバーには設定を含む独自のリポジトリがあります。

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

プロジェクトをデプロイするとき（ jenkinsとphingツールを使用してこれを行います ）、どのブランチとどのリポジトリを構成するかを指定するだけです：

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

phingがこれで行うことは次のとおりです。

 <!--     --> <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> 

したがって、展開後、プロジェクト全体の構造は次のようになります。

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

合計

私たちが使用した構成構造は許可されました：

• 新しいサイトの展開と構成が簡単
• プロジェクトの展開を自動化する
• さまざまな環境でプロジェクトを簡単に展開できます
• 構成ファイルの変更を追跡できる

ただし、もちろん、構成用のさまざまなリポジトリを使用するアプローチには欠点があり、主なものは変更の同期です。 環境設定を考慮して、1つのリポジトリの変更を他のすべてのリポジトリに手動で転送する必要があります。