Question

Nous sommes en train de configurer un contrôle de source / construction / et plus de serveurs pour le développement .NET et nous envisageons soit d'utiliser Team Foundation Server (ce qui coûte beaucoup de temps) ou de combiner plusieurs options open source, telles que SourceForge Enterprise / GForge et Subversion et CruiseControl.net, etc. Quelqu'un a-t-il emprunté la bonne voie de l'OSS ou s'agit-il de TFS uniquement si vous voulez bien faire les choses et vous mettre au travail rapidement?

Était-ce utile?

La solution

Mon travail utilise actuellement un processus de génération essentiellement libre avec le régulateur de vitesse en guise de moteur, et il est génial. Je suggérerais que si vous ne savez pas pourquoi vous auriez besoin de TFS, cela ne vaut probablement pas le coût.

Ce qu’il faut garder à l’esprit avec le logiciel OSS, c’est que le logiciel était utilisé par l’équipe Java depuis des années auparavant ou qu’il utilisait un code Java similaire. Il est robuste et adapté à vos besoins.

Microsoft ne peut pas livrer de code OSS, raison pour laquelle ils doivent ré-implémenter de nombreux outils Open Source. Donc, non, ce n'est pas nécessaire et des millions de projets ont été livrés sur cette pile. Le revers de la médaille est qu’il existe de nombreuses fonctionnalités intéressantes que vous obtenez avec TFS que vous n’obtiendrez pas (facilement) avec la pile OSS, telles que l’intégration avec votre logiciel de suivi des bogues / fonctionnalités.

Autres conseils

Je suis toujours allé dans le sens du logiciel libre et je n’ai jamais eu de problème. Je recommanderais également fortement TeamCity pour votre solution de CI. Il existe une licence gratuite et je pense que CC.NET est sorti de l’eau pour faciliter la configuration et les retours.

Je suis un utilisateur quotidien de TFS depuis environ un an et demi.

  • Le contrôle de source est stable
  • Vous ne pouvez pas facilement travailler déconnecté. L'extraction de fichier va au serveur.
  • La fusion automatique fonctionne très bien, sauf que parfois elle corrompt le fichier source (problème d'encodage).
  • TFS a une impression de paresse!? Surtout le gestionnaire de test. Code géré?
  • Il y a divers bugs stupides dans la partie test, rien de critique.
  • Le test prend trop de temps à démarrer (en attente).
  • J'ai des blocages SQL de temps en temps!?
  • Le suivi des problèmes est nul. Vous êtes obligé de travailler dans les boîtes de dialogue intégrées lentes, Web est uniquement un affichage. Je recommande de le comparer à d'autres systèmes de suivi des problèmes, tels que JIRA
  • La construction fonctionne bien.

Si vous utilisez TFS, assurez-vous d’installer VSTS2008SP1. La grande majorité des gens que j'ai vus déposant des plaintes utilisent la version 2005. 2005 est le classique "Microsoft 1.0". syndrome. Il y avait beaucoup de problèmes qui ont été résolus par les 2 dernières "versions".

Le Service Pack pour 2008 n’est pas simplement un correctif, mais il a ajouté de nombreuses nouvelles fonctionnalités.

En ce qui concerne le choix vs OSS - il y a beaucoup de discussion (ici et ailleurs). Ce n'est pas un produit bon marché - mais c'est le meilleur choix pour de nombreux scénarios (et le pire pour d'autres).

Nous avons examiné TFS, mais avons finalement opté pour Subversion + Trac + VisualSVN. Nous ne faisons pas de CI pour le moment, mais Cruisecontrol serait ce que nous utiliserions, je pense.

J'ai commencé à utiliser Trac avec de nombreux projets open-source, et c'est un excellent projet. Il ne s'agit en réalité que d'une partie de ce que fait TFS. Vous devrez donc prendre une décision. Si vous utilisez tout ce que vous utilisez, TFS réussira probablement à mieux lier le tout. Trac est un wiki / traqueur de bogues / navigateur de source. Tout est lié - lorsque vous tapez le nom d'une page Wiki ou que vous dites "Corriger le bogue 1234". dans un message de validation, chaque fois que vous voyez ce message dans Trac, les liens vont aux bons endroits. C'est un outil qui vous aide à faire votre travail mais qui reste généralement à l'écart.

VisualSVN est un excellent pont entre TortoiseSVN (un client Subversion) et VisualStudio et améliore considérablement la productivité. Ils ont un essai gratuit, et ce n'est pas très cher ensuite (50 € / utilisateur), mais ça en vaut la peine.

L’un des inconvénients de Trac réside dans le monde Windows: c’est pénible de travailler sur IIS. J'ai installé Trac plusieurs fois, mais je me suis rapidement frustré d'essayer de le faire fonctionner correctement. J'ai fini par installer Apache sur une autre adresse IP (je pouvais également utiliser un autre port), puis c'était transparent.

À l'exception d'une personne de mon équipe (qui avait un peu d'expérience), personne n'avait encore utilisé la subversion. Un couple avait utilisé VSS et c'est tout. Tout le monde était sceptique, mais je dirais en quelques jours qu'ils étaient tous convertis. Après avoir complètement appris Trac et s’être habitué à tout (quelques jours de plus), tout le monde est totalement vendu et adore ça.

Notre société utilise avec succès la combinaison CruiseControl / SVN / nAnt / JIRA.

Le problème avec TFS est que cela ne vaut que pour les grandes entreprises. Cela coûtera terriblement cher aux petites entreprises de 30 développeurs ou moins, qui bénéficieraient déjà grandement du combo Open Source ci-dessus.

Subversion + Cruisecontol.Net est une bonne alternative. SVN est riche en fonctionnalités, stable et flexible.

L’avantage réel de l’utilisation de TFS par rapport à un jeu d’outils d’exploitation distinct est l’intégration des différents flux d’informations disponibles.

* Créer une exigence et l'insérer dans TFS
* Créer un ensemble de tâches les reliant à l'exigence et les attribuer aux différents développeurs
* Chaque développeur travaille sur sa tâche et l'archivage, en affectant la tâche à l'ensemble de modifications archivée

* Un correctif de bogue arrive, également dans ce cas, le jeu de modifications sera coordonné avec la demande de correctif de bogue et vous pouvez également mapper le correctif sur l'exigence d'origine.

Une fois cette opération effectuée, toutes les informations peuvent être utilisées pour suivre le projet et procéder à une évaluation du travail, par exemple le nombre de modifications apportées par un correctif, c’est-à-dire la condition qui a généré plus de bogues ou de demandes de modification, etc.

Toutes ces informations sont très utiles dans les moyennes et grandes organisations et, d'après ce que je vois maintenant, il est impossible (ou très difficile) de suivre l'intégration de différents outils de système d'exploitation.

La pile TFS est bien plus qu'un contrôle de source et une configuration de construction CI / nightly. Pensez à la gestion de projet, aux rapports de bogues et tout cela ajoute à quelque chose de plus que CruiseControl, SVN et NAnt. Seuls les rapports pourraient valoir l'investissement. Et rappelez-vous également que si vous êtes un abonné MSDN / partenaire Gold ISV / etc. vous pourriez en recevoir gratuitement ...

Ce n'est que récemment que je commence à travailler avec TFS quotidiennement et, issu d'une pile précédemment ouverte, je le trouve plutôt insuffisant.

Bien que l'intégration de tout le suivi des bogues et des tâches soit une fonctionnalité vraiment géniale, les aspects négatifs l'emportent sur le poids.

Personnellement, j'utilise la pile suivante qui me donne tout ce que nous devons faire, de l'intégration continue aux déploiements automatisés à l'échelle de l'entreprise, pour une fraction du coût:

J'ai vu les deux en action (même si je suis un développeur Java). L’avantage d’une approche sélective est que vous pouvez choisir les meilleurs éléments pour tout (par exemple, je voudrais vérifier Hudson pour CI: excellent pour Java, fonctionne aussi pour .Net et a charges de plugins et est vraiment simple à utiliser). L'inconvénient est que vous devez effectuer toute l'intégration vous-même. Cependant, cela devient beaucoup plus facile dans le monde Java. En outre, ne laissez pas les gens vous dire qu'un produit pris en charge est préférable. Sur de nombreux produits OSS dans cet espace, la qualité est excellente et vous obtenez un meilleur support de la communauté plutôt que d'attendre une réponse du contrat de support de votre fournisseur (IBM, je vous regarde).

J'espère que cela vous aidera.

Je suis tout à fait d’accord avec l’idée que l’utilisation de TFS ne vaut la peine si vous savez exactement pourquoi vous en avez besoin. Les compléments gratuits, bon marché ou gratuits, basés sur OSS, tels que Visual SVN et TestDriven.Net, sont si performants que l'intégration avec VS est déjà transparente.

Je pensais que je mettrais une nouvelle perspective qui peut être prise avec un grain de sel parce que je ne l'ai pas encore essayée, mais je prévois d'utiliser Bitten pour CI dans un projet à venir. Cela fonctionne sur Trac + SVN, deux excellents outils que j'ai utilisés avec succès pour de nombreux projets.

Nous avons construit une pile de développement progressivement ici, nous utilisons actuellement:

  • Subversion
  • CruiseControl
  • RedMine (intègre le suivi des bogues avec le contrôle de source et inclut le wiki, la gestion de projet de base, etc.).

Je pense que le TFS en vaut la peine pour toutes les fonctionnalités supplémentaires mentionnées dans les publications ci-dessus. Sa fonctionnalité de construction continue fait cruellement défaut, nous avons donc ajouté CruiseControl.NET, ce qui est génial. La seule raison pour laquelle nous choisirions contre TFS si nous devions le faire maintenant, c’est que nous passons au développement multi-plateformes de nos produits. Donc, si vous avez même pensé à cela, pensez à l'OSS. Subversion / Trac serait mon combo préféré de cette façon, CruiseCOntrol.NET demeurant l’épine dorsale. CC.NET avec mono fonctionne bien sous Linux et Mac.

TFS2010 a un TFS Basic, qui ne coûte rien (au-delà de votre abonnement msdn / licence Visual Studio). Il est limité à 1 par licence VS, mais vous n’avez besoin que de licences supplémentaires pour les utilisateurs non VS

L’automatisation de l’UI dans VS2010 à elle seule fait de TFS un gagnant pour le regroupement de solutions open source

Il convient de noter que la meilleure alternative à un large éventail de fonctionnalités TFS ne sont pas nécessairement des logiciels libres, mais des publicités à petit budget, comme NDepend pour la qualité du code et l'exploration de l'architecture, NCover pour la couverture du code, TestDriven.NET pour les tests imbriqués dans l'EDI ...

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top