Team Foundation Build ou TeamCity?

Nous sums principalement une boutique MS travaillant sur le développement de .NET 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 cela est rapidement en voie de disparition.

Nous commençons notre initiative de mise en œuvre de TDD au sein de l’équipe (~ douzaine de personnes). J’ai installé TeamCity et mes premières compilations automatisées s’exécutent avec succès en utilisant le générateur sln 2008 et également en utilisant SVN qu’un collègue avait configuré pour effectuer l’parsing du contrôle de code source. Lors de ma démonstration de gestion, je pense qu’ils ont commencé à acheter de l’huile de serpent et ont jeté les idées sur les TFS.

Cela a jeté une clé dans ce que j’avais prévu pour notre architecture TDD; Dans le bon sens cependant, parce que j’avais toujours supposé que TFS était trop cher et que cela ne valait pas la peine pour notre équipe (et j’ai vu la même chose dans d’autres magasins où j’ai travaillé). Je pense 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 … J’ai encore besoin de faire beaucoup de recherches, mais je pensais que je viendrais ici pour voir si quelqu’un a effectivement utilisé les deux systèmes.

Je me rends compte que le TFS ne se résume pas à un serveur de compilation … mais je ne voulais pas en faire une question trop large, du moins délibérément. Quels sont les avantages / inconvénients pratiques de l’utilisation de TFS / TFB au lieu de TeamCity – par exemple, quels avantages perdrions-nous / gagnerions-nous? Quelqu’un at-il utilisé les deux systèmes (TFS pour TDD / CI et TeamCity / SVN) et peut-il parler d’un sharepoint vue pratique?

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

Merci pour tout conseil

EDIT: Quelqu’un a-t-il utilisé TFS comme serveur Build / CI et peut-il raconter des histoires de réussite / échec?

Nous sums une petite boutique de développement et nous avons décidé que Team Foundation Server était trop chargé pour nous. Nous avions l’habitude d’écrire des scripts MSBuild personnalisés pour exécuter à partir de la ligne de commande, mais après avoir découvert TeamCity, nous y avons transféré l’intégralité de notre processus de génération.

TeamCity est facile à utiliser et à configurer, et JetBrains fournit un support et une documentation excellents. Ils sont également sur un cycle de publication et de mise à jour beaucoup plus rapide que Microsoft.

Leur 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 soit gratuite, nous avons donc pu l’évaluer pour voir si cela fonctionnait pour nous. Nous n’avons pas atteint le nombre de configurations de projet (20) nécessitant une mise à niveau vers l’édition Enterprise.

Cette question a beaucoup de bonnes réponses à propos de TeamCity. Il ne se compare pas à 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 à configurer et à configurer. TFS n’était pas. TeamCity est solide, facile à entretenir et fonctionne parfaitement. Les développeurs de JetBrains ont fait un excellent travail pour répondre à la communauté. Ils obtiennent une libération tous les 6 à 8 mois, ce qui ajoute une réelle valeur ajoutée. TFS est sur un cycle de 2 ans ou plus.

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

Je suis passé par 3 améliorations de Painline dans TeamCity. La seule mise à niveau de TFS que nous avons effectuée a pris le contrôle de notre build et de notre source pendant 3 jours. Je suis l’administrateur de TeamCity sur notre projet et cela 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 s’est généralement bien débrouillé au quotidien, mais seulement si une personne était présente.

J’espère que cela pourra aider

Les avantages de TFS sont un environnement intégré pris en charge par Microsoft. Personnellement, je n’aime pas TFS pour le contrôle des sources et j’ai rencontré un certain nombre de problèmes. 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 juste plus facile de travailler avec et se comporte plus comme vous le souhaitez. Comme avec la plupart des logiciels open source, les deux évoluent constamment et auront toujours les dernières fonctionnalités les plus performantes avant Microsoft. L’intégration entre les 2 est vraiment bonne et je n’ai trouvé aucun défaut fatal dans le système. Je pousse constamment pour aller dans cette voie dans mon entreprise actuelle (nous utilisons TFS), car je pense que c’est un stream de travail bien meilleur. Comme avantage supplémentaire, il est beaucoup moins cher que de passer par la route TFS.

J’ai aussi utilisé FinalBuilder avec TFS – ma question est la suivante: qu’est-ce que vous achetez vraiment avec FinalBuilder que vous ne pouvez pas faire avec NANT / MSBuild? La réponse à mon magasin est malheureusement très petite.

Tout d’abord, voir ce post:

SVN vs Team Foundation Server

En ce qui concerne votre question sur l’environnement qui favorise le mieux le TDD, mes deux cents, c’est que le système de gestion de la construction est beaucoup moins important que le fichier de construction lui-même. Votre fichier Ant ou MSBuild doit avoir les cibles qui effectuent vos tests. Avec MSBuild ou Ant, vous n’avez pas besoin d’utiliser la suite de tests de MS. Vous pouvez toujours utiliser nUnit ou tout ce que vous voulez. Cela signifie que peu importe si TFS appelle votre fichier MSBuild ou si CruiseControl l’est ou si TeamCity l’est. Les connaissances sont toutes dans le fichier de construction et les outils que vous intégrez.

Mon choix personnel est de ne pas se laisser enfermer dans la façon de faire de TFS, car vous disposez de beaucoup plus de liberté pour des coûts beaucoup moins élevés avec les outils de test open source riches. TFS est sur le sharepoint recevoir une mise à niveau majeure. Si vous envisagez d’utiliser TFS, je vous conseille d’attendre au moins la publication de 2010. Concentrez-vous sur l’amélioration de la qualité de vos fichiers MSBuild.

Cela étant dit, je dois admettre que TFS possède l’un des plus beaux systèmes de construction (2005 était terrible, 2008 était agréable). Être capable de personnaliser facilement les notifications et le processus de publication tout au sein du code .NET était plutôt cool – vous aviez beaucoup plus de contrôle central sur les règles de compilation et de publication qu’avec CruiseControl.NET.

J’ai donc utilisé TFS et SVN / CCNet. Je ne peux pas parler beaucoup à TeamCity. Mais l’OMI, un système de gestion de la construction, devrait être relativement indifférent à ce qui est en train d’être construit et à sa construction. Pour nous, le contrôle supplémentaire que TFS nous a apporté dans le processus de gestion des versions ne nous a pas suffi pour justifier l’effort administratif accru d’une solution TFS entièrement intégrée. Cela ne suffisait pas non plus pour justifier le coût supplémentaire par licence de TFS, qui peut être important.

L’ancienne version de TFS était basée sur XAML et très compliquée à utiliser. Cela dit, le nouveau système de construction de TFS 2015 est bien plus performant, et est basé sur des scripts avec de nombreux hooks Web et intégrations tierces; très similaire à Team City. En outre, TFS prend désormais en charge Git. Vous n’êtes donc plus obligé d’utiliser TFVC (Team Foundation Version Control). De plus, avec TFS, vous pouvez utiliser votre propre installation sur site ou tirer parti 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, builds, tests, déploiements), alors que Team City est juste une solution de construction. Lorsque cette question a été posée à l’origine en 2010, j’aurais recommandé que Team City mette le doigt dessus. Maintenant, les 2 sont très compétitifs. Je dirais que cela pourrait se résumer à si vous voulez une solution tout-en-un, alors allez avec TFS, mais si vous cherchez uniquement un système de construction, alors Team City.

En comparant TeamCity à Visual Studio Team Services (la dernière offre cloud de Microsoft):

  • Les deux fonctionnent parfaitement pour mettre en œuvre un processus d’continuous integration

  • TeamCity est plus mature et tout fonctionne.

  • En revanche, Visual Studio Team Services évolue constamment pour rattraper TeamCity et certaines choses ne fonctionnent pas correctement (par exemple, essayez de déclencher des builds basés sur des chemins qui ont des modifications de Git – la documentation est faible et la fonctionnalité ne fonctionne pas). (août 2016))

  • Visual Studio Team Services facilite la mise en œuvre de votre version avec des agents basés uniquement sur le cloud (l’inconvénient est toutefois que chacun doit faire une recherche claire de votre référentiel pour chaque version, ce qui peut append une minute ou plus à la génération). Les deux peuvent également prendre en charge les agents de construction locaux qui n’ont pas besoin d’effacer le répertoire de travail pour chaque nouvelle version.

Mais dans les deux cas, je vous recommande fortement de regarder CakeBuild qui déplace la plupart des informations de configuration sur la façon de faire une compilation du système CI et dans le code C # qui se trouve dans votre référentiel Git avec tous vos autres codes source. Avec CakeBuild, vous pouvez exécuter la même version localement que dans le système CI et si vous devez revenir un mois en arrière pour créer une version spécifique, vous devez le faire avec le code source et le script de génération.

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

Le seul inconvénient de CakeBuild est que toutes vos étapes de construction sont regroupées dans une seule tâche dans le système CI, ce qui rend le reporting légèrement moins agréable et peut nécessiter un travail supplémentaire pour obtenir les résultats du test.

MS a des années de retard dans le domaine du TDD / CI

Etant un TDD depuis 4 ans, vous avez raison. MS ne fait même pas encore la promotion et n’offre pas non plus des outils qui fonctionnent bien avec le stream TDD.

Ne restz pas bloqué avec Visual Studio pour toute sorte d’automatisation, de contrôle de source ou de période de workflow agile (arrêtez d’utiliser TFS, s’il vous plait !!). Ces choses, même si elles sont “nouvelles”, sont monolithiques et comportent toujours des problèmes et des ballonnements étranges. C’est toujours douloureux.

J’ai utilisé Team City et c’est tout simplement incroyable, les choses fonctionnent, elles sont conçues pour être faciles à utiliser, elles sont simplement bien conçues et compatibles avec la plupart des outils de test, etc. Visual Studio pour code, rien d’autre. Recherchez des outils externes et open source pour vous aider à créer un meilleur CI. La vente “vous pouvez tout faire correctement dans VS” ne se vend pas et ne fonctionne pas. Les gens d’aujourd’hui sont habitués à combiner différents outils de l’extérieur pour faire avancer les choses. S’appuyer sur tous les jeux d’outils MS n’est pas la bonne façon de passer à IMO pour .NET. MS aime vendre “hé vous pouvez tout faire juste ici”. Mais vous vous retrouvez avec rien d’autre que de la douleur quand vous allez dans cette voie et buvez leur koolade (TFS, MS Fakes, etc.).

Si vous envisagez de faire du TDD, vous ne voulez certainement pas utiliser tous les outils MS. Vous serez soit poussé “à leur façon” de faire des choses qui sont souvent propriétaires et / ou gonflées lorsque vous essayez de TDD avec leurs outils ou soyez totalement ressortingctif. Pour TDD, vous devez être capable de faire preuve de souplesse et de choix lorsque vous décidez de mettre en couche différents frameworks de test, bibliothèques d’assertions, etc.

Ajoutez Octopus à Team City, et c’est génial… vous allez tout simplement en tomber amoureux en tant que développeur ou pour toute personne qui fait du DevOps.

Arrêtez d’essayer de vous fier à l’échec continu de Microsoft pour les offres d’outils agiles

Commencer à regarder en dehors des sentiers battus et à essayer de nouvelles choses, c’est ce que je répète sans cesse au monde .NET, étant un développeur .NET dans le passé et qui a essayé de nouvelles choses en dehors du monde de la SEP.