Team Foundation Build ou TeamCity ?

Question

Au travail, nous utilisons principalement MS pour le développement .NET de LOB. 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 déteste au travail et il est en voie de disparition.

Nous commençons notre initiative de mise en œuvre de la TDD dans toute l'équipe (~douzaine de personnes). J'ai mis en place TeamCity et j'ai réussi mes premières constructions automatisées en utilisant le constructeur sln 2008 et aussi en utilisant SVN qu'un collègue a mis en place et qui fait l'analyse du contrôle des sources. Lorsque j'ai fait ma démonstration à la direction, je pense qu'ils ont commencé à croire à mon huile de serpent et ont jeté les suggestions de regarder dans TFS.

Cela a jeté un froid dans ce que j'avais prévu pour notre architecture TDD ; d'une bonne façon cependant, parce que j'avais toujours supposé que TFS était tout simplement trop cher et ne valait pas la peine pour notre équipe (et j'ai vu la même chose dans d'autres ateliers où j'ai travaillé / que je connais). J'ai l'impression que MS a des années de retard dans le domaine du TDD/CI et que les produits tiers étaient probablement bien meilleurs et plus matures... Je dois encore faire beaucoup de recherches, mais je me suis dit que je viendrais ici pour voir si quelqu'un a réellement utilisé les deux systèmes.

Je réalise que le TFS englobe beaucoup plus qu'un simple serveur de construction... mais je ne voulais pas que cette question soit trop large, du moins intentionnellement. Quels sont les avantages et inconvénients pratiques de l'utilisation de TFS/TFB au lieu de TeamCity - par exemple, quels avantages perdrions-nous ou gagnerions-nous ? Quelqu'un a-t-il déjà utilisé les deux systèmes (TFS pour TDD/CI et TeamCity/SVN) et peut-il parler d'un point de vue pratique ?

J'ai fait quelques recherches sur ce sujet, et un message que j'ai trouvé ici sur SO mentionnait que l'inconvénient de TFB était qu'il ne supportait que MSBuild. J'avais l'intention d'utiliser FinalBuilder avec TeamCity ; et il semble qu'il supporte également TFS...

Merci pour tout conseil

EDIT : Est-ce que quelqu'un a utilisé TFS comme serveur Build/CI et peut raconter des histoires de succès/échecs ?

Answer 1

Nous sommes un petit atelier de développement et nous avons décidé que Team Foundation Server comportait trop de frais généraux pour nous. Nous avions l'habitude d'écrire des scripts MSBuild scripts personnalisés à exécuter à partir de la ligne de commande, mais après avoir découvert TeamCity, nous avons transféré l'ensemble de notre processus de construction sur celui-ci.

Nous avons trouvé TeamCity facile à utiliser et à configurer, et JetBrains fournit une excellente assistance et documentation. Ils ont également un cycle de publication et de mise à jour beaucoup plus rapide que celui de Microsoft.

La prise en charge du contrôle de source SVN est excellente, et nous apprécions le fait qu'ils prennent en charge MSTest et NUnit pour les tests unitaires.

Nous avons également apprécié le fait que l'édition TeamCity Professional était gratuite, ce qui nous a permis de l'évaluer pour voir si elle nous convenait. Nous n'avons pas atteint le nombre de configurations de projets (20) qui nous obligerait à passer à l'édition Enterprise.

Answer 2

Cette question a beaucoup de bonnes réponses sur TeamCity. Il n'est pas comparable à TFS mais il pourrait vous éclairer sur TeamCity.

J'ai utilisé les deux, et j'ai eu du succès avec les deux, mais TeamCity était tellement plus facile. TeamCity était un jeu d'enfant à mettre en place et à configurer. TFS ne l'était pas. TeamCity est solide comme le roc, il est facile à maintenir et il fonctionne tout simplement. Les développeurs de JetBrains ont fait un excellent travail en répondant à la communauté. Ils sortent une version tous les 6 à 8 mois qui apporte une réelle valeur ajoutée. TFS a un cycle de 2 ans ou plus.

TeamCity vous donne plus de choix dans la façon dont vous construisez et le contrôle de source que vous utilisez. Ce n'est pas tout en un, mais c'est parfois une bonne chose. Il dispose également d'un bon ensemble de points d'extension. Nous avons également été très satisfaits du modèle d'agent qu'il propose.

Je suis passé par 3 mises à jour absolument pénibles dans TeamCity. La seule mise à niveau de TFS que nous avons effectuée a entraîné une interruption de notre construction et du contrôle de la source pendant 3 jours. Je suis l'administrateur de TeamCity sur notre projet et cela me prend quelques heures par mois. TFS a pris quelques jours par semaine.

TeamCity + SVN + VisualSVN a été l'environnement le plus fluide dans lequel j'ai jamais travaillé. TFS était généralement fluide au jour le jour, mais seulement si quelqu'un était là pour le faire fonctionner.

J'espère que cela vous aidera.

Answer 3

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

Personnellement, je pense que vous feriez mieux d'utiliser SVN/TeamCity. Il est tout simplement plus facile de travailler avec et se comporte plus comme vous l'attendez. Comme pour la plupart des logiciels open source, les deux sont en constante évolution et auront toujours la dernière et meilleure fonctionnalité avant Microsoft. L'intégration entre les deux est vraiment bonne et je n'ai trouvé aucune faille fatale dans le système. J'insiste constamment pour que cette voie soit suivie dans mon entreprise actuelle (nous utilisons TFS), car je pense que le flux de travail est bien meilleur. En outre, il est nettement moins cher que le système TFS.

J'ai également utilisé FinalBuilder avec TFS - ma question est la suivante : qu'achetez-vous vraiment avec FinalBuilder que vous ne pouvez pas faire avec NANT/MSBuild ? Dans mon atelier, la réponse est malheureusement très peu.

Answer 4

Tout d'abord, voir ce post :

SVN et Team Foundation Server

Pour ce qui est de la question de savoir quel environnement favorise le plus le TDD et autres, je dirais que le système de gestion de la construction importe beaucoup moins que le contenu du fichier de construction lui-même. Votre fichier Ant ou MSBuild devrait contenir les cibles qui font vos tests. Avec MSBuild ou Ant, vous n'êtes pas obligé d'utiliser la suite de tests de MS. Vous pouvez toujours utiliser nUnit ou ce que vous voulez. Cela signifie que cela n'a pas d'importance si TFS appelle votre fichier MSBuild, ou si CruiseControl le fait, ou si TeamCity le fait. L'intelligence se trouve dans le fichier de construction et les outils que vous y intégrez.

Personnellement, je préfère ne pas m'enfermer dans la façon de faire de TFS, car vous disposez de beaucoup plus de liberté pour un coût bien moindre avec les nombreux outils de test open-source qui existent. TFS est également sur le point de recevoir une mise à jour majeure. Si vous optez pour TFS, je vous conseille d'attendre au moins la sortie de 2010. Concentrez-vous sur l'optimisation de vos fichiers MSBuild dès maintenant.

Ceci étant dit, je dois admettre que TFS possède l'un des systèmes de construction les plus agréables qui soient (2005 était terrible, 2008 était agréable). La possibilité de personnaliser facilement les notifications et le processus de publication à l'intérieur du code .NET était plutôt cool - vous aviez un contrôle bien plus central sur la politique de construction et de publication que ce que nous avions avec CruiseControl.NET.

J'ai donc utilisé TFS et SVN/CCNet. Je ne peux pas beaucoup parler de TeamCity. Mais, selon moi, un système de gestion de construction devrait être assez agnostique par rapport à ce qui est construit et comment il est construit. Pour nous, le contrôle supplémentaire dans le processus de gestion des versions que TFS nous a apporté n'était tout simplement pas un bonus suffisant pour justifier l'effort administratif considérablement accru d'une solution TFS entièrement intégrée. Il n'était pas non plus suffisant pour justifier le coût supplémentaire par licence de TFS, qui peut être important.

Answer 5

L'ancienne version de TFS Build était basée sur XAML et était très encombrante et peu agréable à utiliser. Cela dit, le nouveau système de construction TFS 2015 est bien meilleur, et est basé sur script avec beaucoup de crochets web et d'intégrations tierces ; très similaire à Team City. En outre, TFS prend désormais en charge Git, de sorte que vous n'êtes plus confiné à l'utilisation de Team Foundation Version Control (TFVC). De plus, avec TFS, vous pouvez utiliser votre propre installation sur site ou profiter d'une solution hébergée via visualstudio.com. TFS est idéal car il s'agit d'un environnement totalement intégré (éléments de travail, planification, constructions, tests, déploiements), alors que Team City n'est qu'une solution de construction. Lorsque cette question a été posée en 2010, j'aurais recommandé Team City sans hésiter. Mais aujourd'hui, les deux sont très compétitifs. Je dirais que si vous voulez une solution tout-en-un, alors allez avec TFS, mais si vous cherchez purement un système de construction, alors Team City.