Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Deploiement d'un site

11 réponses
Avatar
M
Bonjour,

Je voudrais savoir quelle technique vous utilisez à la fin d'un
développement sur votre serveur de test pour déployer les fichiers
sur un autre serveur (recette, prod).

Et surtout comment vous gérez les fichiers d'include qui diffèrent
souvent (éléments de connexion à la base de données différents entre
autres) en fonction de l'environnement.

- Faites-vous un ftp de TOUT sauf ces fichiers d'include (avec la
contrainte de devoir filtrer manuellement ces fichiers lors d'un put) ?
- Avez-vous un script personnalisé ?
- Avez-vous un fichier d'include identique qui sait automatiquement
repérer dans quel environnement il se trouve (avec le risque de
trimballer des mots de passe sur tous les environnements) ?

Merci de partager vos solutions.
M

10 réponses

1 2
Avatar
Thief13
Pour ma part, je fait tout les includes en relatif, ce qui permet de
transporter tout les fichier d'un coup, sans me prendre la tete, de
plus, pour les parammetres qui changes en fonction du serveur (base de
donnée...) je fait un petit fichier de configuration, en php (ou en xml,
ces derniers temps ^^) qui contient toutes ces donné, et une foi le site
installé, je n'ai plus qu'a éditer ce fichier. Voilà !
Avatar
CrazyCat
M wrote:
Et surtout comment vous gérez les fichiers d'include qui diffèrent
souvent (éléments de connexion à la base de données différents entre
autres) en fonction de l'environnement.


Je répondrais que tout dépend du site en question et des environnements.
J'ai en fait 3 manières de travailler différentes en fonction du type de
développement:

1) Développement d'un site destiné à être "reproduit": je crée un script
d'installation qui permet à l'usager de créer son fichier de config.
2) Phase de développement: le fichier de config choisit une ou l'autre
des configs en fonction du serveur où il se trouve (et ou de
l'environnement windows/linux).
3) Phase de livraison: mon fichier de config pour le développement
diffère de celui du site de prod, une fois que tout marche bien en local
j'upload tout sauf mon config (le client a le sien), ce qui évite que je
connaisse ses accès.

Pour le 2 et le 3, il faut partir du principe que le serveur de dev
n'est pas d'un accès public et ne sert qu'à valider le site sur un
serveur qui est à l'identique du serveur final du client.
On ne s'inquiète pas que le client connaisse les accès dessus, les
comptes sont normalement temporaires et le contenu est essentiellement
du lorem ipsum :)


--
Discussions et débats sur l'actualité: http://www.sujets-d-actu.eu

Avatar
Bruno Desthuilliers
Bonjour,

Je voudrais savoir quelle technique vous utilisez à la fin d'un
développement sur votre serveur de test pour déployer les fichiers
sur un autre serveur (recette, prod).


Ca dépend de trop de paramètres pour être systématique.

Avatar
M
Ca dépend de trop de paramètres pour être systématique.


Je recherche des pistes ou des idées, pas LA vérité absolue.

J'utilise moi-même plusieurs techniques, mais comme je leur trouve
à toutes un ou plusieurs défaut, je cherchais à voir s'il n'y
avait pas mieux.

Merci à ceux qui ont répondu.

M

Avatar
AxL
M wrote:
Et surtout comment vous gérez les fichiers d'include qui diffèrent
souvent (éléments de connexion à la base de données différents entre
autres) en fonction de l'environnement.


Je répondrais que tout dépend du site en question et des environnements.
J'ai en fait 3 manières de travailler différentes en fonction du type de
développement:

1) Développement d'un site destiné à être "reproduit": je crée un script
d'installation qui permet à l'usager de créer son fichier de config.
2) Phase de développement: le fichier de config choisit une ou l'autre
des configs en fonction du serveur où il se trouve (et ou de
l'environnement windows/linux).
3) Phase de livraison: mon fichier de config pour le développement
diffère de celui du site de prod, une fois que tout marche bien en local
j'upload tout sauf mon config (le client a le sien), ce qui évite que je
connaisse ses accès.

Pour le 2 et le 3, il faut partir du principe que le serveur de dev
n'est pas d'un accès public et ne sert qu'à valider le site sur un
serveur qui est à l'identique du serveur final du client.
On ne s'inquiète pas que le client connaisse les accès dessus, les
comptes sont normalement temporaires et le contenu est essentiellement
du lorem ipsum :)




Bonjour CrazyCat,
comment te débrouilles-tu pour que le script fasse la différence entre
un serveur windows et linux ? Je pensais qu'il existait une var
d'environnment pour cela mais je ne l'aui pas trouvé :
Merci.


Avatar
Thief13
Bonjour CrazyCat,
comment te débrouilles-tu pour que le script fasse la différence entre
un serveur windows et linux ? Je pensais qu'il existait une var
d'environnment pour cela mais je ne l'aui pas trouvé :
Merci.


A quoi sa sert de connaitre le systeème d'exploirtation pour l'execution
du script ?

Avatar
Francois Girault
comment te débrouilles-tu pour que le script fasse la différence entre
un serveur windows et linux ? Je pensais qu'il existait une var
d'environnment pour cela mais je ne l'aui pas trouvé :
Merci.


echo PHP_OS;

--
FG

Avatar
Bruno Desthuilliers
Ca dépend de trop de paramètres pour être systématique.



Je recherche des pistes ou des idées, pas LA vérité absolue.


Oui, mais comme chaque cas est particulier - ou presque...

Au final, on en arrive généralement à maintenir une poignée de scripts
spécifiques à un projet - parfois quelques uns partiellement
réutilisables pour d'autres projets utilisant la même techno.


Avatar
Denis Beauregard
Le 26 Feb 2007 14:52:18 GMT, M écrivait dans
fr.comp.lang.php:

Bonjour,

Je voudrais savoir quelle technique vous utilisez à la fin d'un
développement sur votre serveur de test pour déployer les fichiers
sur un autre serveur (recette, prod).

Et surtout comment vous gérez les fichiers d'include qui diffèrent
souvent (éléments de connexion à la base de données différents entre
autres) en fonction de l'environnement.

- Faites-vous un ftp de TOUT sauf ces fichiers d'include (avec la
contrainte de devoir filtrer manuellement ces fichiers lors d'un put) ?
- Avez-vous un script personnalisé ?
- Avez-vous un fichier d'include identique qui sait automatiquement
repérer dans quel environnement il se trouve (avec le risque de
trimballer des mots de passe sur tous les environnements) ?


Je pense qu'il est préférable, et de beaucoup, de développer de
façon relative, à moins d'avoir une raison pour ne pas le faire
(par exemple, si on ne veut pas faciliter le copiage d'une partie
du site en utilisant des adresses absolues).

Il ne reste alors qu'un petit nombre de fonctions qui soient
réellement dépendantes de la version en ligne par rapport à la
version locale et on peut tout placer dans le même fichier.

Dans mon cas: les mots de passe font partie des fichiers particuliers
à l'installation, mais ils sont toujours dans un autre répertoire,
donc quand je copie tous les fichiers, ces fichiers ne sont pas
touchés. C'est peut-être la solution, surtout si ces fichiers ne
sont pas accessibles par accident.

J'ai développé quelques bases de données avec à peu près la même
structure (un fichier pour poser la question, un fichier pour
recevoir une série de réponses, comme une liste de livres suite à
une requête, ou une liste de couples, et finalement un 3e fichier
pour afficher la réponse détaillée). Je suis relativement
chanceux parce qu'une fois un projet terminé, je n'ai plus à le
modifier sauf en de rares occasions.

Dans un certain projet (plusieurs bases de données avec accès par mot
de passe), j'ai développé ma structure et mis sur Internet 5 bases
suivant 2 modèles. Je me suis retiré et mon successeur, qui se
prenait pour un programmeur, a travaillé comme un pied, interrompant
le service à quelques occasions au lieu de travailler dans un 2e
répertoire. Il a fallu que je lui dise de revenir en arrière et de
se limiter à ce qu'il comprend au lieu de jouer à l'apprenti-sorcier.
Donc, même si on fait une bonne structure relative, lorsqu'on est
remplacé, le suivant risque de cafouiller.


Denis

Avatar
Thief13
echo PHP_OS;


Si vous voulez juste savoir le nom du système d'exploitation, utilisez
plutôt la constante PHP_OS mais gardez à l'esprit que cette constante
contient le nom du système sur lequel PHP a été compilé.


Ce qui signifie que si PHP à été cross compilé sur un linux pour un
windows, il affichera linux, meme si il tourne sous windows...

Je ne trouve pas ça tres fiable...

1 2