wir möchten für ein neues Projekt mal ein CI Framework testen da dies bislang alles mit eigenen Lösungen erledigt wurde.
Ich finde CruiseControl und Jenkins ganz interessant. CruiseControl scheint jedoch schon was länger nicht mehr aktualisiert worden zu sein.
Randinfos:
Es wird mit svn verwendet werden müssen
Es muss generisch verschiedene Sprachen / Skripte etc. verstehen. Primär muss C/C++ Javascript, Html5 Css3 unterstützbar sein.
Vielleicht hat jemand mit den Systemen Erfahrung bzw. kennt eine bessere Alternative.
wir hatten in meiner alten Firma eine zeit lang CruiseControl - ich fand das schrecklich, von der Bedinung, von der UI, von allem. Das ist in etwa 4 Jahre her, keine Ahnung was sich seitdem geandert hat.
Ich habe damals den Build auf Hudson umgestellt (vor der Jenkins/Hudson Trennung) und fand das bei Weltem besser.
Seitdem kenn ich nur noch Firmen die Jenkins nutzen.
Aber ich kenne mich nicht mit der Unterstuetzung von “C/C++ Javascript, Html5 Css3” aus, alle Builds waren immer java related
Hm das untertreicht meine Befürchtung bezüglich Cruise Control. Die Letzte Version ist von 2010. Jenkins scheint verbreiteter als Hudson. Werde ich wohl mal antesten.
Ich finde TeamCity recht gelungen, vor allem wenn mit IDEA entwickelt wird. Für Eclipse gibt es auch ein Plugin, für NetBeans leider nicht.
Bis zu 20 Buildsetups können mit der kostenlosen Lizenz konfiguriert werden, danach ist eine kostenpflichtige Lizenz fällig.
Wir setzen bei uns Jenkins ein und kann es nur empfehlen. Jenkins an sich ist nur das Gerüst, die ganzen Features machen die Plugins aus, von denen es unzählige gibt: https://wiki.jenkins-ci.org/display/JENKINS/Plugins
SVN Unterstützung ist standardmäßig mit dabei. Du kannst Jenkins auch beliebig mit neuen eigenen Skripten erweitern. Die Sprache ist dabei (fast) egal. Bei Jenkins kannst du wenig falsch machen.
Kommt nicht in Frage da kostenpflichtig und die gratis alternativen besser aussehen.
[QUOTE=cmrudolph;65740]Ich finde TeamCity recht gelungen, vor allem wenn mit IDEA entwickelt wird. Für Eclipse gibt es auch ein Plugin, für NetBeans leider nicht.
Bis zu 20 Buildsetups können mit der kostenlosen Lizenz konfiguriert werden, danach ist eine kostenpflichtige Lizenz fällig.[/QUOTE]
It doch extrem Java lastig. Die ganzen IDEs bringen gar nichts, da man man mit Javascript (Hauptaugenmerk) anders arbeitet.
[QUOTE=Curiosity;65741]Wir setzen bei uns Jenkins ein und kann es nur empfehlen. Jenkins an sich ist nur das Gerüst, die ganzen Features machen die Plugins aus, von denen es unzählige gibt: Jenkins Plugins
SVN Unterstützung ist standardmäßig mit dabei. Du kannst Jenkins auch beliebig mit neuen eigenen Skripten erweitern. Die Sprache ist dabei (fast) egal. Bei Jenkins kannst du wenig falsch machen.[/QUOTE]
Dahin tendiere ich auch nachdem ich etwas tiefer reingeschaut habe.
Allen Vielen Dank für den Input! Wir testen nun mal in Ruhe Jenkins!
Ich habe Jenkins inzwischen am laufen und bin recht zufrieden. Habe für die Email Notifications noch email-ext installiert und das Backup Plugin. Plugin System funktioniert soweit super. Gab es bei euch schon mal einen Totalverlust des Systems durch Updates? Wäre einfach gut zu wissen.
Einziger Haken beim Einarbeiten war, dass ich mich wunderte, dass das System die User nicht aus dem svn gezogen hat. Später stellte sich raus, dass nur User welche nach Inbetriebnahme von Jenkins comitten angelegt werden! (Für alle die sich da auch drüber wundern sollten). Macht im Nachgang auch Sinn, denn es könnten alte Karteileichen im svn liegen.
Wir werden Jenkins nun peu a peu ausbauen. Sieht aber wirklich gut aus
Totalverlust nicht, aber normalesweise updated man keine Plugins solaneg alles laeuft.
Was mr aufgefallen ist, ist dass die Plugins immer noch nicht so wirklich untereinander integriert sind (BulkBuilder zB. verursacht Fehler mit EnvInject), ist halt alles immer ncoh ein Riesenverhau (wer Lust auf richtig schlechten Code hat sollte sich mal die Hudson/Jenkins Soucen ansehen).
Man sollte sich einen „Long-Term Support release“ von Jenkins holen, damit sollte es weniger Probleme mit Plugins geben.
Auf der positiven Seite gibt es wirklich viele gute Plugins, und nach etwas einstellen funzt dann auch alles, selbst wenn man ab & zu auf Krude Notloesungen umsteigen muss.
Lasse hier die Builds (hauptsaechlich Maven) auf einer Ramdisk laufen um Disk IO zu reduzieren und die performance zu verbessern, SSDs waeren auch gut.
Workspace Root Directory=/mnt/ramdrive/workspace/${ITEM_FULLNAME}
Build Record Root Directory=${JENKINS_HOME}/builds/${ITEM_FULLNAME}
Dann einfach alles unter /var/lib/jenkins ins Backup.
Man sollte die Anzahl der gespeicherten Builds reduzieren (Max # of builds to keep), sehr viele davon machen das Starten und Stoppen von jenkins sehr langsam. Die Artifakte werden in Nexus gespecihert (ist ja alles Maven), dadurch muss man nicht wirklich viele alte Builds speichern.
Ach ja, das „Jenkins Job Configuration History Plugin“ finde ich sehr nuetzlich um zu sehen wann welche Aenderungen an einem Build Job gemacht wurden, nuetzlich wenn man viele Projekte hat und mehrere Leute die Konfiguration der Jobs anpassen koennen.
@maki : ist eigentlich nun Hudson bzgl maven builds besser als Jenkins ? meines wissens haben doch van Zyl und Konsorten dies nach der Abspaltung von Jenkins uebernommen
Ich weiss nicht ob Hudson besser ist, nehme seit Ende letzten Jahres nur Jenkins (davor Bamboo - IME schlecht fuer Maven Builds), und die Jahre davor Hudson.
Maven Builds funktionieren ganz gut mit Jenkins, Aerger machen hoechstens mal die Plugins, zB. das „Config File Provider Plugin“ spielt nicht wirklich mit dem „Jenkins M2 release Plugin“ zusammen, dadurch musste ich wieder eine globale settings.xml verwenden.
Probleme im eigentlichen Sinne gibt es keine bei Maven Builds.
