J'ai passé pas mal d'années à gérer un document de "mise en place de l'environnement de développement", un pavé décrivant pas à pas comment installer Eclispe, Maven et tout ça, jamais à jour et lu en diagonale par les développeurs qui mettaient de toute façon plus d'une journée pour avoir quelque chose de carré.
J'ai ensuite tenté de simplifier et d'automatiser un peu les choses (genre, j'étais committer Maven à l'époque, vous voyez le liens ?). J'ai donc maintenu un gros ZIP avec un JDK, Subversion, Maven, Tomcat et Eclipse avec la conf qui va bien "prêt à l'emploi". C'était un peu mieux, mais ça restait compliqué. Au moins je passais moins de temps sous Word :P
De nos jours, je tenterais de gérer ça avec Chef ou Pupet, mais il faut avouer que, si ces outils font des merveilles sur des serveurs Linux, leur utilisation pour gérer les postes de développement Windows est encore un sujet de science fiction.
Quelle alternative ? Certains (ils se reconnaitront) essayent d'y répondre en virtualisant le poste de développement dans de VM, contraignant les développeurs à utiliser des outils bridés dans un environnement peu réactif.
L'autre piste, c'est l'IDE en mode Web - Codenvy explore cette piste.
Codenvy permet de connecter votre repository github à un IDE web Eclipse-like (histoire de ne pas dépayser le développeur lambda ?). Je l'ai testé avec mon projet codestory, histoire de voir.
L'import du projet maven se passe bien - mieux que sous Eclipse diront les médisants ! L'IDE réagit vite et bien. "Rich Internet Application" réalisée selon les bonnes pratiques, l'UI s'affiche très rapidement et les fonctionnalités sont chargées en tâche de fond. L'inverse du portail de support Zendesk que j'utilise tout les jours en fait ...
Evidemment, les actions proposées dans cet IDE sont loin de ce que permet Intelij Idea. En termes de refactoring par exemple, on ne me propose que de renommer ma classe. Cependant, pour un certains nombre de développeurs que je connais, c'est la seule fonction qu'ils utilisent, donc ça ne gènera pas :P
L'autre intérêt de l'IDE web est sa parfaite intégration avec Git d'une part, et avec la plateforme cible d'autre part. Les wizard Git sont très propres et prendront par la main les développeurs novices. Le déploiement vers un PaaS est également très bien pris en compte. Cet IDE cloud se calle donc parfaitement entre les services d'hébergement de code et les services d'hébergement d'applications.
Après quelques essais, l'IDE n'est pas super réactif mais raisonnablement utilisable. Disons que si j'avais un truc à corriger en express pendant Devoxx je pourrais prendre ma tablette et m'en servir pour corriger et pousser un correctif. Le build est lent et je n'ai pas réussi à lancer mes tests unitaires. Bref, je n'ai pas l'intention d'abandonner Idea.
Pour quel usage ? J'avoue que je me pose la question, car on est tout de même très loin du confort d'un IDE classique, dont la puissance de refactoring et d'assistance sera difficile à égaler (mais ça viendra). Cependant, il y a pas mal de scénarios qui m'ont été soufflés sur twitter :
- les corrections rapides, lorsqu'on qu'on veut "juste" corriger un petit truc vite fait. Le genre de chose qu'on fait actuellement sous Github sans aucune assistance, ici on a un compromis intéressant.
- les langages qui ne permettent ou ne nécessitent pas une foultitude de refactoring complexes.
Pour du développement Java bête et méchant, je reste sceptique à ce stade. Ce que j'aimerais sur un outil de ce type c'est un mix d'infinitest (test en continu) et de seleniumgrid (tests distribués) sur une infrastructure cloud. Autrement dit, à chaque modification les tests de mon project sont lancés en parallèle et j'ai du feedback en quelques secondes maximum.
8 commentaires:
Eclispe, l'IDE qu'on aime tant qu'on ne sait même plus l'orthographier :)
bien vu ! du coup je le laisse comme ça :P
Salut,
Sinon, pour un IDE web, connecté avec github, à la Eclipse, il y a Orion :)
http://www.eclipse.org/orion/
J'ai testé Orion, je comprend rien...
Concernant les IDEs dans le cloud pour autre chose que de l'HTML/JS/CSS, j'y crois pas trop.
Par contre pour la partie front end avec que de l'HTML/JS/CSS, ça peux être intéressant.
Bizarrement, les outils dans le cloud paraissent exactement correspondre à la définition "des outils bridés dans un environnement peu réactif".
Le PAAS pour avoir un Git/Jenkins/Tomcat dans le cloud OK, mais un IDE ?
Quand on voit déjà la réactivité légendaire (*kof*) d'Eclipse sur un poste local pourtant bien musclé...
Bref, je n'y crois pas trop.
Quand à la prochaine étape, ce sont sûrement les développeurs dans le cloud. Oh wait, ça s'appelle l'offshore.
@Olivier taquin va.
Quand je dis "outils bridés dans un environnement peu réactif" je pense à une VM taillée au plus juste par développeur.
Quand je pense xxx dans le cloud, je pense distribution de la charge sur un pool de serveur. Je reprend l'exemple d'infinitest. A moins de coder/tester propre, lancer les test à chaque "save" est douloureux. Si on peut déporter ça sur N machines utilisées "on-demand" ça a du sens.
Et avec cette feature a venir :)
Real time collab a la Google docs
Concernant, l'installation du poste, le client où je suis actuellement utilise un truc génial.
On a un environnement complet qui s'installe via puppet sur nos machine sous Ubuntu. Un coup de chroot et c'est fini.
Nous avons l'IDE de configuré (avec choix Eclipse ou IntelliJ CE) mais aussi un tas d'alias pour git et quelques autres outils.
Quand je suis arrivé, on est parti d'un poste vide et après un café (le temps du déploiement via puppet) je pouvais commencé à coder.
Enregistrer un commentaire