par
naholyr » 03 juil. 2007, 11:03
Il y a aussi la méthode des environnements d'exécution, façon Symfony et autres, qui est assez facile à mettre en place (puisque finalement c'est la même que ce que je disais précédemment, à ceci près qu'au lieu de ne pas écraser le fichier de config sur le serveur de prod, on utilise plusieurs fichiers de conf et plusieurs bootstraps) :
- Tout le code "commun" à tout environnement est placé dans un fichier autre que l'index.php (par exemple "runtime.php") et index.php se réduit à sa plus simple expression :
1. La config
2. Le runtime (qui dépend de la config)
<?php
// Options dépendantes de l'environnement d'exécution (bdd, chemins, etc...)
require 'config/config.inc.php';
// Exécution de l'application
require 'includes/runtime.php';
- On crée un fichier "config-dev.inc.php" qui détermine la config en environnement de dév (localhost), et un fichier "config-prod.inc.php" qui détermine la config en environnement de production. Rien n'empêche d'en créer d'autres
- On crée autant de points d'entrée qu'on a d'environnements :
index.php<?php
require 'config/config-prod.inc.php';
require 'includes/runtime.php';
index-dev.php<?php
require 'config/config-dev.inc.php';
require 'includes/runtime.php';
On n'a alors plus du tout à se soucier de l'environnement : quand je bosse en local j'appelle
http://localhost/index-dev.php et sur le serveur de prod je me contente de supprimer l'accès au fichier "index-dev.php" (en ne l'uploadant pas, c'est le plus simple).
Et la règle d'or c'est que la seule différence entre mon serveur de prod et mon serveur de dév, c'est le fichier de conf utilisé. Tout le reste doit être rigoureusement identique.
On peut se créer autant d'environnements qu'on veut, le fichier de config devrait permettre de régler le niveau de débuggage, les chemins, l'activation ou non des benchmarks, etc...
Il y a aussi la méthode des environnements d'exécution, façon Symfony et autres, qui est assez facile à mettre en place (puisque finalement c'est la même que ce que je disais précédemment, à ceci près qu'au lieu de ne pas écraser le fichier de config sur le serveur de prod, on utilise plusieurs fichiers de conf et plusieurs bootstraps) :
- Tout le code "commun" à tout environnement est placé dans un fichier autre que l'index.php (par exemple "runtime.php") et index.php se réduit à sa plus simple expression :
1. La config
2. Le runtime (qui dépend de la config)
[php]<?php
// Options dépendantes de l'environnement d'exécution (bdd, chemins, etc...)
require 'config/config.inc.php';
// Exécution de l'application
require 'includes/runtime.php';[/php]
- On crée un fichier "config-dev.inc.php" qui détermine la config en environnement de dév (localhost), et un fichier "config-prod.inc.php" qui détermine la config en environnement de production. Rien n'empêche d'en créer d'autres ;)
- On crée autant de points d'entrée qu'on a d'environnements :
[b]index.php[/b][php]<?php
require 'config/config-prod.inc.php';
require 'includes/runtime.php';[/php]
[b]index-dev.php[/b][php]<?php
require 'config/config-dev.inc.php';
require 'includes/runtime.php';[/php]
On n'a alors plus du tout à se soucier de l'environnement : quand je bosse en local j'appelle http://localhost/index-dev.php et sur le serveur de prod je me contente de supprimer l'accès au fichier "index-dev.php" (en ne l'uploadant pas, c'est le plus simple).
Et la règle d'or c'est que la seule différence entre mon serveur de prod et mon serveur de dév, c'est le fichier de conf utilisé. Tout le reste doit être rigoureusement identique.
On peut se créer autant d'environnements qu'on veut, le fichier de config devrait permettre de régler le niveau de débuggage, les chemins, l'activation ou non des benchmarks, etc...
