Team Foundation Créer ou TeamCity?

Question

Nous sommes la plupart du temps MS boutique au travail à faire du développement LOB .NET. Nous utilisons également MS Dynamics pour notre application CRM ... tous les développeurs utilisent actuellement VS / SQL Server 2008. Nous utilisons également VSS, mais tout le monde le hait au travail et qui est rapidement en voie de disparition.

Nous debuts Notre initiative pour la mise en œuvre TDD sein de l'équipe (~ douzaine ppl). J'ai obtenu la configuration TeamCity et que mon premier automatisé builds en cours d'exécution en utilisant avec succès le constructeur sln 2008 et en utilisant aussi SVN qu'un collègue avait l'installation qui fait l'analyse de contrôle de code source. Lorsque demoing à managament, je pense qu'ils ont commencé à acheter dans mon huile de serpent et ont jeté les suggestions de recherche dans TFS.

a jeté une clé dans ce que j'avais prévu pour notre architecture TDD; Dans une bonne façon cependant, parce que j'avais toujours pensé que TFS était tout simplement trop cher et ne vaut pas pour notre équipe (et je l'ai vu la même chose dans d'autres magasins que j'ai travaillé à / Sache). Je me sens comme MS est en retard dans la années TDD / zone CI et que les produits tiers étaient probablement beaucoup mieux et plus mature ... Je dois encore faire beaucoup de recherche, mais je pensais que je serais venu ici pour voir si quelqu'un a effectivement utilisé les deux systèmes.

Je me rends compte du TFS comprend beaucoup plus qu'un simple serveur de build ... mais je ne voulais pas en faire trop large d'une question au moins sur le but. Quels sont les avantages / inconvénients des pratiques de l'utilisation TFS / TFB au lieu de TeamCity - par exemple qui bénéficie nous perdrions / gain? Quelqu'un at-il ici réellement utilisé les deux systèmes (TFS pour TDD / CI et TeamCity / SVN) et peut parler du point de vue pratique?

Je l'ai fait quelques recherches sur ce sujet, et un poste que je trouve ici sur le SO ont mentionné que les inconvénients de TFB est seulement pris en charge MSBuild. Je comptais sur l'utilisation FinalBuilder avec TeamCity; et il semble qu'il soutient également TFS ainsi ...

Merci pour tout conseil

EDIT: Quelqu'un at-il utilisé comme TFS Construire / serveur CI et peut raconter des histoires de succès / échec

Answer 1

Nous sommes une petite boutique de développement, et a décidé que Team Foundation Server porte trop de frais généraux pour nous. Nous avons utilisé pour écrire des scripts personnalisés MSBuild pour exécuter à partir de la ligne de commande, mais après nous avons découvert TeamCity, nous avons déménagé notre ensemble du processus de construction sur lui.

Nous avons trouvé TeamCity être facile à utiliser et à configurer, et JetBrains offre un excellent support et de la documentation. Ils sont également un cycle de mise à jour et la libération beaucoup plus rapide que Microsoft.

Leur soutien pour le contrôle des sources SVN est excellente, et nous aimons le fait qu'ils prennent en charge les MSTest et NUnit pour les tests unitaires.

Nous avons également apprécié le fait que l'édition professionnelle TeamCity était libre, afin que nous puissions l'évaluer pour voir si cela a fonctionné pour nous. Nous qui nous obligerait n'a pas atteint le nombre de configurations de projet (20) pour passer à l'édition Enterprise.

Answer 2

Cette question a beaucoup de bonnes réponses sur TeamCity. Il ne se compare pas à TFS mais il pourrait faire la lumière sur TeamCity pour vous.

Je l'ai utilisé à la fois, et je l'ai eu du succès avec les deux, mais TeamCity était tellement plus facile. TeamCity était un jeu d'enfant à installer et à configurer. TFS était pas. TeamCity est solide, il est facile à entretenir et il fonctionne tout simplement. Les développeurs de JetBrains ont fait un excellent travail de répondre à la communauté. Ils obtiennent une sortie tous les 6 à 8 mois qui apporte une valeur ajoutée réelle. TFS est sur un cycle de deux années ou plus.

TeamCity vous donne un plus grand choix dans la façon dont vous construisez et que le contrôle des sources que vous utilisez. Ce n'est pas tout en un, mais qui est parfois une bonne chose. Il a un bon jeu de points d'extension ainsi. Nous avons également été très heureux avec le modèle de l'agent qu'il a.

Je suis passé par 3 painles absolument mises à niveau TeamCity. Celui TFS mise à jour, nous avons pris notre contrôle de la construction et de la source pendant 3 jours. Je suis l'administrateur pour TeamCity sur notre projet et il prend quelques heures par mois. TFS a pris quelques jours par semaine.

TeamCity + SVN + VisualSVN est l'environnement plus doux que j'ai jamais travaillé. TFS était généralement lisse le jour en jour, mais seulement si quelqu'un y était gardais en cours d'exécution.

L'espoir qui aide

Answer 3

Les avantages de TFS sont un environnement intégré qui est pris en charge par Microsoft. Personnellement, je n'aime pas TFS pour le contrôle des sources et ont eu un certain nombre de problèmes avec elle. Il est maladroit, mais il avait l'avantage d'avoir VS intégration (qui est également disponible dans VisualSVN, mais il est pas aussi robuste).

Personnellement, je pense que vous seriez bien mieux d'utiliser SVN / TeamCity. Il est juste plus facile de travailler avec et se comporte plus comme on peut s'y attendre. Comme avec la plupart des logiciels open source, les deux sont en constante évolution et aura toujours la dernière et la plus grande fonctionnalité avant Microsoft. L'intégration entre les deux est vraiment bon et je l'ai trouvé aucun défaut rédhibitoire dans le système. Je pousse constamment aller dans cette voie dans mon entreprise actuelle (nous utilisons TFS), car je crois qu'il est un meilleur flux de travail. Comme un avantage supplémentaire, il est beaucoup moins cher que la route TFS.

J'ai aussi utilisé FinalBuilder avec TFS - ma question il y a ce que vous achetez vraiment avec FinalBuilder que vous ne pouvez pas faire avec NANT / MSBuild? La réponse à ma boutique est malheureusement très peu de l'OMI.

Answer 4

Tout d'abord, voir ce post:

SVN vs Team Foundation Server

En ce qui concerne votre question sur quel environnement favorise davantage TDD et ces, mes deux cents est que le système de gestion de construction qui compte beaucoup moins que ce qui est dans le fichier de construction lui-même. Votre fichier Ant ou MSBuild devrait avoir les objectifs qui font vos tests. Avec MSBuild ou Ant, vous ne devez pas utiliser la suite de tests de MS. Vous pouvez toujours utiliser nUnit ou tout ce que vous voulez. Cela signifie qu'il n'a pas d'importance si TFS appelle votre fichier MSBuild, ou si CruiseControl est, ou si TeamCity est. Les Smarts sont tous dans le fichier de construction et les outils dont vous intégrer avec.

Mon choix personnel est de ne pas obtenir verrouillé dans la façon de TFS de faire les choses, puisque vous avez beaucoup plus de liberté pour beaucoup moindre coût avec la richesse des outils de tests open source qui sont là-bas. TFS est sur le point de recevoir une mise à jour majeure, aussi bien. Si vous allez aller avec TFS, mon conseil est d'au moins attendre jusqu'en 2010 est libéré. Concentrez-vous sur faire vos fichiers MSBuild aussi bons qu'ils peuvent être en ce moment.

Cela étant dit, je dois admettre que TFS est l'un des plus beaux systèmes de construction là-bas (2005 a été terrible, 2008 était bien). Être en mesure de personnaliser facilement les notifications et le processus de libération tout à l'intérieur du code .NET était assez cool - vous avez eu beaucoup plus de contrôle central sur la politique et la libération de construction que nous avons fait avec CruiseControl.NET.

Je l'ai utilisé TFS et SVN / CCNet. Je ne peux pas parler beaucoup à TeamCity. Mais l'OMI un système de gestion de construction devrait être assez agnostique à ce qui est construit et comment il est en cours de construction. Pour nous, le contrôle supplémentaire dans le processus de gestion des versions qui TFS nous a tout simplement pas assez d'un bonus pour nous de justifier l'effort administratif considérablement augmenté d'une solution totalement intégrée TFS. Ce ne fut pas suffisant pour justifier le coût supplémentaire par licence de TFS, qui peut être important.

Answer 5

L'ancien TFS build a été XAML basé et très lourd et et non agréable de travailler avec. Cela dit, le nouveau système de construction TFS 2015 est pas de géant mieux, et est script basé avec beaucoup de crochets web et intégrations 3ème partie; très similaire à l'équipe City. En outre, TFS supporte désormais Git, de sorte que vous ne se limitent plus à l'utilisation de Team Foundation Version Control (TFVC). En outre, avec TFS vous pouvez utiliser votre propre installation sur prem, ou peut profiter d'une solution hébergée par visualstudio.com. TFS est grand parce qu'il est un environnement complètement intégré (articles de travail, la planification, construit, tests, déploiements), alors que la ville équipe est tout simplement une solution de construction. Lorsque cette question a été posée en 2010, je l'ai recommandé mains Ville équipe vers le bas. Maintenant, cependant, les deux sont très compétitifs. Je dirais que ce serait peut-être faire bouillir jusqu'à si vous voulez une solution tout-en-un, puis aller avec TFS, mais si vous cherchez purement juste un système de construction, puis équipe de la ville.

Answer 6

Comparaison TeamCity aux services Visual Studio Team (Le tout dernier offre en nuage de Microsoft):

• Les deux fonctionnent très bien pour la mise en œuvre d'un processus d'intégration continue

• TeamCity est plus mature et tout fonctionne.

• Services Visual Studio Team en revanche est en constante évolution pour rattraper TeamCity et certaines choses ne fonctionnent pas bien (par exemple, essayez le déclenchement builds basés sur des chemins qui ont des changements de Git - la documentation est faible et la fonction lui-même ne fonctionne pas (Août 2016))

• Visual Studio Team Services, il est facile d'avoir seulement des agents basés sur le cloud en cours d'exécution de votre construction (l'inconvénient est toutefois que chacun doit faire un pull propre de votre référentiel pour chaque construction qui peut ajouter une minute ou plus la construction). Les deux peuvent également prendre en charge les agents de construction locaux qui ne ont pas besoin d'essuyer le répertoire de travail pour chaque construction nouvelle.

Mais dans les deux cas, je vous recommande vivement de regarder aussi à CakeBuild qui se déplace la plupart des informations de configuration sur comment pour compilons du système de CI et dans le code C # qui est dans votre Git dépôt ainsi que tous vos autres code source. Avec CakeBuild vous pouvez exécuter la même version locale que vous exécuterez dans le système de CI et si vous avez besoin de revenir un mois pour construire une version spécifique que vous avez le code source et le script de compilation pour le faire.

CakeBuild en place, vous êtes maintenant libre de basculer facilement entre TeamCity et services Visual Studio Team.

Le seul inconvénient de CakeBuild est que toutes vos étapes de construction sont regroupés dans une seule tâche dans le système de CI qui rend des rapports un peu moins agréable et peut impliquer un travail supplémentaire pour obtenir les résultats des tests sur dans un format que le système de rapports de CI peut utiliser.

Answer 7

  

MS est à des années derrière dans la zone TDD / CI

Étant celui qui a TDD'd depuis 4 ans maintenant vous avez raison. MS est toujours pas même la promotion de ce et ils ne proposent des outils qui fonctionnent bien avec le flux TDD.

Ne restez pas coincé face à Visual Studio pour tout type d'automatisation, contrôle de code source, ou d'une période de flux de travail agile (cesser d'utiliser TFS !! s'il vous plaît). Ce genre de choses, même si elles disent est « nouveau » est monolithique et vient toujours des questions étranges et ballonnement. Il est toujours douloureux.

Je l'ai utilisé équipe de la ville et il est tout simplement incroyable, les choses fonctionnent, il est conçu pour la facilité d'utilisation, et il est tout simplement bien conçu et compatible avec la plupart de tous les outils de test, etc. utilisation Visual Studio fine pour le code, rien d'autre. Recherchez des outils de source externe et ouverte pour aider à bâtir un meilleur CI. Le « vous pouvez tout faire en plein VS » vendre ne vend pas, et cela ne fonctionne pas. Les gens nowdays sont habitués et toujours combiner différents outils de l'extérieur pour faire avancer les choses. En se fondant sur tous les États membres toolsets est tout simplement pas la manière d'aller de l'OMI pour .NET. MS aime vendre « hey, vous pouvez simplement faire tout ici ». Mais vous vous retrouvez avec rien d'autre que la douleur quand vous allez dans cette voie et boire leur koolade (TFS, MS Fakes, etc.).

Si vous envisagez de faire TDD, vous ne voulez certainement pas à utiliser tous les outils MS. Vous aurez soit être poussé vers le bas « chemin » de faire ce qui est souvent propriétaire et / ou de ballonnement lorsque vous essayez de TDD avec leurs outils ou être totalement restrictive. Pour TDD vous devez être en mesure d'avoir une certaine souplesse et choix lorsque vous décidez de la couche dans différents cadres de test, les bibliothèques d'assertion, etc.

Octopus au-dessus de la ville d'équipe, et il est excellent ... vous simplement tomber amoureux comme développeur ou pour tous ceux qui font DevOps.

Arrêtez d'essayer de compter sur Microsofts a continué l'échec des offres d'outils agiles

Commencer à regarder des sentiers battus et essayer de nouvelles choses est ce que je ne cesse de répéter dans le monde .NET, moi d'être un développeur .NET dans le passé et qui a essayé de nouvelles choses en dehors du monde de MS.