Zend FR

alien7 · 06-04-2009 15:02:55

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

Code:

## Setting Environnement variable
SetEnv ENV dev // ou prod

Fichier index.php

Code:

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

Code:

/* 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

Code:

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

sekaijin · 06-04-2009 17:12:36

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

alien7 · 06-04-2009 18:05:41

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)

ichevc02 · 07-04-2009 10:21:29

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 :

Code:

$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 :-) )

Code:

[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)

Mr.MoOx · 07-04-2009 10:34:29

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

Code:

$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.

alien7 · 07-04-2009 10:53:51

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').

keilnoth · 07-04-2009 11:18:07

// 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.

nORKy · 07-04-2009 11:33:30

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

keilnoth · 07-04-2009 11:51:09

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.

alien7 · 07-04-2009 12:05:32

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.

Mr.MoOx · 07-04-2009 13:10:38

// 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.

nORKy · 07-04-2009 13:17:26

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

sekaijin · 07-04-2009 17:41:29

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

nORKy · 07-04-2009 19:34:34

sekaijin, tu dis que tu utilises 2 fichiers, mais c'est 2 fichiers sont dans le même répertoires ??

sekaijin · 07-04-2009 19:40:45

oui

sekaijin · 07-04-2009 19:49:38

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)

keilnoth · 08-04-2009 00:06:24

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à.

Zend FR

#1 06-04-2009 15:02:55

[Proposition] Bien séparer bootstrap dev et prod

Code:

Code:

Code:

Code:

#2 06-04-2009 17:12:36

Re: [Proposition] Bien séparer bootstrap dev et prod

#3 06-04-2009 18:05:41

Re: [Proposition] Bien séparer bootstrap dev et prod

#4 07-04-2009 10:21:29

Re: [Proposition] Bien séparer bootstrap dev et prod

Code:

Code:

#5 07-04-2009 10:34:29

Re: [Proposition] Bien séparer bootstrap dev et prod

Code:

#6 07-04-2009 10:53:51

Re: [Proposition] Bien séparer bootstrap dev et prod

#7 07-04-2009 11:18:07

Re: [Proposition] Bien séparer bootstrap dev et prod

#8 07-04-2009 11:33:30

Re: [Proposition] Bien séparer bootstrap dev et prod

#9 07-04-2009 11:51:09

Re: [Proposition] Bien séparer bootstrap dev et prod

#10 07-04-2009 12:05:32

Re: [Proposition] Bien séparer bootstrap dev et prod

#11 07-04-2009 13:10:38

Re: [Proposition] Bien séparer bootstrap dev et prod

#12 07-04-2009 13:17:26

Re: [Proposition] Bien séparer bootstrap dev et prod

#13 07-04-2009 17:41:29

Re: [Proposition] Bien séparer bootstrap dev et prod

#14 07-04-2009 19:34:34

Re: [Proposition] Bien séparer bootstrap dev et prod

#15 07-04-2009 19:40:45

Re: [Proposition] Bien séparer bootstrap dev et prod

#16 07-04-2009 19:49:38

Re: [Proposition] Bien séparer bootstrap dev et prod

Mr.MoOx a écrit:

#17 08-04-2009 00:06:24

Re: [Proposition] Bien séparer bootstrap dev et prod

Pied de page des forums