2010-03-24 10 views
6

¿Qué cambio para cambiar de producción a puesta en escena ... etc. y dónde ... Bootstrap?zend framework auto switch producción ensayo de prueba ... etc.

Además, curioso si alguien ha configurado su Zend Framework para cambiar automáticamente de producción, puesta en escena, etc .. prueba basándose en la información de host ..

ejemplo ..

if (hostname = 'prodServer') ... blah 
if (hostname = 'testServer') ... blah 

estoy nuevo para Zend, pero normalmente configuro mis proyectos para cambiar automáticamente los entornos de ejecución según la información del host.

gracias

Respuesta

15

Suponiendo que está utilizando APPLICATION_ENV como parte de Zend_Application, puede agregar esto en .htaccess o en la configuración principal de Apache (suponiendo que Apache esté en uso, aún así debería ser posible con diferentes servidores web).

Por ejemplo, en su .htaccess/config (asume mod_setenv):

SetEnvIf HTTP_HOST abc.example.com APPLICATION_ENV=production 
SetEnvIf HTTP_HOST def.example.com APPLICATION_ENV=staging 
SetEnvIf HTTP_HOST ghi.example.com APPLICATION_ENV=development 

A continuación, asegúrese de que APPLICATION_ENV se establece en index.php mediante el uso de:

// Define application environment 
defined('APPLICATION_ENV') || define('APPLICATION_ENV', (getenv('APPLICATION_ENV') ? getenv('APPLICATION_ENV') : 'production')); 

Este es agregado por Zend_Tool si lo usas para generar el proyecto

+0

SetEnvIf Host def.example.com APPLICATION_ENV = la distribución funciona para mí – Yeroon

+0

mejor manera parece ser: SetEnvIf HOST^abc.example.com $ APPLICATION_ENV = producción ... – Kamil

0

La mejor manera que he visto es:

index.php - production 
index_dev.php - dev, index_dev.php/controller/action 

También probé host llamado configs archivos:

base.ini - base config 
localhost.ini - dev config 
prod.host.com.ini - prod config 

pero el primer enfoque es mucho mejor.

+2

Honestamente no veo valor en los archivos de índice por separado, y mucho menos lo veo de la mejor manera. Idealmente, el entorno debería cambiar (eso es hardware/servidor), mientras que el código al pasar de dev-> testing-> staging-> production debería ser el mismo. La diferencia real entre entornos es la audiencia prevista (y como tal nivel de actividad de depuración/registro). Por lo tanto, SetEnv en .htaccess (o configuración de host virtual) debe definir en qué ámbito se encuentra, y una vez que tenga un dominio/entorno, cargue la sección correspondiente de su * single * ini file. –

+0

No hay diferencia donde lo defina, la ventaja es el rápido cambio de entorno prod/dev. –

+0

La diferencia es que en un caso define el entorno en el servidor y, en el otro caso, el cliente elegirá el entorno. Esto tiene varias desventajas: Seguridad, si implementa un index_dev.php. Mantenimiento: tiene dos o más puntos en el código, donde se define su env (config, index_ .php, api_ .php, cli_ .php, ...); Tiene que decirle a sus clientes (AJAX, WebService-Clients, Shell-Scrips, ...), para acceder a diferentes archivos/URI para diferentes entornos, incluso tiene que decirles a sus clientes, qué entorno "usted" quiere que el cliente solicite . – stofl

1

Definimos una variable de entorno (ENVPHP) y la usamos en nuestros archivos de configuración XML, de modo que los parámetros de DB correctos se cargan siempre que defina la variable de entorno ENVPHP correcta. Al usar XML puede extender (o anular) sus parámetros comunes con los de los entornos específicos.

es decir. la configuración es el siguiente:

<?xml version="1.0" encoding="UTF-8"?> 
<application> 
    <common> 
     <name>MyApp_name</name> 
     <code>MyApp_code</code> 
     <version>MyApp_version</version> 
     <authentication> 
      ... authentication specific parameters (ie. LDAP connection parameters) 
     </authentication> 
     ... 
    </common> 
    <dev extends="common"> 
     <database> 
      ... DB connection parameters for development 
     </database> 
     ... 
    </dev> 
    <tst extends="common"> 
     <database> 
      ... DB connection parameters for test 
     </database> 
     ... 
    </tst> 
    <prd extends="common"> 
     <database> 
      ... DB connection parameters for production 
     </database> 
     ... 
    </prd> 
</application> 

Y para cargar la configuración, Tengo el siguiente en mi rutina de carga (en realidad, en una clase de singleton de la aplicación):

public static function getEnv() 
{ 
    if (self::$env === null) { 
     self::$env = getenv('ENVPHP'); 
    } else { 
     return self::$env; 
    } 
} 

protected function initConfig() 
{ 
    $configFile = $this->appDir . '/config/application.xml'; 
    if (! is_readable($configFile)) { 
     throw new Application_Exception('Config file "' . $configFile . '" is not readable'); 
    } 
    if (false === self::getEnv()) { 
     throw new Application_Exception('The environment variable "ENVPHP" is not defined'); 
    } 
    $config = new Zend_Config_Xml($configFile, self::getEnv(), true); 
    $config->setReadOnly(); 

    Zend_Registry::set('config', $config); 
    $this->config = $config; 
} 

En código PHP si quiero para hacer algunas cosas solo para entornos específicos, entonces uso Application :: getEnv() para verificar en qué entorno estoy y ejecutar el código que quiero de acuerdo con él.

BTW La variable de entorno ENVPHP se puede establecer en su archivo de configuración de apache utilizando, por ejemplo. SetEnv ENVPHP "dev" dentro de su contenedor VirtualHost. Para los scripts PHP CLI se debe configurar como una variable de entorno del sistema operativo ...

4

que trabajan para mí en .htaccess

SetEnvIf Host dev.mydomain.ca APPLICATION_ENV=development 
SetEnvIf Host mydomain.ca APPLICATION_ENV=production 
SetEnvIf Host mydomain.localhost APPLICATION_ENV=production 

Luego, en mi solicitud.ini

[development : production] 
phpSettings.display_startup_errors = 1 
phpSettings.display_errors = 1 
resources.frontController.params.displayExceptions = 1 
; Database for development 
resources.db.params.dbname = "mydabase-dev"