TFS 2008/2010 vs Jenkins für Continuous Integration
Hat jemand konkrete Erfahrungen mit der Verwendung von TFS 2008/2010 UND Jenkins für Continuous Integration (CI)? Wir versuchen zu entscheiden, welche CI-server zu verwenden. Unser team arbeitet ausschließlich im Microsoft .NET/Visual Studio 2010/C#. Wir haben die folgenden Anforderungen:
- Automatisch erstellen unsere web-Projekt auf jedem checkin.
- Unit-tests mit jedem build.
- Automatisch bereitstellen, grün baut, um die Entwicklung und/oder test-Umgebungen.
- Geben ziemlich berichten.
- Bieten build - /deployment-Benachrichtigungen per E-Mail.
Merke ich, dass die Installation von einem tool nicht unbedingt geben uns diese Funktionalität out-of-the-box, und dass wir für die Integration mit anderen tools wie MSBuild, dies zu erreichen.
Ich bin auf der Suche nach bestimmten Funktionen, Jenkins, TFS 2008/2010 nicht oder Umgekehrt. Auch die einfacher zu pflegen, verwenden, usw.
Nur aus der hand, Jenkins können Sie all diese Dinge (TFS-SCM-plugin, MSBuild-plugin deploy-to-X-plugins), obwohl "schöne Berichte" - Teil kann verlangen, einige Mühe auf Ihrem Teil. Aber dafür gibt ' s eine ziemlich umfassende API zum abrufen von build-info und so weiter, die helfen könnten.
Auch Jenkins ist wirklich wirklich leicht zu pflegen und zu nutzen. Man kann alles mit dem browser, alle Optionen sind verständlich Kontext-Hilfe und die community ist sehr aktiv und hilfsbereit.
Auch Jenkins hat die Chuck-Norris-plugin, das ist ein absolutes muss für shaming-Entwickler, die gegen das bauen. TFS-nicht bieten dieses außergewöhnliche feature-plugin.
Auch Jenkins ist wirklich wirklich leicht zu pflegen und zu nutzen. Man kann alles mit dem browser, alle Optionen sind verständlich Kontext-Hilfe und die community ist sehr aktiv und hilfsbereit.
Auch Jenkins hat die Chuck-Norris-plugin, das ist ein absolutes muss für shaming-Entwickler, die gegen das bauen. TFS-nicht bieten dieses außergewöhnliche feature-plugin.
InformationsquelleAutor Doug | 2011-10-05
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ich würde empfehlen, mit Jenkins - es wird alle deine Anforderungen out of the box abgesehen von eventuell #3, aber wenn Sie können ein Skript Ihre Einsätze dann kann es das auch tun.
Hier sind einige links, die Ihnen helfen, Ihr baut und läuft:
Blog über das tun .NET-builds in Jenkins
Jenkins Windows-Installern
Die Installation der Jenkins master und slaves, die als Windows-Dienste
Disclaimer: ich habe keine Erfahrung mit TFS, aber ich denke, dass offene Lösungen sind fast immer mehr flexible und erweiterbare (und billiger !) als proprietäre Produkte.
Ich habe TFS weitgehend in der Vergangenheit, und ich bin derzeit die Durchführung Jenkins für einen client und ehrlich gesagt, es ist 6 in der einen und ein halbes Dutzend der anderen. TFS hat erstaunliche VS IDE-integration, eine Tonne von open-source-Erweiterungen auf CodePlex und verwendet die Windows Workflow Foundation für die einfache Erweiterbarkeit, während Jenkins hat eine schöne open-source-Reihe von Plug-ins eine dlarge Gemeinschaft von Benutzern, wenn Sie sind ein .NET shop und schreiben wollen, ein plug-in für es die Sie tun müssen, damit in Java.
InformationsquelleAutor gareth_bowles
Spät zu diesem Spiel, aber ich habe beide TFS 2010 und Jenkins für CI. TFS 2010 hat minimalen Satz von CI-tools. Allerdings, wenn Sie möchten, erstellen Sie ein CI-pipeline, es ist eine völlig andere Geschichte, während Jenkins kann einfach erzeugen der pipeline.
Wenn Sie auf der Suche bei nur CI für ein build von beiden sollte funktionieren. Allerdings, wenn es um die gesamte pipeline, Jenkins Weg zu gehen. Mit TFS-es kann getan werden, aber Jenkins ist die bessere Wahl.
Hier ist schnelle Punkte:
TFS:
Mit einer build-definition können Sie kompilieren, ausführen von tests, Rückkehr changeset/workitems, senden Sie eine E-Mail, wenn ein build ist gebrochen
Natürliche integration mit visual studio
extrem schwer zu schaffen, CI-pipeline. Erfordert benutzerdefinierter handler und umfangreiche workflow-Arbeit. Nicht so intuitiv wie das erstellen einer build-definition.
Weil der 3. Kugel, es ist nicht leicht zu pflegen/anpassen/skalieren CI-pipeline
Jenkins:
Brauchen zu erstellen eine msbuild-config-Datei für CI, was nicht viel ist Schmerzen im Vergleich zu der Erstellung CI-pipeline mit TFS. Allerdings TFS gibt bessere/einfachere Tools zum erstellen einer build-definition. jedoch, es ist nicht schlimm, erstellen der config Datei msbuild für ein Projekt.
Erstellen einer CI-pipeline ist sehr einfach. Nur die Kette Sie mit upstream - /downstream-jenkins-job-trigger übergeben und ein Artefakt aus früheren Jobs.
Da Jenkins ist sehr flexibel, es ist leicht zu erstellen, ein jenkins-plugin, um Ihre individuellen Bedürfnisse und bieten es zu Open-Source-community 🙂
In Zusammenfassung, wenn Sie brauchen, vollständige, automatisierte build -, test-und deployment-system gehen mit Jenkins. Wenn Sie nur brauchen, nur das zu bauen und zu testen, TFS könnte Ihnen einen Rand über Jenkins.
InformationsquelleAutor Shane
Wenn Sie Team 2010-2012, es gibt keinen Grund zu bringen Jenkins. Team hat alle Funktionen, die Sie aufgelistet, und der build-Prozess ist unglaublich flexibel.
Beachten Sie, dass, wenn Sie stecken bleiben auf Team 2008 oder früher, sollten Sie ernsthaft betrachten Jenkins -- 2008 und früher sind ziemlich primitiv und unflexibel im Vergleich zu 2010 oder später.
Ich habe gekämpft, mit diesem vor kurzem versucht, um eine vollständige TFS automatische erstellen und bereitstellen von Azure, und es ist "WEG" länger, um zu arbeiten, als es sein sollte. Das problem ist, dass die kontinuierliche integration von templates automatisch Holen die erste web-Projekt in die Lösung zu bereitstellen... aber ich habe zwei, und alphabetisch, es wählt immer den falschen. Keine Optionen sagen es anders, und so, jetzt ich ' m kämpfen mit anpassen des deployment-template zu bekommen, um dieses große Aufsicht in out-of-the-box-design.
Haben Sie sich überlegt, dass zwei builds?
InformationsquelleAutor Stu