Reprise du message précédent :

Pourquoi local ?
Comment faire pour être sûr à 100 % que l'environnement local se comporte de la même façon que le distant ?
En particulier quand Windows local /Linux distant...

En ayant le même environnement à 100%

Mais sur la majorité des projets, avoir le même environnement à 90% est largement suffisant.

On peut tester l'URL-rewriting Htaccess etc, sous windows ?

Moi mon dev et mon prod sont tous en distant, comme ça je suis sûr d'avoir deux copies identiques... (et de plus j'ai besoin d'un accès au données du serveur (fichiers) commun aux deux, + accès distant à d'autres sites (banque))

 
J'ai un serveur de test qui est dans la salle des serveur , juste en dessous du serveur principal  
 
j'ai donc besoin de transferer des fichiers par ftp
 

therEDLED > Apache réagira de la même manière que tu sois sous windows ou sous linux (sur à 99%)
 
mysql réagira aux requêtes de la même manière sous windows ou linux dans 99.99% des cas (peut être une légère différence avec les requêtes d'accés aux fichiers, genre les "LOAD DATA INFILE" ) et les réglages seront les même (attention aux limitations des systèmes de fichiers)
 
php a quelques différences entre windows et linux (par exemple, seule la version windows sait contacter un serveur smtp distant quand on utilise la fonction mail) A par au niveau de la configuration, rien ne change entre la version windows et la version unix.
 
 
 
En fait, si tu fais du php avec apache et mysql, les principaux changements seront les outils accessible par des exec et autres fonctions qui font appel à des programmes ou des scripts externe au langage.

 
Etant donné que :
 
Je change souvent de machine,
Les modifications de la base sont nombreuses,
Et quand j'ai juste a changer un accent ou rajouter un champ, je m'embete pas avec le local, je change direct sur ftp, malgré les risques que cela peut comporter

 
surtout que quand je bosse sur ftp, je bosse sur une version beta (qui doit etre online pour montrer au client final )

tomsoft > Ta façon de faire doit rappeller des choses à pas mal de monde ici ... surtout des choses du genre "putain j'ai foiré le 'where' de mon update".

 
Mais tes fichiers ils sont pas versionnés ?

Marrant, j'essaye de créer un fichier .htaccess là, et windows est pas fan
Et puis sinon ya d'autres raisons que j'ai déja citées
 

 
C'est trop trop apache qui s'occupe de créer les fichiers .htaccess et c'est trop trop un truc compliqué de googler 4sec pour trouver comment on fait.

Pour faire de l'url-rw en local ?
 
Parce créer un fichier htaccess sous linux je sais faire

 
pourtant ça marche...
 
et selon les bases, t'as pas envie d'aller péter la prod...
 
sur le projet où j'étais stagiaire, on avait les environnement suivants :  
-dev local (websphere de la machine), pointant sur BDD de dev + SAP de dev + IMS de dev
- serveur DVPT, pointant sur BDD de dev + SAP de dev + IMS de dev
- serveur de TEST, pointant sur BDD de test+ SAP de test+ IMS de test, réplique de prod rafraichie avant les tests d'intégration pour les bases et SAP/IMS, et MAJ du dev après freeze du code
- serveur de recette client, pointant sur BDD de test+ SAP de test+ IMS de test, réplique de prod rafraichie avant les tests fonctionnels pour les bases et SAP/IMS, et MAJ depuis TEST après fin de tests d'intégration
- serveur de MAINTenance, pointant sur BDD de maint+ SAP de maint+ IMS de maint, réplique de prod rafraichie tt les jours, uniquement pour la maintenance
-2x serveur de prod, pointant sur BDD de PROD+ SAP de PROD+ IMS de PROD
 
bon c un peu extreme, mais qd une modif arrivait en prod, elle avait fait tout le chemin...
 
et t'avais pas le "ooops, j'ai oublié mon where dans mon delete"

 
le monsieur veut dire que linux ou windows ca change absolument rien au problème là...si ton .htaccess foire sous win y'a des chance qu'il foire aussi sous nux, ou que tu l'as pas mis au bon endroit

nan mais je parle du nom ".htaccess", pas du contenu.

Ca c'est pas un problème d'apache mais de l'explorateur de fichier d'XP. Si tu crées le fichier depuis le bloc note il te dira rien et le fichier sera créé. Si tu le crées depuis une session dos, il te dira rien et le fichier sera créé (j'ai fait les deux tests à l'instant. )

Bien sur
Tu peux même overrider l'url de prod

Comprend pas, si c'est un serveur de test tu déploies d'abord dessus avant de deployer sur le serveur de prod non?
 
Ou sinon, j'ai rien capté
 

-Si t'as tout versionné, tu peux checkout/clone de n'importe quelle machine
-Ton versionning c'est donc le backup du ftp?
 
Si tu bosses tout seul, ok, à la limite, mais à plusieurs c'est juste une blague

je suis seul, a bosser pour le frangin sur de l'ecommerce.
 
Tiens d'ailleurs, vous trouvez ca comment le theme graphique (en tt cas, lui il adore ) :
 
http://beta.furiagear.com
 
Si c'est consideré comme du spam, je virre

j'arrive pas à lire le titre du site, encore moins le sous-titre.
L'effet reflet ne "fonctionne pas" pour moi (je vois que t'as essayé de le faire, mais je vois aussi que c'est raté, la demarquation centrale est trop prononcée on dirait ); les fleches rouge pur dans les menus sont bcp trop lourdes visuellements (et le bord rouge des carrés tappe trop fort).

pour le titre, on reflechit encore quant a la couleur de police, et c'est pas un relief qui est voulu, mais juste une bordure pour mieux lire
 
et je vais tenter d'estomper un peu le rouge

les flèches rougent me gènent pas, mais le titre se démarque pas du tout du fond...

 
Du verbe rouger

 
le titre c'est prevu de changer, peut etre estomper le header et laisser le titre "a fond" pour les fleches, ben je sais plus trop la

Je bose sur un intranet/CMS/machine a fusion froide

le serveur de test ( machine physique ) est un clone du serveur de prod niveau configuration . Ce n'est pas ma machine , mais bien une machine, en salle serveur, prete a remplacer le serveur de prod en cas de gros pet
il heberge deux serveurs apache dans deux arborescence differentes

• une est celle sur laquelle je bosse ( ALPHA)
• une autre est une réplication régulière de la base de prod : base SQL , fichiers, configuration ( meme les chemin sont identiques a la version en prod )  ( BETA )

une fois une modif faite, je la réplique sur le base BETA, pour voir le comportement en utilisaiton normale

et de la base beta , je repique sur la prod.

ca c'est le fonctionnement normal

mais en cas d'urgence, il m'arrive d'intervenir directement sur la prod.

pour l'instant, et au risque de faire hurler les gens, pas de versionning. Mais c'est prévu pour bientôt.
Ceci dit, j'ai des sauvegardes régulières de mes fichiers : PROD est sauvegardé tous les jours, ALPHA toutes les heures ( il n'y a que des fichiers *.php , c apese rien )

J'espère bien, htaccess c'est un problème d'apache, windows s'en contrefout

J'vois pas en quoi avoir tout en distant t'assure que les copies sont identiques, faut encore les synchroniser, avoir tout le projet versionné et utiliser les numéros de rev ou des tags, ça ça assure que les copies sont identiques  

Chez nous on SSH dans le serveur et on update sa copie locale du projet  

Raison de plus pour que tout soit versionné
Et pour avoir un projet self-contained avec un build propre histoire que ça soit déployable en 5mn.

C'est cool, comme ça le client voit en direct quand tout explose

comme y dit le sieur omega

Ca c'est via le fichier host, pas le htaccess  

Ben raison de plus, si t'as déjà 2 serveur de test tu rajoutes un poste local pour ton boulot, ALPHA te sert de serveur de test perso (test de tes modifs en environnement de prod), BETA devient le serveur de recette pour le client, le chef, la QA, ... et tu gardes la prod.

J'ai toujours du mal avec les trucs "prévus pour bientôt"
 
Entre autres parce que dans ma boite actuel, dans mon ancienne équipe (l'équipe front web) le SVN ça a été "prévu pour bientôt" pendant 3 mois et au final on a fini par se coller un serveur SVN sous un bureau en skunkworks parce que le chef était un boulet
 
Avant d'apprendre qu'on aurait en fait pu utiliser le serveur SVN des ingés, mais que notre cher cheffe ne s'était en fait jamais renseigné
 
Et franchement, quand on voit qu'avec des outils comme Mercurial ou Git la mise en place du versioning même ça prend environ 5mn (ajouter 1h ou 2 pour acquérir la base si on a jamais utilisé de SCM), franchement je vois pas comment on peut trouver des excuses au fiat de ne pas utiliser de gestionnaire de révisions

Le versionning ca gere des modifications sur des fichiers faites par plusieurs personnes en meme temps? (ou au minimum des modifications sur  plusieurs fichiers d'un meme projet)
 
Tout ca sur un serveur local (win server 2003) où sont stockés tout les fichiers (serv de dev), on garde rien nos stations de travail (win xp pro).. avant d'envoyer ca en prod (linux)
 
Je pose cette question dont la reponse sera peut etre "bha oouais ou est le probleme ?" mais le dev qui s'en occupe à l'air de rencontrer quelques difficultés..
 
merci

Les Revision Control System permettent:

• De conserver une trace de toutes les modifs (explicitement enregistrées, naturellement, les modifs non commitées ne sont pas vues)
• De grandement faciliter la communication et la synchro entre des développeurs multiples, y compris dans des environnements différents
• De garder un nombre illimité de machines en synchro.

Pas compris, vous bossez tous sur le même serveur sur les mêmes fichiers en même temps? Ca vous pête pas à la yeule 3 fois par jour genre A écrase le fichier que B venait de finir de modifier?

c clair qu'un SVN ça se met en place en une aprèm, formation des users comprise...

mais dès le lendemain, tu comprends pas comment t'as pu bosser sans...parce que ça résoud les problématiques suivantes :

• Roger a fait une super IHM, et moi un BackOffice qui roxxe, comment qu'on les merge proprement ?
• Ah merde, dédé a fait une super modif sur mon backoffice, comme qu'on fusionne le lot ?
• (4j après) : hum, finalement la version au 23/11 était mieux pour l'IHM, par contre on veut garder le backoffice de maintenant...comment faire un rollback juste d'une partie du code sans que tout pète ?
• Mais bordel qui est le con qui a commité cette merde ? (svn blame, la joie des équipes de dev )
• en prod on va laisser la version actuelle et la maintenir, mais on voudrait bien commencer à bosser sur la versions suivante...comment gérer x versions en //...sachant qu'on veut bien sur que les failles critiques découvertes en prod voient leur patchs appliqués à la version de dev

a plus de 2 developpeurs c'est impossible de bosser sans, à moins d'adorer perdre des journées entières à fusionner du code et voir pkoi ça marche pas

 
Le client c'est mon frere, il me paye quasi rien, donc il peut se permettre de voir les erreurs    

Je parle pas de SVN, SVN ça se met pas en place en 5mn montre en main. SVN c'est pour les gens qui n'ont pas le courage de sortir de leur IDE (ce avec quoi je ne suis pas du tout d'accord), ou qui ont déjà une codebase là dessus et ne veulent pas avoir à supporter 15 outils différents (ce que je comprend parfaitement par contre)

 
OK merci
 
heu en fait ouais on bosse direct sur les fichiers sur le serveur.. En 6mois c'est arrivé qu'une seule fois qu'on bosse exactement sur le meme fichier en meme temps (ca a bugé bien sur) ..
Nos projets eclipse pointent donc sur le fichier sur le serv.. si on fait une modif, Ctrl-S, Alt-tab F5, on voit la modif dans la seconde..
 
Bref on trouve ca bien pratique (a part le fait de bosser sur le meme fichier en meme temps, mais ca ca peux degager de l'equation tellement c'est rare), le seul truc c'est qu'a part les sauvegarde tous les soirs, ya pas de versionning..

Tu bosses sur un version distante à défaut de versionning non? Parce que y'a rien de plus chiant que de devoir uploader à chaque modif

J'ai jamais dis le contraire

Si tu bosses avec des gens qui flippent pas à la moindre ligne de commande autant mettre un truc mieux que SVN

 
Chez nous c'est :  
- dev en local, fichiers versionnés sous SVN
- un serveur de recette chez nous
- un serveur de recette chez le client
- un serveur de pre-prod identique a la prod (meme url, tout pareil) mais accessible seulement via proxy
- puis le serveur de prod

serveur de recette ca correspond/sert a quoi ?

heu je vois pas en quoi SVN oblige à utiliser un IDE...c'est sur que c cablé pour (t'as les fonctions de synchronize, le diff graphique et tout, ça rend très productif d'utiliser ce genre d'outil dans un IDE), mais tu peux en ligne de commande, et si t'es réfractaire, y'a TortoiseSVN
 
sachant que c'est le standard qui remplace CVS, et que Step 1
 
et tu parlais de quoi du coup ? tu fais ton versionning à la main ?
et si SVN ça se monte en 5min, c'est boulversant de connerie à mettre en oeuvre (avec un repository tt con, adossé à Apache ça prend allez 30min de plus, et je suis gentil)
je l'ai fait dans la boite où j'ai fait mon stage de maitrise, en une aprèm j'ai fais l'install du serveur avec l'authentification gérée par Apache, la doc utilisateur de base, et la formation de 3 users...
 

c un serveur en config de test, sur lequel le client (et toi avant) déroule les tests fonctionnels, et fait en gros la recette de ton livrable, cad vérifie que ce que tu livres est conforme aux specs...

Ben ça sert à recetter, c'est pour le marketting, la QA et le client: quand on arrive à une version stable/livraison (ce qui peut être aussi fréquent qu'après avoir terminé chaque tâche d'une todo ou aussi rare qu'après avoir terminé l'intégralité des devs à faire pour l'itération) on update le serveur de recette chez nous, le marketting/la qa/autre peuvent tester si ça correspond bien à leurs demandes (donc aux demandes client filtrées par eux, un truc du style). Si c'est le cas c'est validé de notre côté, ça passe sur le serveur de recette du client (nb: le client peut aussi recetter sur la boite, mais ça veut dire qu'il aura accès à la même chose que la QA, donc potentiellement des bugs que la qa n'aura pas encore eu le temps de catcher), si le client valide ça passe en pré-prod (pour refaire une QA mais sur une config exactement identique au serveur de prod, juste au cas où) et quand c'est validé en pré-prod c'est poussé en prod.

Je sais pas où t'as lu ça, parce que c'est sûrement pas ce que j'ai écrit.

Le cobol aussi c'était un standard
C'est pas un argument ça, c'est un "je me cache le cul et j'veux pas prendre de décision alors que fais comme tous les autres

Et alors?

Tu serais pas un peu beaucoup fatigué? Je te suggère de relire mes posts sur cette page, je suis sûr que tu vas vite réaliser à quel point ta question est débile.

Voilà. Faut installer apache, faut installer mod_svn, faut créer le repo et faut configurer le repo. Ca prend plus de 5mn

poste des trucs intelligibles alors
 

je vois pas pourquoi, cf ma réponse
 
en fait je comprends pas où tu veux en venir dans ta réponse...si tu parles pas de SVN tu parles de quoi ?
 

 
- Install de TortoiseSVN
- Choix d'un repertoire sur un share disk
- Right click > Tortoise SVN > create repository
 
Si tu mets plus de 5 minutes pour faire cela, t'es mauvais. Les configs Apache et autre, c'est juste necessaire si t'as besoin de partager a l'exterieur, et encore...

  Thx !
 
Sinon question CMS: je vais me pencher dessus.. lequel prendre ?
 
Quitte à apprendre a utiliser un CMS autant directement tapé dans le lourd meme si c'est complexe..
 
Bref, y'en a t'il un au dessus du lot? (symphony ?)
 
merci

Il parlait de Mercurial/Git

symfony n'est pas un CMS c'est un framework de développement