Team Foundation Build ou TeamCity?
Nous sommes principalement une boutique MS en train de faire du développement .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 c'est rapidement en voie de disparition.
Nous commençons notre initiative de mise en œuvre de TDD dans toute l'équipe (~ une dizaine de personnes). J'ai obtenu la configuration TeamCity et j'ai réussi à exécuter mes premières versions automatisées avec le générateur sln 2008 et également avec SVN qu'un collègue avait configuré et qui effectuait l'analyse du contrôle de source. Lors de la démonstration de la gestion, je pense qu'ils ont commencé à acheter mon huile de serpent et ont rejeté les suggestions de recherche dans 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 tout simplement trop cher et n'en valait pas la peine pour notre équipe (et j'ai vu la même chose dans d'autres magasins où j'ai travaillé/que je connais). J'ai l'impression que MS a des années de retard dans le domaine TDD/CI et que les produits tiers étaient probablement bien meilleurs et plus matures ... J'ai encore besoin de faire beaucoup de recherches, mais j'ai pensé que je viendrais ici pour voir si quelqu'un a réellement utilisé les deux systèmes.
Je me rends compte que le TFS englobe beaucoup plus qu'un simple serveur de build ... mais je ne voulais pas faire de cette question trop large au moins exprès. Quels sont les avantages/inconvénients pratiques de l'utilisation de TFS/TFB au lieu de TeamCity - par exemple, quels avantages perdrions-nous/gagnerions? Quelqu'un ici a-t-il réellement utilisé les deux systèmes (TFS pour TDD/CI et TeamCity/SVN) et peuvent parler d'un point de vue pratique?
J'ai fait quelques recherches sur ce sujet, et un article que j'ai trouvé ici sur SO a mentionné que le contre de TFB était qu'il ne supportait que MSBuild. Je prévoyais d'utiliser FinalBuilder avec TeamCity; et il semble qu'il prend également en charge TFS aussi ...
Merci pour tout conseil
EDIT: Quelqu'un a-t-il utilisé TFS comme serveur Build/CI et peut raconter des histoires de réussite/échec?
Nous sommes une petite boutique de développement et avons décidé que Team Foundation Server supporte trop de frais généraux pour nous. Nous avions l'habitude d'écrire des scripts MSBuild personnalisés à exécuter à partir de la ligne de commande, mais après avoir découvert TeamCity, nous y avons déplacé l'intégralité de notre processus de génération.
Nous avons trouvé TeamCity facile à utiliser et à configurer, et JetBrains fournit un excellent support et une excellente documentation. Ils sont également sur un cycle de mise à jour 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, afin que nous puissions l'évaluer pour voir si cela fonctionnait pour nous. Nous n'avons pas atteint le nombre de configurations de projet (20) qui nous obligeraient à passer à l'édition Enterprise.
Cette question a beaucoup de bonnes réponses sur TeamCity. Cela ne se compare pas à TFS, mais cela pourrait vous éclairer sur TeamCity.
J'ai utilisé les deux, et j'ai réussi avec les deux, mais TeamCity était tellement plus facile. TeamCity était un jeu d'enfant à installer et à configurer. TFS ne l'était pas. TeamCity est solide comme le roc, il est facile à entretenir et il fonctionne tout simplement. Les développeurs de JetBrains ont fait un excellent travail en répondant à la communauté. Ils reçoivent une sortie tous les 6 à 8 mois qui ajoute une réelle valeur. TFS est sur 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 sommes également très satisfaits du modèle d'agent dont il dispose.
Je suis passé par 3 mises à niveau absolument douloureuses dans TeamCity. La seule mise à niveau TFS que nous avons effectuée a supprimé notre contrôle de génération et de source pendant 3 jours. Je suis l'administrateur de TeamCity sur notre projet et cela prend quelques heures par mois. TFS prenait 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 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 de code source et j'ai eu un certain nombre de problèmes avec celui-ci. Il est maladroit, mais il avait l'avantage d'avoir l'intégration VS (qui est également disponible dans VisualSVN, mais n'est pas aussi robuste).
Personnellement, je pense que vous seriez beaucoup mieux en utilisant SVN/TeamCity. Il est simplement plus facile de travailler avec et se comporte plus comme prévu. Comme avec la plupart des logiciels open source, les deux évoluent constamment et auront toujours la dernière et la plus grande fonctionnalité 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 suivre cette voie dans mon entreprise actuelle (nous utilisons TFS), car je pense que c'est un flux de travail bien meilleur. Comme avantage supplémentaire, il est nettement moins cher que d'opter pour la route TFS.
J'ai également utilisé FinalBuilder avec TFS - ma question est ce que vous achetez vraiment avec FinalBuilder que vous ne pouvez pas faire avec NANT/MSBuild? La réponse dans ma boutique est malheureusement très peu IMO.
Tout d'abord, consultez cet article:
En ce qui concerne votre question sur l'environnement qui favorise le mieux le TDD et autres, je pense que le système de gestion de build importe beaucoup moins que ce qui se trouve dans le fichier de build 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, si CruiseControl l'est, ou si TeamCity l'est. Les smarts sont tous dans le fichier de construction et les outils que vous intégrez avec lui.
Mon choix personnel n'est pas de m'enfermer dans la façon de faire de TFS, car vous avez beaucoup plus de liberté pour beaucoup moins de coûts avec les outils de test open source riches qui existent. TFS est sur le point de recevoir également une mise à niveau majeure. Si vous allez utiliser TFS, mon conseil est d'attendre au moins jusqu'à la sortie de 2010. Concentrez-vous sur l'amélioration de la qualité de vos fichiers MSBuild dès maintenant.
Cela étant dit, je dois admettre que TFS possède l'un des systèmes de construction les plus agréables du marché (2005 a été terrible, 2008 était agréable). Être en mesure de personnaliser facilement les notifications et le processus de publication dans le code .NET était plutôt cool - vous disposiez d'un contrôle beaucoup plus central sur la politique de création et de publication que nous ne le faisions 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 build devrait être relativement indépendant de ce qui est construit et de la façon dont il est construit. Pour nous, le contrôle supplémentaire du processus de gestion des versions que TFS nous a apporté n'était tout simplement pas suffisant pour justifier l'effort administratif considérablement accru d'une solution TFS entièrement intégrée. Cela ne suffisait pas non plus à justifier le coût supplémentaire par licence de TFS, qui peut être important.
L'ancien build TFS était basé sur XAML et était très encombrant et n'était pas agréable à utiliser. Cela dit, le nouveau système de construction TFS 2015 est meilleur que jamais, et est basé sur des scripts avec de nombreux crochets Web et intégrations tierces; très similaire à Team City. En outre, TFS prend désormais en charge Git, vous n'êtes donc plus limité à 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 génial car il s'agit d'un environnement complètement intégré (éléments de travail, planification, builds, tests, déploiements), tandis que Team City n'est qu'une solution de build. Lorsque cette question a été posée à l'origine en 2010, j'aurais recommandé Team City haut la main. Maintenant, cependant, les 2 sont très compétitifs. Je dirais que cela se résumerait peut-être à si vous voulez une solution tout-en-un, alors optez pour TFS, mais si vous recherchez uniquement un système de build, alors Team City.
Comparaison de TeamCity avec Visual Studio Team Services (la dernière offre cloud 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.
Visual Studio Team Services, en revanche, évolue constamment pour rattraper TeamCity et certaines choses ne fonctionnent tout simplement pas bien (par exemple, essayez de déclencher des builds basés sur des chemins qui ont des changements de Git - la documentation est faible et la fonctionnalité elle-même ne fonctionne tout simplement pas (en août 2016))
Visual Studio Team Services permet de ne disposer que d'agents basés sur le cloud pour exécuter votre build (l'inconvénient est cependant que chacun doit effectuer une extraction nette de votre référentiel pour chaque build, ce qui peut ajouter une minute ou plus à la build). Les deux peuvent également prendre en charge les agents de génération locaux qui n'ont pas besoin d'effacer le répertoire de travail pour chaque nouvelle génération.
Mais dans les deux cas, je vous recommande vivement de regarder également CakeBuild qui déplace la plupart des informations de configuration sur comment pour faire une construction à partir du système CI et dans le code C # qui se trouve dans votre référentiel Git avec tous vos autres codes sources. Avec CakeBuild, vous pouvez exécuter la même build localement que vous exécuterez dans le système CI et si vous devez remonter un mois pour créer une version spécifique, vous avez le code source et le script de build pour le faire.
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 en une seule tâche dans le système CI, ce qui rend les rapports légèrement moins agréables et peut impliquer un travail supplémentaire pour obtenir les résultats des tests dans un format que le système de rapports CI peut utiliser.
MS a des années de retard dans le domaine TDD/CI
Étant celui qui a TDD depuis 4 ans maintenant, vous avez raison. MS n'en fait même pas la promotion et n'offre pas d'outils qui fonctionnent bien avec le flux TDD.
Ne restez pas coincé avec Visual Studio pour tout type d'automatisation, de contrôle de source ou de période de workflow agile (arrêtez d'utiliser TFS s'il vous plaît !!). Ce truc, même s'ils disent que c'est "nouveau" est monolithique et vient toujours avec des problèmes étranges et des ballonnements. C'est toujours douloureux.
J'ai utilisé Team City et c'est tout simplement incroyable, les choses fonctionnent, il est conçu pour être utilisable, et il est simplement bien conçu et compatible avec la plupart des outils de test, etc. Utilisez finement Visual Studio pour le code, rien d'autre. Recherchez des outils externes et open source pour aider à construire un meilleur CI. La vente "vous pouvez tout faire correctement dans VS" ne se vend pas et ne fonctionne pas. De nos jours, les gens sont habitués et combinent toujours différents outils de l'extérieur pour faire avancer les choses. S'appuyer sur tous les ensembles d'outils MS n'est tout simplement pas la voie à suivre pour l'OMI pour .NET. MS aime vendre "hé, vous pouvez tout faire ici". Mais vous vous retrouvez avec rien d'autre que de la douleur lorsque vous empruntez cette voie et buvez leur koolade (TFS, MS Fakes, etc.).
Si vous prévoyez de faire TDD, vous ne voulez certainement pas utiliser tous les outils MS. Vous serez soit poussé vers le bas "leur façon" de faire des choses qui est souvent propriétaire et/ou gonflé lorsque vous essayez de TDD avec leurs outils ou soyez totalement restrictif. Pour TDD, vous devez avoir une certaine flexibilité et des choix lorsque vous décidez de superposer dans différents cadres de test, bibliothèques d'assertions, etc.
Ajoutez Octopus au-dessus de Team City, et c'est stellaire ... vous en tomberez simplement amoureux en tant que développeur ou pour quiconque fait du DevOps.
Arrêtez d'essayer de compter sur Microsofts échec continu aux offres d'outils agiles
Commencer à regarder en dehors des sentiers battus et essayer de nouvelles choses est ce que je n'arrête pas de répéter dans le monde .NET, étant moi-même un développeur .NET dans le passé et qui a essayé de nouvelles choses en dehors du monde MS.