Cruise Control .Net vs Team Foundation Build [fermé]

Question

Notre équipe met en place des builds d'intégration continue et nocturne. Nous possédons Team Foundation Server et pourrions utiliser Team Foundation Build. Je suis plus familier avec CC.Net et je l’utilise de la sorte, mais la direction voit tout l’argent dépensé dans TFS et veut l’utiliser.

Certains points qui me plaisent davantage dans CC.Net sont la flexibilité des notifications ainsi que la facilité d’implémentation de scripts personnalisés.

Si vous connaissez les deux produits, lequel préférez-vous et pourquoi?

Answer 1

J'ai utilisé les deux. Je suppose que cela dépend des valeurs de votre organisation.

Puisque vous connaissez CC Net, je n’en parlerai pas beaucoup. Vous savez déjà ce qui le rend cool.

Voici ce que j'aime de Team Foundation Build:

• Agents de génération. Il est très simple de transformer n'importe quelle boîte en une machine de compilation et d’en exécuter une. MSFT l'a bien compris.
• Rapport. Tous les résultats de construction pertinents (test inclus) sont stockés dans une base de données SQL et sont signalés via SQL Server Reporting Services. Il s'agit d'un outil extrêmement puissant pour la création de graphiques et la vérification des résultats au fil du temps. CC Net ne l’a pas intégré.
• Vous pouvez effectuer des personnalisations similaires via MSBUILD. C'est fondamentalement la même chose que d'utiliser NAnt avec CC Net

Voici ce qui me motive à propos de Team Foundation Build:

• Pour générer des projets C ++ / CLI (ou exécuter des tests unitaires ...?), l'agent de génération doit disposer de VSTS Dev ou de Team Suite. Ceci, amis, est juste batsh * t fou.
• Il doit être connecté au bateau-mère TFS

Si vous êtes dans une grande organisation avec beaucoup de patrons qui ont des budgets énormes et des rapports d'amour (et ne vous méprenez pas, cela a une valeur énorme) OU vous devez passer à une ferme de construction multi-machine, Je préférerais Team Foundation Build.

Si vous êtes un magasin allégé, restez fidèle à CC Net et développez vos propres solutions de reporting. C'est ce que nous avons fait.

Jusqu'à ce que nous ayons acquis. Et obtenu TFS: P

Answer 2

Je suppose qu'en tant que propriétaire de TFS, vous l'utiliserez pour le contrôle de version. Dans ce cas, je me pencherais pour Team Foundation Build. Cela dit, je suis assez d'accord avec Nick .

J'ai écrit la intégration de CruiseControl.NET pour TFS . Cela fonctionne bien et vous donne les mêmes capacités de construction que celles auxquelles vous êtes habitués. Pour moi, le principal avantage de CC.NET est qu’il est totalement extensible et qu’il intègre des intégrations avec tous les principaux systèmes SCM et de systèmes bâtis sous le soleil. La principale raison pour laquelle j'ai écrit l'intégration CC.NET à TFS est que, dans TFS2005, le système de construction ne disposait pas d'une prise en charge CI immédiate. Cependant, la version TFS2008 est bien améliorée et l’équipe continue de l’améliorer très activement pour les futures versions de TFS.

La raison principale pour passer à TFS Build est de manière à ce que les informations de construction soient automatiquement rapportées dans TFS, ce qui permet de compléter la vision du développement logiciel en termes de reporting. Il s'intègre également parfaitement au côté suivi de l'élément de travail de TFS et à l'intérieur de l'EDI (à la fois dans Visual Studio et Eclipse).

Cela dit, si vous avez de gros investissements dans les scripts Nant qui ne font pas que compiler et tester votre code, ou si vous avez déjà une solution de création de rapports maison, vous pouvez vous en tenir à ce que vous avez.

Answer 3

La véritable valeur de Team Foundation Build réside dans le fait qu’il associe des ensembles de modifications et des éléments de travail à des générations.

Cela permet quelques scénarios utiles:

• Vous pouvez consulter un élément de travail et savoir quelle version il est inclus dans
.
• Vous pouvez regarder une construction et voir quels changements de code (et éléments de travail) elle inclut

Ensuite, il y a bien sûr les rapports construits à partir de ces informations. Mais même ces liens en eux-mêmes sont utiles aux types non-gestionnaires.

Consultez le site www.tfsbuild.com pour obtenir des "recettes". sur différentes configurations Team Build.

Answer 4

SVN est un outil bien supérieur, ce n’est pas vrai, SVN vs. TFS est similaire à un pick-up Ford par rapport à une Mercedes 500. Il fait le travail mais il n’est ni joli ni confortable, la fusion a beaucoup à faire. voulu. Je préfère l'outil de fusion TFS, car il semble que le responsable de la création de branches fonctionne parfaitement avec vous. Voilà à quel point c'est intelligent. Notre SVN interne a semblé beaucoup corrompu, c’est la raison pour laquelle nous l’avons laissé tomber et que nous sommes passés à TFS sans avoir regardé en arrière. La mise à l'écart des changesets est merveilleuse pour un atelier de développement agile, elle compte actuellement plus de 270 ingénieurs sur TFS, sans aucun problème, SVN n'était tout simplement pas capable de gérer ce type de charge sans que personne ne pose de problèmes.

Je préfère CC.NET simplement en raison des outils que nous avons développés en interne pour étendre les fonctionnalités de création de rapports et d'administration. La compilation de TFS est cependant très étroitement intégrée et nous prévoyons un basculement lors de la mise à niveau vers SQL 2008

Answer 5

Nous utilisons CruiseControl.net depuis juin 2007 et cela a très bien fonctionné pour nous. Mieux encore, il s’intègre facilement à SVN, qui est un fournisseur de contrôle de source bien supérieur.

Notre configuration est donc la suivante:

• Cruise Control.Net
• SVN
• Trac - pour les rapports de bogue et la gestion de projet (s'intègre parfaitement à SVN)
• nunit - pour les tests unitaires

Nous avons eu d'importants développements parallèles en cours et l'expérience en matière de création de branches et de fusion a été spectaculaire. Si vous avez le choix, j'irais avec la configuration ci-dessus!