Discussion :

[sam01]

Bonjour,

j'aimerais tester une nouvelle fonctionnalité de mon site web. Actuellement, les pages de mon site son dans le dossier:
indd_html

J'aimerais tester la totalité de mon site (l'évolution que j'ai faîte), avant de le mettre en ligne réellement. Mais j'aimerais que mon site actuel continue de fonctionner pendant que je fais mes tests sur le nouveau site qui lui comporte des évolutions.

Au niveau base de données, je n'ai pas de souci, je duplique ma base de données avec un autre user et mot de passe.
mais pour les pages php, quelle est la technique utilisée en général. Faut-il créer un sous-dossier de indd_html et
mettre dedans le nouveau site à tester. Mais comment empêcher les internautes d'y accéder ? merci d'avance pour
votre aide.

[lllhuhdklll]

L'idéal est de créer un autre dossier comme par exemple "indd_html_test".

Au niveau de la sécurité, si vous utilisez un espace membre, il suffit de se connecter pour voir la page d'index.

Si non, je ne vois pas, ou alors votre hébergeur dispose peut-être d'une option pour cacher un dossier.

[bob633]

Personnellement, je trouve ta méthode bancale.

Lorsque tu diffuses ton site sur internet, c'est qu'il est censer être en production, autrement dit visible et exploitable par les client finaux.

Si tu fais des modifications, c'est que le site repasse en mode développement (ou évolution dans ton cas). Hors les tests ne se font pas en mode production, mais bien en développement.

Tu as dû développé ton application en local j'imagine ?
Pourquoi ne fais-tu pas tes tests en local, et une fois que c'est OK, tu transfères le delta en prod ?

Ca à l'avantage d'avoir une production propre, avec seulement la/les BDD / fichiers utiles au bon fonctionnement initial.

[ABCIWEB]

Tu as dû développé ton application en local j'imagine ?
Pourquoi ne fais-tu pas tes tests en local, et une fois que c'est OK, tu transfères le delta en prod ?

Ca à l'avantage d'avoir une production propre, avec seulement la/les BDD / fichiers utiles au bon fonctionnement initial.

Oui moi aussi je pensais que tout le monde faisais comme cela. Et normalement quand c'est suffisamment testé en local, les derniers tests sur le web ne peuvent pas mettre en cause la stabilité de l'application. Tu as des contraintes particulières ?

[RunCodePhp]

Salut

Dans la majorité des cas j'adopte le même principe évoqué plus haut, c'est à dire de faire le développement en local avec pleins de test (au moins les parties qui ont été modifiées), et dans la majorité des cas, une fois validé et mis à jour sur le site en production c'est satisfaisant.

Ceci dit, il faut au moins que l'environnement en local soit le plus proche possible de celui distant en production, sinon on risque d'avoir des (mauvaises) surprises.

Je me souviens d'un bug lié à une version de Php un poil (ou cheveux) plus récent en local (XMLWriter) qui faisait que tout fonctionnait bien en local mais pas coté distant.
Donc faut voir.


Rien empêche de créer un site miroir pour les test tournant en parallèle sur le même serveur distant.
Pour cela tu pourrais très bien créer un sous-domaine de ton domaine, genre test.domaine.com, sans compter que tu peux aussi faire en sorte qu'il y ait une authentification pour ce site de test (.htaccess/.htpasswd par exemple).

(Si ton hébergeur ne te permet pas de faire ce genre de chose, faudra alors se poser des questions sur la qualité des services offerts par cet hébergeur.)

[sam01]

Bonjour RunCodePhp, ton idée de sous-domaine me plaît pas mal.
Je ne savais pas trop à quoi ça servait, mais si je peux m'en servir pour tester l'évolution de mon site, ce n'est pas de refus.
Si j'ai bien compris le principe du sous-domaine, mon site : www.example.com
aura un sous-domaine qui sera accessible via l'url : test.example.com ? c'est bien ça.

Ensuite, je dois copier tous les fichiers dans mon répertoire /home/example

Est-ce que le sous-domaine : test.example.com sera référencé par google si je le laisse longtemps actif ?

[bob633]

Oui moi aussi je pensais que tout le monde faisais comme cela. Et normalement quand c'est suffisamment testé en local, les derniers tests sur le web ne peuvent pas mettre en cause la stabilité de l'application. Tu as des contraintes particulières ?

Pas de contraintes particulières.

Je ne suis pas dev Web de métier mais plus .NET. Je bosse sur des applis qui demandent des recettes assez poussées, et vis à vis d'un client, il est impossible de faire des tests sur un site de production. Bien entendu, lorsque l'appli est en ligne, on est forcer de faire un premier test de mise en route voir le bon fonctionnement.

Et bien je préfère appliquer cela partout, même dans mon dev web, afin d'être rigoureux sur les démarches. On sépare ainsi les tests du cas réel.

En achetant une voiture, le vendeur vient pas faire les 1000 premiers kilomètres avec toi pour voir si le moteur tient ou pas.

C'est juste une question de principe, moins des contraintes

Après si ton hébergeur permet d'avoir plusieurs BDD, alors en effet un sous domaine peut être une solution ... même si je ne reste pas partisan de la méthode de tout mettre en prod sans avoir effectuer des tests utiles en local

[gene69]

Tu as dû développé ton application en local j'imagine ?
Pourquoi ne fais-tu pas tes tests en local, et une fois que c'est OK, tu transfères le delta en prod ?

parce que des tests sur une plateforme de dev, c'est pas des tests d'intégration & qualification, je suppose.

.htaccess peut venir a bout d'un cas comme ça.

[bob633]

parce que des tests sur une plateforme de dev, c'est pas des tests d'intégration & qualification, je suppose.

L'auteur n'a pas testé en local. Il veut une solution pour tester directement en prod, en ayant une solution pour séparer le test / prod.

Puis des tests se font sur le dév, une fois validée sur l'intégration et une fois validée sur la prod.

[sam01]

Oui, c'est bien ça.
J'aimerais me créer un environnement le plus proche de la production.
Je créer donc une base de données identique et je duplique mon répertoire de production que je protège vian un .htaccess et un .htpassword.
Je cré un sous-domaine et le tour est joué. J'ai un environnement de test pratiquement identique à mon environnement de production.

[ABCIWEB]

Pas de contraintes particulières.

Arf excuse moi je t'ai induit en erreur. Ma question concernant les contraintes particulières était à destination de sam01 (qui a répondu depuis).

[RunCodePhp]

Je créer donc une base de données identique et je duplique mon répertoire de production que je protège vian un .htaccess et un .htpassword.
Je cré un sous-domaine et le tour est joué. J'ai un environnement de test pratiquement identique à mon environnement de production.

Exactement.

A mon sens il n'y a pas plus proche que d'utiliser le même serveur (Apache, Php et MySQL, et l'OS aussi).

Attention tout de même d'éviter de mettre "à genoux" ton serveur en faisant je ne sais quoi.
Vu que le site en prod utilise le même serveur Web, tu le mettras lui aussi HS.


Puis si tu mets un .htaccess .htpasswd, donc une authentification, un moteur de recherche ne pourra pas récupérer de contenu.


Puis normalement un moteur de recherche ne peu (théoriquement) pas demander un contenu où il n'existerait pas l'ombre d'un lien pointant vers celui-ci.
Ce qui veut dire que si par exemple tu ne mets aucun lien de www.exemple.com vers test.exemple.com, google ne saura jamais que test.exemple.com existe.

En faite, le .htaccess .htpasswd n'est pas vraiment pour éviter un éventuel référencement d'un moteur de recherche, mais plus pour faire barrière d'un éventuel hacker/pirate, d'une personne humaine malintentionnée quoi

D'ailleurs, utiliser un nom de sous-domaine un peu tordu (au lieu de "test") serait encore mieux (on est jamais assez prudent).

C'est la même chose quand on crée une partie admin, faut éviter de l'appeler "admin".

[sam01]

Merci pour tes précieux conseils RunCodePhp.