TFS pour Java-mauvaise idée?
nous considérons TFS pour nos projets basés sur .NET et comme une plate-forme de gestion des tâches. Certaines équipes se développent exclusivement en Java et sont très satisfaites de SVN (Subclipse).
nos gestionnaires ont formulé les questions suivantes:
- devrions-nous migrer les équipes Java vers TFS aussi?
- TFS (source control only) gère-t-il bien les projets Java?
- est-ce une douleur de migrer notre Java base de code et historique de Subclipse à TFS?
Actuellement, nous envisageons d'utiliser TFS comme plate-forme de contrôle à fournisseur unique pour des raisons de maintenabilité. Nous aimerions éviter que nos informaticiens prennent en charge plusieurs systèmes.
Merci
6 réponses
divulgation complète, je travaille sur l'équipe qui écrit L'outillage Java pour TFS alors prenez cette réponse comme biaisée de manière appropriée : -)
en ce qui concerne TFS - tous les codes sont créés égaux. C'est juste octets dans les fichiers qu'il vérifie dans le contrôle de version. Comme tous les systèmes SCM, il ne se soucie pas de la langue dans laquelle les fichiers sont écrits.
Microsoft fournir un complet, riche TFS Plug-in pour Eclipse (appelé Team Explorer Partout.) Cela fournit le contrôle complet des sources, le suivi des éléments de travail, la construction, sharepoint, l'accès aux rapports etc dans TFS à partir des IDE basés sur Eclipse. Il est écrit en 100% Java et parle directement aux services web exposés par TFS.
en outre, nous fournissons également un client ligne de commande multiplateforme pour TFS afin que vous puissiez parler à TFS à partir de la ligne de commande sur votre système d'exploitation de choix (Mac, Linux, Solaris, HP-UX, Aix, etc tous entièrement pris en charge).
enfin, si vous avez des outils écrits en Java qui veulent parler à TFS, ils peuvent utiliser le SDK TFS pour Java qui est l'API complète que nous avons utilisé pour créer le client Eclipse integration et la ligne de commande multiplate-forme, mais empaqueté avec des échantillons et des extraits et prêt pour vous redistribuer avec vos applications.
quand il s'agit de construire vous avez un couple de choix. Si vous voulez coller avec votre construire le serveur alors il est probable que cela supporte déjà le fait de parler à TFS (ce que font tous les serveurs de construction open source populaires). En plus de cela, Microsoft fournit le TFS Build Extensions qui vous permettent d'exécuter Ant ou Maven basé construit sur le serveur de construction de la fondation de L'équipe. Les résultats de compilation (ainsi que les avertissements ou les erreurs) sont publiés dans TFS avec les données de test de JUnit si vous exécutez des tests de JUnit dans le cadre de votre Compilation. Aussi, vous obtenez de créer et de gérer les définitions de build dans L'IDE Eclipse et ont un endroit pour gérer l'accès à eux, etc.
So - Le niveau de support pour Java est très élevé et Microsoft a montré des investissements constants dans ce domaine. Nous avons récemment envoyé quelques outils D'alimentation TFS 2010 pour Eclipse et nous avons également envoyé des versions de prévisualisation de Team Explorer Everywhere 11 aux côtés de Team Foundation Server 11 (Nous sommes la même équipe au sein de la société).
à importer l'historique de SVN, c'est la même chose que importer l'historique de n'importe quel outil SCM dans TFS (ou TFS dans n'importe quel outil SCM). Vous avez plusieurs options. Vous pouvez prendre un instantané et couper à un point particulier (comme une version) ou vous pouvez migrer l'histoire. Pour migrer l'historique de SVN il y a quelques solutions partenaires disponibles, dont une de migration opportune avec laquelle j'ai vu beaucoup de clients avoir du succès.
Espère que ça aide.
après un an de travail sur un projet Java/JVM en utilisant TFS, je voudrais dissuader quiconque de le faire. Alors que TFS peut être considéré comme le top-of-the-line pour les développeurs.Net, vous ne trouverez pas de développeurs Java avec une expérience avec elle. Il y a le plug-in pour Eclipse et un port pour IntelliJ, mais j'ai eu de la malchance avec les deux, bien que je devine que c'est principalement parce que TFS ne fonctionne pas comme les autres VCS que j'ai utilisé.
dans notre équipe, nous avons estimé un 10-15% frais généraux en raison de TFS et les complications causées par elle. Jours de travail perdus parce que TFS a décidé de réécrire des fichiers, jours de problèmes de dépannage causés par des mises à jour incomplètes de TFS. Nous avons fait une branche en 6 mois parce que toute l'équipe a perdu deux jours la dernière fois que nous l'avons fait. Il est courant d'entendre la phrase "je viens de mettre à jour avec vos derniers changements, pouvez-vous venir vérifier pour vous assurer que rien n'a disparu dans la fusion?". Au lieu d'utiliser Jira, nous sommes bloqués en utilisant le terrible problème-tracking dans TFS, provoquant plus encore plus de questions.
plusieurs développeurs de l'équipe ont utilisé git, soit de manière autonome, soit sur le pont git-tfs. D'autres se contentent de copier l'arborescence des sources avant toute activité "risquée", comme la mise à jour ou la vérification.
de toute façon, je ne le recommande pas pour une équipe qui n'a pas d'expérience avec elle...
j'aime beaucoup la réponse de @Martin_Woodward, mais elle est trop biaisée à mon avis, donc j'ajoute mes 2 cents ici. Dans notre entreprise, nous sommes dans une situation similaire, et la décision (à mon avis) dépend du contexte. Je peux voir 3 situations différentes, et les décisions peuvent être différentes dans chacune d'elles:
- vous développez principalement des solutions .NET, et les parties Java sont intégrées dans les solutions .NET.
- vos solutions .NET sont indépendants développés à partir des solutions Java, et ils sont moitié .NET, moitié Java.
- la plupart de vos solutions sont développées avec Java, et seul un petit pourcentage est développé avec .NET
Je ne suis d'accord avec Martin que dans le premier cas. Vous profiterez de l'environnement de développement commun, du contrôle du code source, du processus de construction ... Vos gars de Java vont apprendre les différences avec le contrôle Source de TFS (a-t-il un nom??). Et votre avenir sera brillant ;-)
si vos solutions .NET et Java sont indépendantes l'une de l'autre, le seul argument à utiliser TFS pour développer des solutions Java est le coût d'exploitation. Et vous devriez regarder attentivement, si les économies réalisées pour exploiter l'environnement de développement seul TFS compense le coût supplémentaire de la conversion de vos projets Subversion en TFS.
Dans le dernier cas, ce serait une terrible décision de passer avec beaucoup de les gens ont juste un environnement commun à développer. Vous pouvez intégrer Subversion dans VisualStudio (en utilisant par exemple VisualSVN ou d'autres plugins), et vous n'avez pratiquement aucun invest.
la migration du code source incluant l'historique est normalement une douleur, et cela dépend de la source et de la cible si cela fonctionne bien. Nous avons de bonnes expériences avec CSV et SVN, mais aucune (bonne) expérience avec d'autres. Mais qui n'est normalement pas un problème, vous pouvez utiliser vos anciens dépôts SVN (en lecture seule) et juste migrer le dernier jalon. Après un certain temps, les prises en pension SVN peuvent être laissées pour compte ...
après 1 an de travail avec TFS / Java je suis tout à fait d'accord avec Dusty J (Oui, TFS/Java est mauvais) et complètement en désaccord avec Martin Woodward à propos du grand soutien de Microsoft. Bien que pour mon devoir en tant que développeur L'Eclipse TFS soit OK, les problèmes sont pour mes tâches de compilation/publication.
tout d'abord, ce plugin Eclipse ne permet pas de créer une branche pour plusieurs projets à la fois comme dans CVS/SVN. Il faut créer une branche distincte pour chaque projet. Alors nous ne pouvons pas garder les mêmes noms de projet dans la Direction générale – il faut changer le nom d'un projet et après avoir quitté la Direction générale pour changer le nom à l'origine. Voir Aussi mon article comment associer un espace de travail Eclipse avec un espace de travail TFS? , il n'y a aucun moyen d'associer un espace de travail Eclipse avec un espace de travail TFS. Ainsi, le mappage d'un dossier local ne peut pas être sauvegardé; il doit être fait à nouveau après l'ouverture d'un autre espace de travail Eclipse pour la construction d'une branche. Et puisque la cartographie locale est même il y a une possibilité d'effacer un dossier local avec un travail non enregistré comme Dusty J a écrit.
cette suppression de fichiers locaux sans avertissement est une terrible caractéristique de TFS (voir le post pourquoi la commande get à partir d'une ligne de commande dans TFS supprime les projets parallèles? ). ce que Microsoft pense de la possibilité d'effacer des fichiers locaux juste sous l'option régulière "supprimer la cartographie locale" dans Eclipse?
donc, malgré mon effort pour apprendre TFS je passe encore 10 fois plus de temps pour les différentes versions que les CVS que j'ai utilisés auparavant.
(un Autre biaisée MS employé)
TFS a formé une équipe il y a environ 18 mois pour se concentrer uniquement sur l'amélioration de L'expérience Java dans les Services TFS/Team et sur toutes les plateformes. Je fais partie de cette équipe et je pense que nous avons fait beaucoup de progrès. Je ne suis pas en désaccord avec le fait que l'histoire de la fin à la fin était assez mauvaise lorsque cette question a été posée, mais je pense que la réponse a changé un peu au cours de la dernière année.
mon équipe fournit des tâches de construction et de déploiement pour TFS ainsi que les plugins pour Eclipse et IntelliJ pour rendre l'expérience de bout en bout aussi complet que possible. Nous travaillons également dur pour nous assurer que nous documentons comment tirer le meilleur parti de TFS si vous êtes un développeur Java.
si vous voulez plus de détails, allez à http://java.visualstudio.com .
Merci, Jason Prickett
pourquoi ne pas utiliser SVN pour les projets .NET? Est-il une raison pour que? Il existe plusieurs plugins pour SVN dans Visual Studio ainsi qu'un shell windows extension .