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

Comparaison entre TeamCity et Visual Studio Team Services (la dernière offre de Microsoft basée sur le cloud) :

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

• TeamCity est plus mature et tout fonctionne.

• Visual Studio Team Services, en revanche, est en constante évolution pour rattraper TeamCity et certaines choses ne fonctionnent tout simplement pas bien (par exemple, essayer de déclencher des constructions basées sur des chemins qui ont des changements à partir de Git - la documentation est faible et la fonctionnalité elle-même ne fonctionne tout simplement pas (à partir d'août 2016)).

• Visual Studio Team Services permet de n'avoir que des agents basés dans le nuage pour exécuter votre construction (l'inconvénient est toutefois que chacun d'entre eux doit effectuer une extraction propre de votre dépôt pour chaque construction, ce qui peut ajouter une minute ou plus à la construction). Les deux peuvent également prendre en charge les agents de construction locaux qui n'ont pas besoin de nettoyer le répertoire de travail pour chaque nouvelle construction.

Mais dans un cas comme dans l'autre, je vous recommande vivement de regarder également CakeBuild qui déplace la plupart des informations de configuration sur comment pour faire une construction hors du système CI et dans le code C# qui est dans votre dépôt Git avec tous vos autres codes sources. Avec CakeBuild, vous pouvez exécuter la même construction localement que vous exécuterez dans le système CI et si vous avez besoin de revenir un mois en arrière pour construire une version spécifique, vous avez le code source et le build script pour le faire.

Avec CakeBuild en place, vous êtes maintenant libre de passer facilement de TeamCity à 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 le reporting un peu moins agréable et peut impliquer un travail supplémentaire pour obtenir les résultats des tests dans un format que le système de reporting CI peut utiliser.

Answer 2

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

Pour quelqu'un qui a fait du TDD depuis 4 ans maintenant, vous avez raison. MS n'en fait toujours pas la promotion et ne propose 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 flux de travail agile (arrêtez d'utiliser TFS s'il vous plaît !). Ce truc, même s'ils disent qu'il est "nouveau", est monolithique et vient toujours avec des problèmes bizarres et du ballonnement. C'est toujours pénible.

J'ai utilisé Team City et il est tout simplement incroyable, les choses fonctionnent, il est conçu pour être utilisable, et il est tout simplement bien conçu et compatible avec la plupart des outils de test, etc. J'utilise Visual Studio pour le code, rien d'autre. Recherchez des outils externes et open source pour aider à construire un meilleur CI. Le slogan "vous pouvez tout faire dans VS" n'est pas vendeur et ne fonctionne pas. De nos jours, les gens sont habitués à combiner différents outils externes pour faire avancer les choses. S'appuyer sur tous les outils de MS n'est tout simplement pas la voie à suivre pour .NET. MS aime vendre "hé, vous pouvez tout faire ici". Mais vous ne faites que souffrir lorsque vous suivez 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. Si vous essayez de faire du TDD avec leurs outils, vous serez soit poussé vers "leur façon" de faire les choses, qui est souvent propriétaire et/ou gonflée, soit totalement restreint. Pour le TDD, vous devez pouvoir disposer d'une certaine flexibilité et de choix lorsque vous décidez d'intégrer différents cadres de test, bibliothèques d'assertion, etc.

Ajouter Pieuvre en plus de Team City, et c'est stellaire... vous en tomberez tout simplement amoureux en tant que développeur ou pour quiconque fait du DevOps.

Arrêtez d'essayer de compter sur l'échec continu de Microsofts en matière d'outils agiles.

Commencez à regarder en dehors de la boîte et essayez de nouvelles choses, c'est ce que je ne cesse de répéter au monde .NET, moi qui suis un développeur .NET dans le passé et qui a essayé de nouvelles choses en dehors du monde MS.