Hallo zusammen

Ich möchte mich in nächster Zeit intensiv mit den Themen Continuous Integration / Continuous Deployment beschäftigen.
Dazu gehören natürlich auch Unit Tests und Code Analysis.

Meine Fragen an euch:
Welche Produkte setzt ihr in eurer Firma ein? In welcher Kombination?
Welche Erfahrungen habt ihr mit den verwendeten Produkten gemacht?

Speziell interessieren würden mich auch Erfahrungen mit nicht-Microsoft Software. Ich kenne bisher nur TFS (allerdings nicht als CI-System).
Es gibt ja diverse erhältliche Tools:

• CruiseControl.NET
• Draco.NET
• TeamCity
• Hudson
• Usw.

Wir sind noch unschlüssig welche Tools wir intern als Standard definieren wollen.

Gruss Kantiran

Da wir im Haus Jira als Bugtracker einsetzen, und Subversion für uns mit entfernten Entwicklern deutlich einfacher als TFS war, war auch bei uns ein nicht MS Tool für CI die erste Wahl.

Und da hat nach längerem Test dann Teamcity das Rennen gemacht.
Einer der ausschlaggebenden Punkt war die Admin UI.
Die ist per WebInterface auch einfach über die VPN zu erreichen.

Das die kostenlose Version dann auch noch 20 Projekte und auch 3 Buildagents unterstützt hat es noch einfacher gemacht.

Ich benutze schon seit längerer Zeit CruiseControl.Net und bin damit auch recht zufrieden.
XML-Basierte Konfiguration mit Präprozessor, durch Plugins und XSLT erweiterbar, unterstützt viele Sourcecontrol Systeme und das beste: it's free!

Wir benutzen Mercurial als Versionsverwaltung und TeamCity (die kostenlose Edition) als CI-Server.

Wir haben gar keinen anderen CI-Server ausprobiert - am meisten liest man über TeamCity und CruiseControl.net, und als ich gelesen habe daß CC.net per XML konfiguriert wird und TeamCity eine richtige UI hat, habe ich mich dafür entschlossen TeamCity als erstes auszuprobieren. Und dann bin ich direkt dabei geblieben

Ich hab damals zur Urzeiten mit Teamcity angefangen - damals war das aber alles noch nicht so schön einfach und übersichtlich gehalten :-)

Irgendwann hab ich mir dann CruiseControl.net angeschaut und bin dabei stehen geblieben.

CruiseControl.net ist jetzt Hauptbestandteil.
Subversion und Sourcesafe als Quellcodeverwaltung.
MSBuild kompiliert die Projekte.
NAnt führt zusätzliche Aufgaben (z.b. FTP-Upload) aus.
Und die Setups werden mit WIX geschrieben und über NAnt mit erledigt.

Das ist schon alles etwas komplex und langwierig bis man es so eingestellt hat wie man es braucht.
Aber wenn man es benutzen kann, dann sieht man sehr sehr viele Vorteile in dieser Flexibilität :-)


Ahh Edit:
Projektverwaltung mit Tickets bzw Bugrequests und Wiki machen wir mit Redmine :-)

Wir verwenden folgendes:

* CI: TeamCity (wir haben sowohl Projekte in Java als auch .NET)
* Versionsverwaltung: SVN
* Bugrtracking: Mantis
* Setups werden mit WIX erstellt (der Aufruf erfolgt über ein selbst erstelltes Programm das die .wxs-Dateien erstellt)
* zusätzlichen haben wir noch ein internes Wiki zur Projektverwaltung und allgemeine Firmeninformationen

Einzig mit Mantis bin ich nicht so ganz zufrieden, hier würde ich gerne Trac einsetzen und auch gleich das Wiki integrieren. Leider haben wir momentan keine Kapazitäten frei um das umzubauen.

TeamCity überzeugt vor allem durch die hervorragende Web-GUI (wie FZelle scho gesagt hat).

CI: TeamCity
Versionsverwaltung: Git, what else? (Gitorious) ;)
Task/Bug-Tracking: Jira
Projektverwaltung/Planung: GreenHopper
Interne Dokumentation: In den Wikis von Gitorious

Hallo zusammen

Vielen Dank für die Antworten.
Wie ich sehe wird TeamCity und CruiseControl.NET oft benutzt. Ich werde mir diese genauer ansehen und mit TFS vergleichen.

Verwendet ihr diese Tools auch zusammen mit NUnit, FxCop oder den entsprechenden VS-Tools?
Ist Continuous Deployment auch ein Thema (automatisiertes Staging, d.h. installieren des Setups auf einem Testsystem)?

Gruss Kantiran

NUnit und FXCop gehen sofort.
Und mit VS-Tools meinst du was?

Und da du mit allen CI systemen Ant oder MSBuild ( und einige andere ) benutzen kannst,
ist da ja alles möglich was sich eben automatisieren lässt.

Ich meine die in VS Integrierten Tools für Unit Tests ("MS Testprojekt") und Code Analysis.
Soweit ich das richtig verstanden habe unterscheiden sich die VS Code Analysis und FxCop (auch wenn gleiche Assemblies verwendet werden).

...aber warscheinlich lässt sich wie geasagt alles mittels MSBuild anbinden.

Das Problem ist dann nur die Lizenzierung.

Zum reinen Übersetzen der Sourcen benötigst du kein VS.NET, benutzt du aber die MS Unittests und die in VS.NET eingebauten CA Tools, benötigst du ein installiertes VS.NET und damit eine einzelne Lizenz.

Bei mir läuft unter CCNet unter anderem nUnit für Unittests (direkt beim Build), Scheduled für jeden Tag Integration Tests (mit Datenbank usw), Code Coverage über PartCover, Nightly Build Deployment auf ein Netzwerklaufwerk sowie für interne Anwendertests und Produktauslieferungen ein InstallShield Standalone build für Setups.

Zusätzliche Werkzeuge sind bei uns noch NUnit und MSpec für die Tests, und NCover für die Code-Coverage.

[offtopic]

Zitat von Sclot

Projektverwaltung mit Tickets bzw Bugrequests und Wiki machen wir mit Redmine :-)

Bugrequest - was ein cooles Wort - das Analogon wäre dann der Featurereport (auch als "Bedienungsanleitung" bekannt) ;)

[/offtopic]

Benutzen bei uns:

* CruiseControl.NET: automatische Builds (Zeit und andere Trigger), Staging, Tests, ...
* MSTest: Für die Unit-Tests
* Sharepoint: Für Tickets, Task, Bug-Tracking, Wiki, ...
* MSBuild zusammen mit CCnet fürs Builden
* Und die CodeCoverage Tools von VS für Metriken und CodeCoverage
* SVN als Code-Repository

Sind soweit zufrieden mit dieser Konstellation. CCnet macht alles was wir wollen, benötigt aber einiges an Zeit bis alles Konfiguriert ist.

Hmm, mir ist Folgendes noch nicht ganz klar:
Egal welches CI-System ich verwende (TFS, TC, CC) die Build-Skripts (MSBuild, NAnt) wenden in jedem Fall von Hand geschrieben?

Was nimmt mir denn das GUI von TC beispielsweise ab?
...Ich bin wirklich Neuling in diesem Gebiet.

Btw.: Habe gerade gesehen das TFS 2010 den Build als WF-Workflow abbildet. Sieht noch schick aus, werde dies sicher ebenfalls noch genauer anschauen.

Die BuildScripte müssen ja irgendwie geschrieben werden, wobei man per MSBuild auch einfach eine SLN Compilieren kann.

TC nimmt dir aber das drumherum ab, also Auswahl des SCM, ziehen der aktuellen Version, Anschmeissen der Compilation, erstellen von Abhängigkeiten der Projekte untereinander, Trigger für die Aktionen, Anzeige der Ausgaben, ausführen der Unittests usw.

All das musst du bei CC von Hand in XML machen.