Reprise du message précédent :
La machine de dev connectée à un environnement dans le cloud, ça me semble être une fausse bonne idée. Ta connexion internet saute, tu peux plus bosser

Ca c'est pour les déploiements vers les env de recette/preprod/prod.
Qd tu devs avec du Docker ou une VM locale, t'as un rep local qui est mappé dans le container/VM, tu committes pas pour que ce soit visible sinon t'as pas fini.

 
ça, ça me semble un faux bon argument. Quand notre connexion internet saute au boulot, on ne peut plus bosser de toutes façons. Ne serait-ce que parce que on a trop de services qui dépendent déjà du web, emails, slack... Moi je bosse  souvent remotely de toutes façons, donc que les données soient au bureau ou dans le cloud, c'est kif kiif... Sauf que le bureau, il peut être cambriolé, il peut bruler etc...
Je vois pas comment on peut bosser en se passant du cloud en 2016. C'est infiniment mieux qu'avant.
 
Par contre, pour en revenir à xdebug, je viens de regarder et ça semble très compliqué de rediriger le debugger qui est sur une instance EC2 Ubuntu sur le client OSX. On se connecte avec en ssh sur l'EC2 à travers un VPN pour avoir la même IP que ce soit au bureau ou ailleurs, et je n'arrive pour le moment pas à forwarder le port 9000 dans le sens EC2 --> client OSX sous netbeans.
 
 

Sur la JVM non, pas besoin. Et de nouveau, le debugger se connecte à un port réseau donc ça change pas grand chose

Et j'ai pas encore testé mais apparemment Docker sous Windows marche pas mal. Nos projets récents utilisent Play et donc SBT, y a un plug-in qui permet de créer des containers Docker à la volée: d'abord pour reproduire l'environnement cible de manière fidèle, faire passer les tests unitaires, construire le RPM, puis publier le container vers AWS qui sera déployé avant de faire tourner les tests d'intégration.

Et tout ça, ça marche pareil depuis ton PC ou depuis Jenkins, peu importe l'environnement hôte.

 
Avec des technos style vagrant, je ne vois plus l'intérêt d'un serveur de dev autre qu'une VM qui ressemble le plus possible au serveur de prod.
 

 
Parfait exemple du truc que je comprends pas - du dev dans le cloud. Du test/préprod oui, mais du dev???
 

 
Mettre en place un xdebug sur une debian c'est apt-get install php5-xdebug + 2 lignes dans un fichier de conf. Niveau contraintes ça va.

 
- Parce que les données sont safe sur un EC2 et que tu as un cron qui fait une sauvegarde tous les jours ou même toutes les heures si tu veux sur du S3 qui est sur la même infra, le tout super rapidement et pour un coût bien inférieur. Avoir un/des serveurs chez soi ou au boulot, c'est lourd et faut quelqu'un qui s'en occupe (et qui s'en occupe bien).  
 
- Parce que tu peux bosser d'où tu veux et que la sécurité de la connection se définit super simplement (en tous cas sur AWS), que tu as la main sur tout et que tu dois pas faire chier un sysadmin de mes couilles qui va te tanner parce que tu peux pas ouvrir tel port, tel machin etc...  
 
- Parce que tu peux scaler et changer la RAM, les CPUs etc... pendant le développement. Tu arrives pas à la fin comme un con en réalisant que tes perfs sont minables/pas adaptées. La machine sur laquelle tu bosses a strictement les mêmes caractéristiques (hard et soft) que la prod plus tard.
 
Et il y a bien d'autres raisons, mais j'ai la flemme de détailler.. Le serveur de dev au boulot c'est juste pénible et nul par rapport à des trucs comme AWS pour le dev. Et je peux comparer car au boulot on a un serveur de dev qu'on est en train de laisser tomber pour du AWS. On en est à 50% de la migration totale et on respire déjà mieux, on est impatient de le débrancher...

 
1/ Win
2/ localhost WAMP
3/ FTP
4/ var_dump  
 

sinon pour xdebug avec netbeans le tout avec la machine de dev sur AWS fonctionne maintenant, y compris à travers un VPN (qui chez nous est aussi une instance EC2 qui nous permet de nous connecter à nos autres instances EC2).
 
Solution pour ceux qui cherches:
 
sur l'EC2 ubuntu:
 

 
Depuis votre mac ou votre station Linux:
 

 
Et laisser le terminal ouvert, ou mettez en tache de fond avec Ctrl-Z, bg (lje préfère laisser le terminal ouvert sans mettre en tache de fond, car cela je suis sûr de ne pas oublier de fermer le tunnel quand j'ai fini.
 
Et voilà, vous pouvez utiliser xdebug.

Perso j'ai jamais réussi à installer xdebug sur OS X 10.11

(j'utilise pas mamp, j'ai installé php et mysql en séparé)

 
Mais dans ton précédent message tu dis que tu utilises win non ?

 
Tu compares à un serveur de dev, je compare à une VM sur le poste du dev. Mon point vue c'est que le concept de serveur de dev n'a plus de sens avec de la virtualisation moderne...vu d'ici ta solution est un upgrade d'une solution obsolète.
Avec une VM locale tes données sont safe, tu fais les sauvegardes que tu veux, tu as aucun pb de sécurité, et tu bosses d'où tu veux aussi. Un ou deux fichiers de conf vagrant dans le projet et un nouveau dev monte sa VM en 10 minutes, identique à celles de tous les autres. Et c'est encore moins cher que ta solution amazon.

C'était une vanne.

1/ OSX
2/ localhost et VM
3/ FTP ou SVN selon projet
4/ var_dump pr l'instant en backend, chrome pour le JS

Faut pas confondre serveur de dev et preprod.
 
En dev je vois pas l'intérêt de dépendre du net de façon bloquante.  
Les besoins de backup bof. Si t'as tout sur des images Docker ça prend quelques minutes à remonter en local (le plus long étant surtout de remonter les données dans les bases).

 
je ne vois pas plus en 2016 l'intérêt de ne pas en dépendre. Pour moi le local, c'est devenu une perte de temps.

 
Heu non.
 

 
Heu, non plus.
 

 
 
ça oui, mais ici où je vis, tu bosses d'où tu veux aussi avec une connection 4G data illimitée.
 

 
Et le jour où tu peux plus bosser et tu dois passer la main par exemple, le tout dans l'urgence, que tu es plus joignable, que tu tombes dans le coma? Et lorsque tu as tout un tas de services externes qui exigent que tu aies une seule IP (énormément le cas dans pratiquement tous nos gros projets) ? et qu'il y a plusieurs personnes a bosser sur la même instance pour ces raisons (et d'autres parfois)... Il y a des centaines de raisons qui font que les solutions locales puent le fromage.
 
Et pour du dev sur du AWS, le prix est dérisoire.

ben c'est sur que ça dépend si ton appli est standalone ou si elle dépend forcément d'autres apps (un ERP, d'autres WS, etc...) que forcément tu pourras pas avoir sur ta machine
 
je fais mumuse avec Vagrant, c'est sympa, par contr débugguer son script de provisionning shell c'est un poil relou, faut péter la VM et la refaire à chaque fois. Par contre c'est vraiment cool
(y'a mieux je sais, mais rien qui puisse se piloter via windows, ni ansible ni salt ne gèrent un master windows, seuls les minions peuvent etre sous win). Y'a du masterless, mais j'ai pas investigué..
 
y'a 2 trucs contre lesquels je me bas, c'est oh-my-zsh (il veut pas s'installer comme il faut, il s'installe en root bien que je sois dans un script non privileged), et mount.cifs qui m'impose de rentrer un pwd alors que j'en fournis un dans la commande...

8=========>
 

Tout ça pour un job qui te déprime, c'est pas mal.

J'essaye de faire de mon mieux jusqu'à la fin, parce qu'au job suivant je vais leur dire quoi ? que je crame tout avant de me barrer, ou que même si c'est la merde, j'essaye de faire de mon mieux en attendant une meilleure opportunité ?

 
Explique en quoi tu fais mieux sur ton infra amazon. Niveau sécu je vois pas mieux qu'un truc qui peut marcher sur une machine sans réseau, perso.
 

 
Si tu as tout commité y compris la conf vagrant, un checkout + vagrant up et c'est prêt sur la machine de quelqu'un d'autre en moins d'1/2h. Et pareil si tu reprends le projet 2 ans plus tard - pas sûr que ce soit aussi simple avec un serveur de dev hébergé ailleurs et qui aura potentiellement évolué entre temps...
 

 
Ca c'est des contraintes qui ne concernent pas forcément des masses de projets.
 
 

 
...et des centaines qui font dire l'inverse...

 
8==> OK je m'incline    

C'est quoi la box? J'ai eu des soucis avec Vagrant sous W10. Je vais tester une debian jessie 32bit là.

Extraits pertinents du vagrant file :

Du coup la box :
- se provisionne avec Debian 8
- me met la base pour bosser (python, vim, etc...)
- je peux la provisionner depuis Pycharm
- dans Pycharm, je déclare un interpréteur distant, et dans la config run, je mappe le répertoire local (celui dans lequel Pycharm écrit) d:\projets\TestVagrant sur /vagrant/share/TestVagrant, sachant que les 2 répertoires sont synchronisés via CIFS, le répertoire windows est partagé et monté sous linux

0 temps de déploiement puisque les fichiers sont accédés directement sur le partage windows

 
Je bosse dans le train ou l'avion. Je suis bien content de ne pas dépendre du net.

Moi si, un pb de network, wifi, si tu bosses dans l'avion ou le train, si ton ISP fait de la merde, si t'as des soucis de DNS, etc.

Moi je crois pas que je puisse faire quoi que ce soit de productif sans google.

http://codeahoy.com/2016/04/30/do- [...] requently/

ou stackoverflow.

oui, c'est ce que je dis
google ne donne que 3 résultats dans mes rêves : Stack overflow, Github et mozilla dev network.

+ tous les miroirs SO et commentcamarche.net

https://devdocs.io/  pour avoir les docs rapidement  
+ SO /MDN  
 
ET REDDIT QUI EST ABSOLUMENT INDISPENSABLE

Ha oui ? pourquoi donc ? veille techno ?
 
Je l'utilise tous les jours en mode "recréation" mais pas du tout en mode dev.

a ton avis

Et HFR

Pour SO : https://archive.org/details/stackexchange

 
Il y a Dash pour les docs.
 
https://kapeli.com/dash

 
Un soft à télécharger/installer et qui marche que sur les trucs à la Pomme ? euh ok Je vais rester sur http://devdocs.io

 
grave...ce week-end je jouais avec ma VM, c'est juste impossible de faire quoi que ce soit sans net.  Je dois dire que SO (et ses variantes) ont du fournir 80% des bons résultats, avec 10% la doc des outils eux meme, et 10% des blogs de gens ayant fait la meme démarche qui flagguent les problèmes (les plus pointus ont été résolus comme ça)

 
+1