2010-03-24 12 views
6

Cosa cambio per passare dalla produzione alla messa in scena .. ecc. E dove .. Bootstrap?zend framework auto switch produzione staging test .. etc

Inoltre, curioso se qualcuno ha configurato la Zend Framework per passare automaticamente dalla produzione, messa in scena, prova .. ecc in base alle informazioni host ..

esempio ..

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

Sono nuovo a Zend ma in genere configuro i miei progetti per passare automaticamente agli ambienti di esecuzione in base alle informazioni sull'host.

grazie

risposta

15

Supponendo che si stia utilizzando APPLICATION_ENV come parte di Zend_Application, è possibile aggiungerlo nel file .htaccess o nella configurazione principale di Apache (supponendo che Apache sia in uso, dovrebbe essere possibile anche con server Web diversi).

Per esempio, nel vostro .htaccess/config (assume 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 

Poi assicurarsi che APPLICATION_ENV si trova in index.php utilizzando:

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

Questo viene aggiunto da Zend_Tool se lo usi per generare il progetto.

+0

SetEnvIf Host def.example.com APPLICATION_ENV = staging funziona per me – Yeroon

+0

modo migliore sembra essere: SetEnvIf HOST^abc.example.com $ APPLICATION_ENV = produzione ... – Kamil

0

Il modo migliore che ho visto è:

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

Ho anche provato host chiamato file configs:

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

ma il primo approccio è molto meglio.

+2

Sinceramente non vedo alcun valore in file indice separati, per non parlare di vederlo come un modo migliore. Idealmente, l'ambiente dovrebbe cambiare (è hardware/server), mentre il codice quando si passa da dev-> testing-> staging-> production dovrebbe essere lo stesso. La vera differenza tra gli ambienti è il pubblico previsto (e come tale livello di attività di debug/log). Quindi SetEnv in .htaccess (o configurazione dell'host virtuale) dovrebbe definire in quale ambito ci si trova e, una volta che si ha un ambito/ambiente, si carica la sezione corrispondente dal proprio file * single * ini. –

+0

Non c'è alcuna differenza dove lo si definisce, il vantaggio è l'ambiente di commutazione/dev di commutazione veloce. –

+0

La differenza è che nel caso in cui si definisce l'ambiente nel server e nell'altro caso, il client sceglierà l'ambiente. Questo ha diversi svantaggi: sicurezza, se si distribuisce un index_dev.php. Manutenzione: hai due o più punti nel codice, dove è definito il tuo ambiente (config, index_ .php, api_ .php, cli_ .php, ...); Devi dire ai tuoi clienti (AJAX, WebService-Clients, Shell-Scrips, ...), per accedere a file/URI diversi per ambienti diversi, devi anche dire ai tuoi clienti, quale ambiente "tu" vuoi che il client richieda . – stofl

1

Definiamo una variabile di ambiente (ENVPHP) e la usiamo nei nostri file di configurazione XML, quindi i parametri DB corretti vengono caricati finché si definisce la variabile di ambiente ENVPHP corretta. Usando XML puoi estendere (o scavalcare) i tuoi parametri comuni con quelli per gli specifici ambienti.

ie. la configurazione si presenta come segue:

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

E per caricare la configurazione, ho il seguente nel mio bootstrap (beh, in realtà in una classe Singleton Application):

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

Nel codice PHP se voglio per fare alcune cose solo per ambienti specifici, quindi uso Application :: getEnv() per verificare quale ambiente sono dentro ed eseguire il codice che voglio in base ad esso.

BTW La variabile di ambiente ENVPHP può essere impostata nel file di configurazione Apache utilizzando ie. SetEnv ENVPHP "dev" all'interno del contenitore VirtualHost. Per gli script CLI PHP si dovrebbe impostare come una variabile d'ambiente OS ...

4

che lavorano per me in .htaccess

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

Poi nella mia applicazione.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"