Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Pages: 1
J'aimerais vous proposer ceci pour faciliter le deploiement en prod.
Tout d'abord, il serait preferable de mettre une variable d'environnement dans la conf apache pour le serveur local et distant.
Dans apache2.conf à la fin du fichier vous pouvez ajouter ceci
## Setting Environnement variable SetEnv ENV dev // ou prod
Fichier index.php
<?php /* On definit tous les constantes ici comme ca plus besoin de toucher au bootstrap pour un prochain projet*/ define('DIR_ROOT', dirname(dirname(__FILE__))); define('DIR_BASE',dirname(DIR_ROOT)); define('DIR_LIBRARY',DIR_BASE.'/library'); try { require_once DIR_ROOT.'/app/bootstrap.php'; if ($_SERVER["ENV"] == 'dev') { require_once DIR_ROOT.'/app/debug.php'; } } catch (Exception $exception) { echo '<html><body><center>' .'An exception occured.'; if ($_SERVER["ENV"] == 'dev') { echo '<br /><br />' . $exception->getMessage() . '<br />' .'<div align="left">Stack Trace:' .'<pre>' . $exception->getTraceAsString() . '</pre></div>'; } echo '</center></body></html>'; exit(1); } // run Zend_Controller_Front::getInstance()->dispatch();
fichier bootstrap.php
/* Rien de particulier à mettre dans ce fichier Pensez à enlever le dispatch dans le bootstrap, lancer le dispatch dan sle fichier indes.php */ error_reporting(E_ALL|E_STRICT); Zend_Controller_Front::getInstance()->throwExceptions(true); /* Ces 2 lignes sont mis sur debug.php, voi rplus bas */
Et enfin mon fichier debug.php
<?php error_reporting(E_ALL|E_STRICT); Zend_Controller_Front::getInstance()->throwExceptions(true); /* Firebug Db profiler */ require_once 'Zend/Db/Profiler/Firebug.php'; $profiler = new Zend_Db_Profiler_Firebug('All DB Queries'); $profiler->setEnabled(true); $dbWine = Zend_Registry::get("dbWine"); $dbWine->setProfiler($profiler); /* Firebug log */ require_once 'Zend/Log/Writer/Firebug.php'; $writer = new Zend_Log_Writer_Firebug(); $logger = new Zend_Log($writer); Zend_Registry::set('logger',$logger); function fb($message, $label=null) { if ($label!=null) { $message = array($label,$message); } Zend_Registry::get('logger')->debug($message); }
Voilà j'attends vos remarques
++
Dernière modification par alien7 (07-04-2009 14:39:44)
Hors ligne
Salut
je fais déjà ça mais dans un seul fichier
et pas dans le index ni le bootstrap
http://www.z-f.fr/forum/viewtopic.php?pid=16344#p16344
j'utilise en réalité deux fichiers ini
app.ini et un autre fichier qui dépends de l'environement
dev.ini pprod.ini prod.ini etc.
dans app j'ai une entrée
environnement=dev
par exemple
mon bootstrap vas alors charger les divers composants en fonction de la prod preprod dev etc.
je peux ainsi avoir autant d'environnement que je veux.
sans changer une ligne de code
A+JYT
Hors ligne
Oui j'avais deja vu ton post. Mais là ou je voulais insister particulierement est là partie ou l'on met un variable d'environnement dans le fichier apache2.conf ou http.conf, que l'on recupère via un $_SERVER['ENV'].
Ca évite de jongler avec cette variable.
Aussi je voulais montrer le fichier debug.php, ca évite le fichier .ini, ca peut peut-etre interresser certains.
Dernière modification par alien7 (06-04-2009 18:07:21)
Hors ligne
Bonjour,
je set une variable d'environnement dans chaque environnement different (dev, recette prod)
et j'utilise un seul fichier ini comme suivant.
dans le bootstrap :
$environnement = getenv("ENVIRONNEMENT"); if (!$environnement) { die ("variable d'environnement non definie"); } $config = new Zend_Config_Ini('./conf/config.ini', $environnement);
et le config.ini (enfin une petite parti :-) )
[production] db.adapter = PDO_MYSQL db.config.host = xxxx db.config.username = xxx db.config.password = xxx db.config.dbname = xxx debug = false .... [recette] db.adapter = PDO_MYSQL db.config.host = xxx db.config.username = xxx db.config.password = xxx db.config.dbname = xxx debug = false ..... [developpement] db.adapter = PDO_MYSQL db.config.host = xxx db.config.username = xxx db.config.password = xxx db.config.dbname = xxx debug = true ......
comme ca aucun oubli ni changement de code/conf a faire lors des déploiements dans les différents environnement. Etant "tête en l'air" cette solution me conviens très bien .
Dernière modification par ichevc02 (07-04-2009 10:23:27)
Hors ligne
Moi je fais rien de tout ca. J'ai une technique toute bête qui vaut se qu'elle vaut.
Je fais en fonction du nom de domaine. Un truc du style...
$server_name = explode('.',$_SERVER["SERVER_NAME"]); $ext = array_pop($server_name); $domain = array_pop($server_name); // Mise en place des includes path (ou autre ) en fonction de l'extension du nom de domaine switch($ext) { case 'local': //dev... case 'fr': //prod...
Je n'ai donc qu'un bootstrap, et je fais comme sekaijin, un fichier ini par environement.
Hors ligne
ichevc02 ->
Tu fais donc comme moi , getenv('ENV') ou $_SERVER['ENV'] renvoi la meme chose.
Je trouve ca pratique plutot qu'un define("env", 'prod').
Hors ligne
// Mise en place des includes path en fonction de l'environnement
Tes include_path ne devraient pas changer d'un environnement à l'autre. Ces chemins sont sensés être relatifs au positionnement de ton application sur le serveur. Positionnement que tu récupères avec la variable __FILE__ dans le fichier index.php ça te permet de ne jamais avoir à changer ton bootstrap.
Les seules choses qui devraient changer c'est le fichier .htaccess (ou son équivalent) et le(s) fichier(s) de configuration.
A partir du moment où on a un fichier de configuration par environnement, je ne vois plus la nécessité de faire des contrôles d'environnement de type if ($env == 'dev') alors qu'on peut faire if ($config->displayDebug == true) ou if ($config->throwsError == true) ou if ($config->showTrace == true).
D'ailleurs, comment afficher, si nécessaire, le débug, en prod ? Ou en staging, en preprod, en live ou en test si on a défini que l'environnement de debug s'appelait "dev" ?
J'utilise la notation [prod] ... [dev] ... des fichiers INI. L'héritage qu'elle procure est excellent. La multiplication des fichiers de configuration nécessite de répéter, copier-coller, et modifier partout, quand une variable change sur tous les environnements. Ce qui est franchement chiant.
Hors ligne
Moi, encore plus simpe, dans mon fichier index.php Bootstrap("dev");
De toute façon, il faut la changé qqpart cette valeur, donc, que ca soit dans un ini, un .php, ou autre, c'est pareil..
Dans mes ini, j'ai des sections dev, prod et quand nécessaire, j'utilise l'héritage
Hors ligne
C'est pareil tant que tu n'utilises pas de système de versioning (CVS, Subversion, etc...).
Car à ce moment là, tes fichiers en dev et production seront identiques et tu pourras pas modifier un fichier uniquement en dev ou prod sans risquer de l'écraser. Et donc, ça sera bien plus pratique de modifier uniquement le .htaccess qui n'est généralement pas "versionné" car il est vraiment lié à l'environnement.
Hors ligne
Personnellemnt je n'utilise pas de fichier .htaccess je met tout dans le virtualhost. J'utilise aussi subversion donc pas pratique de changer dev en prod comme ferait nORKY, donc ma solution me convient.
Hors ligne
// Mise en place des includes path en fonction de l'environnement
Tes include_path ne devraient pas changer d'un environnement à l'autre. Ces chemins sont sensés être relatifs au positionnement de ton application sur le serveur. Positionnement que tu récupères avec la variable __FILE__ dans le fichier index.php ça te permet de ne jamais avoir à changer ton bootstrap.
Les seules choses qui devraient changer c'est le fichier .htaccess (ou son équivalent) et le(s) fichier(s) de configuration.
Un vieu commentaire qui trainait... En effet mon include path n'est écrit qu'un fois en haut de mon boostrap dans la plupart des cas. Merci pour le rapelle sur __FILE__...
N'empêche que selon les environnements, l'include path peut être différent. Et oui par exemple si j'ai plusieurs applis qui utilisent une librairie (le ZF disons) et que sur mon environnement X ma librairie est commune à plusieurs applis, je la met donc dans l'arbo au niveau parent des applis. Alors que sur mon env Y, j'ai une lib directement dans mon OS (admettont que j'utilise le ZF dans les depots d'ubuntu...) je ne fais vraiment pas avoir le même include path. Ou pas.
Les seules choses qui devraient changer c'est le fichier .htaccess (ou son équivalent) et le(s) fichier(s) de configuration.
Ah tiens, moi mon htaccess change rarement (pour pas dire jamais)
A partir du moment où on a un fichier de configuration par environnement, je ne vois plus la nécessité de faire des contrôles d'environnement de type if ($env == 'dev') alors qu'on peut faire if ($config->displayDebug == true) ou if ($config->throwsError == true) ou if ($config->showTrace == true).
Ben par exemple sur mon appli actuelle j'ai le background de mon site qui change histoire que je sache bien sur quel env je suis. Et donc j'ai un background pour dev, un pour test etc. Il me suffit d'une classe CSS sur mon body certe, mais c'est bien avec une variable de type ENV (que ce soit dans le registre, dans le setEnv ou encore une constante - osef) que je réalise cette astuce . J'envoie pas ma config à la vue hein :p
De toute façon, il faut la changé qqpart cette valeur, donc, que ca soit dans un ini, un .php, ou autre, c'est pareil..
Dans mes ini, j'ai des sections dev, prod et quand nécessaire, j'utilise l'héritage
Moi justement vu que je "switch" de config a partie du nom de domaine de l'appli (ex: j'utilise monappli.max, mes collegues utilisent monappli.collegue1 etc, et apres j'ai monappli.org ou encore .fr...).
Ca marche pour des "sites" evidemment mais du coup j'ai rien a changer. Même quand je fais un export de mon projet du SVN à la prod.
Hors ligne
Mon trunk est toujours en "dev"
Mes tags eux sont en "prod".
Et je sépare la partie "app" de la partie "admin" (configuration apache). La conf d'apache pour moi n'est pas le représentant de l'état dev ou prod de mes applis.
De plus, je ne touche jamais aux apache, ils sont configurer une bonne fois pour toute (comme Mr moox pour les htacess), j'ai un apache sur machine de dev et un apache sur machine de prod configurer différements
Hors ligne
utiliser les propriété de ENV suppose qu'on ai à l'avance tous les cas possible (au moins ceux à discriminer)
que faire lorsque la machine sur la quelle tu as ton dev a pour un projet une valeur pour un autre une autre etc que faire lorsque tu passe de ta plateforme d'intégration à la recette puis à la prod
que faire lorsque tu livre un zip contenant ton application et que tu n esais pas où elle sera déployée
bref env est un truc très bien mais pas sur
j'ai moi aussi envisagé d'utiliser un boot('dev') dans l'index
mais cela implique de modifier du code pour déployer
pour moi l'environnement est un élément de conf il doit se trouver dans un seul endroit avec tous les autre paramètres de conf
alors peu importe qu'on choisisse un fichier ini ou autre chose le truc c'est qu'il n'y ait qu'un point pour la conf
pour moi le fichier ini est un truc connu et facile à utiliser
si je fille un zip et une doc sur me fichier de conf n'importe quel exploitant est capable de l'installer.
pour finir je n'aime pas du tout avoir toutes les conf de tous les environnement dans le même fichier je trouve que c'est bien parce qu'il n'y en a qu'un mais la préprod n'a pas à connaitre les conf de la prod les login pass de la basse par exemple les séparer permet de ne livrer que ce qui concerne la cible.
A+JYT
Hors ligne
sekaijin, tu dis que tu utilises 2 fichiers, mais c'est 2 fichiers sont dans le même répertoires ??
Hors ligne
oui
Hors ligne
Mr.MoOx a écrit:
N'empêche que selon les environnements, l'include path peut être différent. Et oui par exemple si j'ai plusieurs applis qui utilisent une librairie (le ZF disons) et que sur mon environnement X ma librairie est commune à plusieurs applis, je la met donc dans l'arbo au niveau parent des applis. Alors que sur mon env Y, j'ai une lib directement dans mon OS (admettont que j'utilise le ZF dans les depots d'ubuntu...) je ne fais vraiment pas avoir le même include path. Ou pas.
dans l'arbo de mes applis j'ai un dossier library
dans celui-ci j'ai mes dans des dossiers les lib de l'appli
j'ai quelque part sur mes serveur ZF en version x (version courant pour la plateforme) le php.ini contient le chemin de cette version dans le include path
mon boot ajoute systématiquement pour toutes mes applis dans l'ordre
cheminVersMonAppli/Application;cheminVersMonAppli/Library;get_include_path()
ainsi si ZF n'est pas dans le dossier library de l'application il prends celui du système
s'il est dans library il prend celui-là
trois cas se présent
ZF est installé en standard et la version convient à l'appli je ne mets pas ZF dans library et c'est la version système qui est utilisée
ZF est installé en standard mais la version ne convient pas je mets une version compatible dans library et c'est celle-ci qui est utilisée
ZF n'est pas installé e mets une version compatible dans library et c'est celle-ci qui est utilisée
et ce sans changer 1 paramètre ni une ligne de code
A+JYT
Dernière modification par sekaijin (07-04-2009 19:50:35)
Hors ligne
Tout ça dépend de la manière de déployer ses applications. Chacun à sa sauce à ce qu'on peut voir.
Par ici, on n'a pas de zip à livrer et aucune intervention client, donc pas de risque de ce côté là.
Hors ligne
Pages: 1