Discussion :

[awalter1]

Bonjour,
je veux tester mes procédures PHP. J'ai compris que le PHP s'exécute coté serveur. Je lis que pour tester PHP en local il me faut un serveur Apache ...
Je développe avec Dreamweaver 2, l'envoi de mes fichiers vers mon site (ça veut bien dire coté serveur ?) via ftp se fait en un clic. Je ne comprends pas pourquoi j'aurais besoin de tester en local plutôt que directement sur mon site ? et donc installer plein d'outils en plus. J'ai du louper quelque chose.
Merci d'éclaircir ce point.

[aeroth]

si tu est sur windows, il faut que tu sache que php n'est pas installé par defaut, donc tu ne peux l'interpretter.
il faut donc que tu installes wamp ou easyphp (Windows apache mysql php), pour que tu puisse l'interpretter. Attention lis des tuto sur ce que tu installera, car ce n'est pas magique genre tu install et bim n'importe où est ton fichier il sera executé.

[RunCodePhp]

Je ne comprends pas pourquoi j'aurais besoin de tester en local plutôt que directement sur mon site ? et donc installer plein d'outils en plus. J'ai du louper quelque chose.
Merci d'éclaircir ce point.

Tu as loupé quelque chose, c'est certain.
Il y a pleins de (très) bonnes raisons de procéder ainsi, je dirais même que c'est obligatoire.

Même les plus experts ne codent pas sans faire d'erreurs (j'en doute), n'en parlons pas si on ne sait pas trop ou on va, c'est particulièrement le cas lors de la création du site ou de son évolution.

Une autre raison c'est que développer en local c'est très largement plus rapide que de le faire en ligne.
En local il suffit de coder, on actualise ou on pointe sur la page via un lien et ce sera pris en compte immédiatement.
En ligne il faudra d'abord republier/écraser le fichier en question pour après voir le résultat.

Aussi, on est jamais à l'abri d'un bug. Soit dit en passant, aucun logiciel sur cette planète contient aucun bug.
Si un jour on détecte un bug sur le site distant en production, il y a de très forte chance de le remarquer aussi en local, car on prendra soin que tout soit identique (à part les quelques codes de configurations propre à la différence qu'il y a entre local et distant).
Du coup, on pourra rechercher la nature du bug tranquillement chez soit, de trouver ensuite une solution pour le réparer (pas de stresse en somme).
Cette recherche peu se faire sur plusieurs jours, voir même plusieurs mois pour peu que le bug soit vicelard.
Suffit ensuite d'appliquer le même correctif sur le site en production.


Pour que tout soit efficace, il faut toujours avoir une copie fidèle du site en production (y compris une copie de la Bdd s'il y en a une).
Puis une autre version fidèle mais intégrant les config pour tourner en local.
Et enfin la version Alpha ou Beta RC qui tourne en local, celle où on est en train de créer, développer, améliorer, déboguer, etc ...
Ces divers versions permettent de revenir en arrière à tout moment.
On peu aussi conserver une version chaque mois, ou tous 3 mois, tout dépend du projet.
Il existe aussi des Soft permettant de faire un suivi de version (c'est assez particulier cependant).

... etc ... on peu en trouver d'autres de raisons.


Dans tous les cas, agir directement sur un fichier du serveur sans prendre la moindre précaution, c'est à dire sans faire de test/essais c'est 100% "casse gueule".

[awalter1]

Bonjour,
Je suis d'accord sur toutes les précautions nécessaires au développement en ce qui concerne la gestion de conf., les backup, les tests unitaires et autres, je fais moi même du développement en pro, mais qui ne concerne pas la techno web.
Je m'initie au dev. pour le web, dans ce cadre (et uniquement dans celui-ci), mon site n'est pas encore accessible par d'autres (par le fait que mon adresse de site n'est pas connue), donc (à mon sens) je peux mettre à jour ce que je veux et quand je veux. et de plus la mise à jour du site distant est immédiate, c'est pour cela que je me demandais si il y avait une raison technique à tester avec un serveur local. J'en suis à explorer ce qu'il est possible de faire en php, javascript et autre.
Je suis d'accord que lorsque mon site sera en service, je devrais changer ma méthode de travail.
Cordialement

[RunCodePhp]

mon site n'est pas encore accessible par d'autres...
... c'est pour cela que je me demandais si il y avait une raison technique à tester avec un serveur local

Pour ma part ce n'est une raison suffisante pour éviter de développer d'abord en local.

Personnellement je préfère procéder de manière inverse, même dans ce cas là.

Il peu avoir des différences entre ton environnement en local et serveur, je pense même c'est certain, même minime.
Cependant, on prendra quand même soin d'avoir un environnement le plus proche possible, particulièrement pour d'Apache, MySQL et Php.
Pourquoi pas le même OS (linux).


Imagine que tu développes tout directement sur le serveur distant, tout fonctionne bien.
Puis après, une fois installé en local, des bugs apparaissent.
C'est quand même embêtant, non ?
Il me semble qu'il est préférable de savoir le plus tôt possible qu'est ce qui fonctionne d'un coté et pas de l'autre (ou diffère un peu).
Par conséquent, les 2 doivent (ou devraient) se faire en même temps, en parallèle, ou du moins, bloc par bloc, parties par parties.

C'est comme ça que je procède en tout cas. Je me vois mal tout faire soit d'un coté soit de l'autre.

Enfin, je dis ça mais tout ceci reste personnel bien sûr, c'est à toi de voir.

[Benjamin Delespierre]

Par ailleurs, je ne saurais que trop te recommander d'utiliser un système de versions de ton choix (Git, SVN, CVS, Mercurial...) afin de pouvoir travailler sur des expérimentations indépendamment de la branche principale et surtout de conserver un historique des changements. Si tu es seul à travailler sur ton projet et que tu ne veux pas installer un serveur de version, utilise Git.

Je rappelle également que ton environnement de développement doit comporter tous les outils nécéssaires tels que:

• un debuggeur
• un profiler (et un programme pour lire les grinds)
• les différentes version de PHP, d'Apache et de MySQL qu'on trouve en prod
• un framework de tests unitaires
• un gestionnaire de version
• un codepad pour faire des tests rapides
• tous les navigateurs grand public actuels (y compris les vieilles versions)
• un IDE digne de ce nom capable d'intégrer tout ça
• un gestionnaire de tâches

Par exemple, mon environnement se compose de:

• Xdebug (PHP 5.2 / PHP 5.3) (débug)
• Webgrind (profiling)
• WAMP Server (PHP 5.1 / PHP 5.2 / PHP 5.3 / Apache 2.0 / Apache 2.2 / MySQL 5.1 / MySQL 5.5) (runtime environment)
• PHPUnit (tests unitaires)
• Git / SVN (versions)
• http://php.developpez.com/telecharge...-WAMP-Ameliore (codepad / tâches)
• Eclipse + PDT + Aptana Studio + MyLyn + Subclipse + EGit + WDT (IDE / tâches)
• FireFox 3.5 ~ 8.0 / IE Tester (IE 6 à 8) / Opéra / Chrome 12 / Safari (web browsers)

Pour des projets modestes, tu peux zapper le profiling et les tests unitaires, tu n'en aura besoin que sur les projets conséquents.
Arrange toi toujours pour que ton environnement de développement reflète au mieux l’environnement de production, quitte à installer une VM Linux pour faire des tests, sinon tu risques d'aller au devant de belles surprises si par exemple tu développes avec PHP 5.3 et que tu déploies sous PHP 5.1