Quel cadre d'intégration continue utilisez-vous et pourquoi? [fermé]


21

Il existe plusieurs cadres d'intégration continue (CI) différents et je me demande lequel est le plus populaire. Quels cadres avez-vous utilisés dans les entreprises où vous travaillez?

Y a-t-il une raison pour laquelle un framework CI est plus populaire qu'un autre - peut-être est-ce à cause des fonctionnalités qu'il offre, des choses qui s'y intègrent ou peut-être de son marketing juste?

Il semble que l'intégration continue soit davantage utilisée dans les mondes Java et .net que ruby ​​ou python. Pourquoi est-ce?


L'une des raisons pour lesquelles CI n'est pas si pertinent avec Ruby et Python est que les langages sont interprétés, donc pas besoin de compiler quoi que ce soit. Mais ce n'est que mon opinion personnelle ...
mliebelt

1
@mliebelt --CI s'étend à plus que de simples compilations de chèques. Vous pouvez exécuter des tests unitaires / d'intégration (même avec d'autres projets dépendants).
Apoorv Khurasia

Réponses:


31

Hudson ou Jenkins (ce dernier est une fourchette du premier). Raison: il est simple (simple à installer et à utiliser) et très flexible. Les plugins ajoutent presque toutes les fonctionnalités auxquelles je peux penser.

Il y a quelques années, j'ai utilisé damagecontrol . Il était également simple à utiliser, mais n'avait pas les plugins. Mais l'auteur a décidé qu'il abandonnerait la solution simple et a commencé le développement d'une nouvelle version, qui consistait en différents serveurs communiquant entre eux (qu'est-ce qui se passe?). Cela n'a pas bien fonctionné et le projet a été abandonné. J'étais à la recherche quelque temps, mais ni cruisecontrol (trop compliqué) ni continuum ne m'ont vraiment eu. Jusqu'à Hudson, cela a fonctionné dès le premier instant pour moi.


Je vais également ajouter une interface utilisateur décente à cela.
Martijn Verburg

Oui, je résumerais l'interface utilisateur sous simple à utiliser.
Mnementh

5
CruiseControl a été difficile à démarrer ... Hudson était si facile à mettre en service. Le plugin Chuck Norris ( wiki.hudson-ci.org/display/HUDSON/ChuckNorris+Plugin ) est un must.
Sam Dolan

Hudson est vraiment super. Cependant, je souhaite que ce soit mieux à l'isolement. Si vous avez un bon nombre d'équipes différentes travaillant toutes sur des projets vaguement liés, le potentiel de marcher les uns sur les autres est plutôt élevé.
Greg Gauthier

Ce programmeur ne peut toujours pas configurer Hudson pour fonctionner sur Windows :(
Mchl

16

J'utilise TeamCity au travail et à la maison. Il prend en charge une grande variété de coureurs de build et est extensible via des plugins.

Ne pas traiter de piles de XML pour la configuration est un énorme avantage dans mes livres et la version gratuite est suffisante pour mes besoins domestiques.

Un problème que j'ai rencontré avec TeamCity a à voir avec le fait de l'obtenir pour la version automatique des assemblys .NET. J'ai dû mettre en place une solution de contournement relativement compliquée, mais une fois en place, cela a fonctionné comme un charme.


Je vais essayer TC à la maison. Nous n'avons eu que des problèmes avec cruisecontrol.net.
Personne

8

Personnellement, je n'ai utilisé que CruiseControl et CruiseControl.Net. La raison en est liée à l'économie. Ils sont raisonnablement stables et une fois que vous les avez installés, il n'y a vraiment pas grand-chose à faire pour les maintenir. La communauté d'utilisateurs est généralement très utile et peut être étendue à vos besoins.

Cela dit, je connais quelques offres commerciales disponibles (une par JetBrains, l'autre par Atlassian) qui offrent une meilleure expérience de configuration et un support commercial. J'avais l'intention d'essayer ces offres, mais je n'ai vraiment pas encore eu la chance.

Les outils CI ont un rôle plus important à jouer avec les langages compilés que les langages interprétés, mais cela ne veut pas dire que l'outil CI est gaspillé en langages interprétés. Lorsque vous avez plusieurs projets qui dépendent les uns des autres et que vous voulez vous assurer qu'un changement ne casse pas accidentellement ses dépendances - les outils CI sont inestimables.

Il existe trois classes générales de problèmes que les outils CI peuvent vous aider à détecter:

  1. Compiler les erreurs - si la signature d'une classe change d'une manière qui brise les dépendances, il est préférable de le savoir avant les heures de gain d'un livrable.
  2. Erreurs logiques - si le comportement d'une classe change d'une manière qui rompt les dépendances, il est préférable de le savoir tôt. Cela doit être vérifié par une sorte de test automatisé, le plus souvent des tests unitaires.
  3. Test d'acceptation - si vous avez une suite automatisée de tests à exécuter sur le produit fini, il est préférable de les exécuter souvent.

Les langages interprétés ne sont pas compilés, il n'y a donc aucune erreur de compilation à détecter. Cependant, les deux autres problèmes sont suffisamment communs pour que les outils CI soient utiles pour les projets dans Ruby / Python / Perl / etc.

Le mot clé à la fois dans les erreurs logiques et les points de test d'acceptation est le test "automatisé". Si vous ne disposez pas d'une suite de tests qu'une machine peut exécuter, alors vous manquez vraiment les plus grands avantages des outils CI. Les suites automatisées peuvent être construites avec le temps, vous pouvez donc commencer petit.

modifier

Voir ce joli graphique pour les comparaisons de fonctionnalités d'un grand nombre d'outils CI (dont beaucoup je ne connaissais pas):

http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix


La distinction compilée / interprétée n'est pas si noire et blanche. Par exemple, Perl a une phase de compilation qui s'exécute au démarrage (et peut être invoquée séparément avec l'option "-c") pour vérifier les erreurs de syntaxe.
Andrew Medico

C'est vrai. Ruby 1.9 et Python ont également des phases de compilation. La classe d'erreur de compilation du problème s'applique à tout langage qui vous alertera si la classe / variable / méthode de référence n'existe pas pendant la compilation. Cela s'applique certainement à toute langue typée statiquement. YMMV sur des langages typés dynamiques mais forts (comme Ruby et Python).
Berin Loritsch

"une fois que vous les avez configurés, il n'y a vraiment pas grand-chose à faire pour le maintenir" - n'est-ce pas vrai pour tous les serveurs d'intégration continue?
Bryan Oakley

5

Serveur Team Foundation

CI solide, intégration étroite avec Visual Studio et Git comme contrôle de version . J'ai vu des serveurs CI plus flexibles, comme Hudson, mais l'intégration étroite de TFS avec d'autres produits rend l'expérience si transparente qu'elle a du sens pour mon équipe.


Par «autres produits», vous entendez «produits Microsoft». Je ne vous critique pas, mais MS a structuré sa pile technologique de sorte que pour s'intégrer aux produits MS, vous avez besoin d'autres produits MS, ou beaucoup de patience et / ou de persévérance.
GKelly

1
Une absurdité totale. Ils ont des API et des SDK pour presque tout ce qu'ils font, même les Kinect, mais les programmeurs non-MS ne savent pas, car ils se couvrent les oreilles dès qu'ils entendent Micros .. (lien vers le SDK TFS) msdn.microsoft.com/ fr-fr / library / bb130146 (v = VS.80) .aspx
Luke Puplett

2

J'utilise à la fois CruiseControl.NET et Hudson . Certains de mes builds sont sur l'un d'eux et certains sur l'autre.

Pourquoi? Parce que je ne suis pas l'ingénieur de construction et que celui qui est l'ingénieur de construction les a configurés de cette façon!

Je n'ai pas de problème avec la façon dont mes builds sont configurés ou des plaintes concernant l'un ou l'autre produit. Je vous informe de la façon dont les choses sont ici, en fait et j'espère que vous appréciez cette perspective!

MISE À JOUR: Depuis que j'ai posté la réponse, Hudson a été bifurqué et est devenu Jenkins . La recommandation ci-dessus s'applique à Jenkins.


1

Impulsion . Cela fonctionne simplement, ce qui est un gros problème pour un ingénieur de construction occupé. Ils ont également un excellent support technique. La principale raison pour laquelle je l'aime tellement, c'est que nous avons plus de 250 projets et qu'il les gère sans hoquet; Je ne peux pas en dire autant de Hudson.


1

Notre équipe travaille principalement en Python, C ++ et Java. Nous utilisons Buildbot pour CI. Nous l'avons d'abord commencé parce qu'il s'intègre à Trac et parce qu'il semblait simple et direct. Je crois que c'est le cadre CI de choix dans le monde Python.


1

Hudson. C'est parfois un petit buggy, et certains des plugins les plus intéressants ne fonctionnent pas réellement, mais avec un peu de prise en main, c'est assez utilisable.

J'utiliserais probablement Pulse à la place, mais si vous devez construire sur plusieurs plateformes, c'est> 5k $, ce qui est un peu trop.


1

CruiseControl.NET pour une intégration continue. Fonctionne assez bien, bien qu'avec le très grand nombre de projets de construction que nous avons mis en place dans CruiseControl, l'application de plateau de bureau CCTray est horriblement non réactive, même avec de longs intervalles de rafraîchissement.

NAnt est destiné aux scripts de construction qui sont exécutés dans les projets CruiseControl. Pour les scripts de construction plus complexes, nous avons étendu NAnt avec des tâches C # NAnt personnalisées, ce qui est très agréable - l'écriture de code en C # est beaucoup plus agréable que la création de scripts NAnt.

Nous sommes une boutique Microsoft et nous allons théoriquement passer à Team Build 2010 de Microsoft une fois que nous aurons migré notre environnement Team Foundation Server vers 2010.


0

Notez que vous devriez pouvoir créer votre application à partir de la ligne de commande, que vous ayez un moteur CI en cours d'exécution ou non.

Cela signifie que tout ce que fait le moteur CI est de systématiser vos appels de build, et vous pouvez choisir le moteur qui correspond le mieux à vos besoins particuliers.

PErsonally j'aime Hudson principalement parce qu'il "se sent" bien, mais je sais que si tout échoue, je peux passer à un autre sans trop d'effort. Si c'est le cas, j'envisagerais probablement d'abord celui d'Atlassian, car j'aime la "sensation" des autres programmes qu'ils font.

Notez que l'interchangeabilité implique qu'il n'importe pas dans quelle langue ils sont écrits. Je crois que Java a été choisi pour de nombreux moteurs car les nombreuses plates-formes prises en charge, combinées avec les nombreux blocs de construction facilement disponibles. Besoin d'un serveur Web - prenez-en un. Besoin de nombreux threads simultanés - utilisez-les simplement. Besoin d'extensibilité - déposez dans un pot.


0

Avant que j'entende le terme "intégration continue" (c'était en 2002 ou 2003), j'ai écrit un script de construction nocturne qui se connectait aux cv, j'ai récupéré une copie propre du projet principal et des cinq sous-projets plus petits, construit tous les jars via ant puis construit et redéployé un fichier WAR via un deuxième script ant qui a utilisé les tâches de fourmi tomcat.

Il a fonctionné via cron à 19 heures et envoyé un e-mail avec un tas de fichiers de sortie joints. Nous l'avons utilisé pendant les 7 mois entiers du projet et il est resté en service pendant les 20 prochains mois de maintenance et d'améliorations.

Cela a bien fonctionné mais préfère toujours hudson aux scripts bash, cron et ant.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.