Requirements an ein Continuous Integration Tool

[wetzesa]

Hallo...
ich soll bei uns in der Firma das CI-Tool Hudson etablieren...
Jetzt stellt sich natürlich die Frage was für Requirements das ganze haben soll...

Es gibt schon einige Requirements wie z.B. die Visualisierung von Checkstyle ,TestNG, usw...

Und nun die Frage an euch...
Was muss euch so ein System bieten bzw. was muss es eure Meinung nach für Informationen liefern...

Ich bin mit diesem Team noch nicht so viel in Kontakt gekommen und bin über jede Idee dankbar...

wetzesa

 

[kama]

Hallo,

Hallo...
ich soll bei uns in der Firma das CI-Tool Hudson etablieren...

Du sollst ...Hm...ich würde eher vermuten "evaluieren" ? Es gibt ja auch noch andere ...TeamCity, Bamboo, Anthill etc.

Jetzt stellt sich natürlich die Frage was für Requirements das ganze haben soll...

Es gibt schon einige Requirements wie z.B. die Visualisierung von Checkstyle ,TestNG, usw...

Daraus schliesse ich, dass Ihr eine Java Entwicklung habt ?


Ich würde doch erstmal irgendwo anders anfagen...Womit baut ihr derzeit ? Ant, Maven, Gradle, ?

Maven bietet hier sehr viel...per mvn site kann man auch so sachen wie CheckStyle, Unit-Test Reports etc. erstellen...Aber dabei geht es wahrscheinlich mehr um Trends (vergleich von vorherigen Builds mit aktuellen)....

Kennt bzw. Nutzt Ihr Sonar (Sonar) wäre hier als Aufsatz zu Empfehlen...der unabhängig von der CI Lösung ist...

Was muss euch so ein System bieten bzw. was muss es eure Meinung nach für Informationen liefern...

Zuerst einmal einen Build...als sprich einfach und schnell(hängt selbstverständlich von der Größe des Projektes ab)...

Verwendet Ihr Multi-Module Builds ? Was ist mit einem Repo Managemer (bei Einsatz von Maven?)

Wieviele Projekte habt ihr ? , Mehrere Branches die gebaut werden müssen ? Integrations Linien ?

Wollte Ihr tatsächlich Continious Integration machen ?

Wären mal so ein paar Punkte von meiner Seite...für den Anfang...

Gruß
Karl Heinz Marbaise

 

[wetzesa]

Vielen Dank für die schnelle Rückmeldung...

Du sollst ...Hm...ich würde eher vermuten "evaluieren" ? Es gibt ja auch noch andere ...TeamCity, Bamboo, Anthill etc.

evaluiert ist bereits...Die Entscheidung nach den Grundlegenden Requirements viel auf Hudson...

Daraus schliesse ich, dass Ihr eine Java Entwicklung habt ?

Ja unser Projekt ist in Java programmiert...Ein Modul ist jedoch in Peal programmiert...

Ich würde doch erstmal irgendwo anders anfagen...Womit baut ihr derzeit ? Ant, Maven, Gradle, ?

Maven bietet hier sehr viel...per mvn site kann man auch so sachen wie CheckStyle, Unit-Test Reports etc. erstellen...Aber dabei geht es wahrscheinlich mehr um Trends (vergleich von vorherigen Builds mit aktuellen)....

Wir nutze Maven2 zum bauen...
Über das maven-site Plugin machen wir die Tests schon...jedoch ist es wie du vermutet hast...
Wir wollen die Trends

Kennt bzw. Nutzt Ihr Sonar (Sonar) wäre hier als Aufsatz zu Empfehlen...der unabhängig von der CI Lösung ist...

Ich kenne Sonar...nutzen wir aber nicht...
Bei uns läuft das Bug-Tracking über Polarion und Bugzilla...

Zuerst einmal einen Build...als sprich einfach und schnell(hängt selbstverständlich von der Größe des Projektes ab)...

Verwendet Ihr Multi-Module Builds ? Was ist mit einem Repo Managemer (bei Einsatz von Maven?)

Wieviele Projekte habt ihr ? , Mehrere Branches die gebaut werden müssen ?

Ja wir haben Multi-Module Builds...

Als Repo-Management nutzen wir Subversion...

Projekte sind es derzeit 3...wobei das eine Projekte 8 Module hat...

Mehrere Branches müssen nicht gebaut werden...

Integrations Linien ?

Wollte Ihr tatsächlich Continious Integration machen ?

Was meinst du mit Integrations Linien...??? Ich verstehe das nicht ganz...

Continious Integration wollen wir nicht zu 100%...das ganze ging mit einem Nigthlybuild los...
Zwischenzeitlich haben wir festgestellt, dass wir alle 15 Minuten nach Commits schauen und dann das Projekt durchbauen...

Gruß...

 

[kama]

Hallo,

evaluiert ist bereits...Die Entscheidung nach den Grundlegenden Requirements viel auf Hudson...

Dachte ich mir doch....

Ich kenne Sonar...nutzen wir aber nicht...

Schade liefert sehr gute Zahlen und vor allem auch Trends noch besser als Plugins in Hudson...

Bei uns läuft das Bug-Tracking über Polarion und Bugzilla...

Polarion ist kein Bug -Tracking sondern Application Life Cycle Management...also deutlich mehr als Bugzilla...

Ja wir haben Multi-Module Builds...

Hudson ist die Wahl....incremental builds etc. alles in Hudson enthalten mit Maven...

Als Repo-Management nutzen wir Subversion...

Häh....Repository Manager für Maven ? Subversion ? Ich dachte da mehr an Nexus, Artifactory oder Archiva...

Projekte sind es derzeit 3...wobei das eine Projekte 8 Module hat...

Übersichtlich...

Mehrere Branches müssen nicht gebaut werden...

Kein Release Branch ? Hm..Branching Strategie nochmal überdenken...

Was meinst du mit Integrations Linien...??? Ich verstehe das nicht ganz...

Schau dir das mal an:http://soebes.de/files/SubConf2008BranchingStrategies.pdf

Wird der Release Cycle von Maven genutzt ?

Continious Integration wollen wir nicht zu 100%...das ganze ging mit einem Nigthlybuild los...
Zwischenzeitlich haben wir festgestellt, dass wir alle 15 Minuten nach Commits schauen und dann das Projekt durchbauen...

Ja das ist eine Aufgabe für Hudson...

Gruß
Karl Heinz Marbaise

 

[wetzesa]

Hallo...

Polarion ist kein Bug -Tracking sondern Application Life Cycle Management...also deutlich mehr als Bugzilla...

Das weiß ich auch......Wir haben eine Option eingefügt wo Tester zu ihren Testcases Komentare einfügen können...Jedes Testcase hängt ja an einem WorkItem und kann so vom Entwickler nochmals angeschaut werden...

Und wir nutzen es nur zusätzlich für das Bug-Tracking...wäre ja schade ums Geld wenn nicht alles aus einem Tool genutzt wird was es kann...

Häh....Repository Manager für Maven ? Subversion ? Ich dachte da mehr an Nexus, Artifactory oder Archiva...

Oh da hab ich dich falsch verstanden...
Wir nutzen als Maven-Repo Archiva...

Kein Release Branch ? Hm..Branching Strategie nochmal überdenken...

Branches nutzen wir schon...sie müssen aber zum Glück nicht so oft genutzt werden und können dann über den Trunk mit abgedeckt werden, weil ja eh alles in was in der Branch gemacht wird in den Trunk übernommen werden muss...

Schau dir das mal an:http://soebes.de/files/SubConf2008BranchingStrategies.pdf

Wird der Release Cycle von Maven genutzt ?

Danke für die PPT...
Ich schau sie mir gleich mal an...

Also meines Wissens nach wird der Release Cycle von Maven bei uns nicht genutzt...
Aber vielleicht sagst du noch ein paar Worte dazu, weil mir auch nicht so ganz klar ist was du damit meinst...

Gruß

 

[kama]

Hallo,

Das weiß ich auch......Wir haben eine Option eingefügt wo Tester zu ihren Testcases Komentare einfügen können...Jedes Testcase hängt ja an einem WorkItem und kann so vom Entwickler nochmals angeschaut werden...

Und wir nutzen es nur zusätzlich für das Bug-Tracking...wäre ja schade ums Geld wenn nicht alles aus einem Tool genutzt wird was es kann...

Ich hatte es vermutet ;-) Ich war nur verwundert wg. Bugzilla...

Oh da hab ich dich falsch verstanden...
Wir nutzen als Maven-Repo Archiva...

Kein Problem...

Branches nutzen wir schon...sie müssen aber zum Glück nicht so oft genutzt werden und können dann über den Trunk mit abgedeckt werden, weil ja eh alles in was in der Branch gemacht wird in den Trunk übernommen werden muss...

Wenig Branches ? Wo liegt das Problem ? Branches sind ein sehr effektives Hilfsmittel...

Also meines Wissens nach wird der Release Cycle von Maven bei uns nicht genutzt...
Aber vielleicht sagst du noch ein paar Worte dazu, weil mir auch nicht so ganz klar ist was du damit meinst...

Wie macht Ihr denn derzeit eine Release ?

Maven macht alles was man braucht, macht den Tag im SVN, Ändert die Versionsnummern, macht dann ein Deploy der Artefakte in das Repository (Archiva) ...

Gruß
Karl Heinz Marbaise

 

[wetzesa]

Wenig Branches ? Wo liegt das Problem ? Branches sind ein sehr effektives Hilfsmittel...

Naja es werden nur wirklich wichtige Dinge in der Brunch gemacht, da wir 2 Releases pro Jahr haben und dort die kleineren Bugs bzw. gewünschten Änderungen...

Wie macht Ihr denn derzeit eine Release ?

Über ein Ant-Script...dort wird über propertys die ganzen Dinge wie Releasenummer, Name, usw. gesetzt, dann gebaut und in ein Directory geschoben...
Dann wird das Directory noch tar.gz und fertig...

 

[kama]

Hallo,

Naja es werden nur wirklich wichtige Dinge in der Brunch gemacht, da wir 2 Releases pro Jahr haben und dort die kleineren Bugs bzw. gewünschten Änderungen...

Ok...dann...

Über ein Ant-Script...dort wird über propertys die ganzen Dinge wie Releasenummer, Name, usw. gesetzt, dann gebaut und in ein Directory geschoben...
Dann wird das Directory noch tar.gz und fertig...

Hm..Versionsnummer ist doch in der Maven POM drin ? und ein tar.gz bauen ist auch kein Problem (Maven-Assembly-Plugin) ...

EDIT: Release Builds mit Unterstützung des mvn release Parts kann man auch in Hudson machen...
Gruß
Karl Heinz Marbaise

 

[wetzesa]

Das ist schon richtig...nur werde ich da nicht viel Zuspruch dafür bekommen...

Nichts desto trotz hab ich meine Requirementsliste bisher leider noch nicht erweitert...

Fallen dir / euch noch Dinge ein die Hudson einem Entwickler, dem QM oder der Geschäftsführung aussagen können bzw. muss...???

 

[Wildcard]

Ich finde das irgendwie lustig. Du schreibst ihr habt verschiedene Tools anhand eurer Requirements evaluiert und seid zu dem Schluss gekommen Hudson zu verwenden.
Und jetzt fragst du welche Requirements ihr an Hudson habt? Solltet ihr die Requirements nicht kennen bevor ihr ein Tool auswählt? :autsch:

 

[wetzesa]

Ich finde das irgendwie lustig. Du schreibst ihr habt verschiedene Tools anhand eurer Requirements evaluiert und seid zu dem Schluss gekommen Hudson zu verwenden.
Und jetzt fragst du welche Requirements ihr an Hudson habt? Solltet ihr die Requirements nicht kennen bevor ihr ein Tool auswählt? :autsch:

Das ist schon richtig so...
Es gibt Tool die wollen wir auch mit Hudson weiter nutzen...

Es gibt aber auch noch genügend Tools die im www noch vorhanden sind, aber bei uns noch nicht im Einsatz...

Deshalb hab ich ja die Grundfragen gestellt, was Ihr, also die Community, aus der sich eines Entwicklers, Architekten, dem QM und dem Softwarebetrieb noch als sinnvoll bzw. wichtig anseht...

 

[Wildcard]

Benchmarks sind zB noch sehr nützlich. Für Hudson gibt es dafür ein schönes Japex Plugin. Code Coverage gehört natürlich auch dazu, da hast du zZ 3 Plugin Alternativen für Hudson, je nachdem welches Coverage Tool ihr verwendet.

 

[wetzesa]

Moin,

Benchmarks sind zB noch sehr nützlich. Für Hudson gibt es dafür ein schönes Japex Plugin.

Du meinst Benchmarking von den einzelnen Projekten oder bin ich da auf dem Holzweg...???
Japex hab ich mir grade angeschaut...vom Konzept sieht es nicht schlecht aus...das einzige was mich etwas stört ist, dass die letzte Release vor fast einem Jahr war

Code Coverage gehört natürlich auch dazu, da hast du zZ 3 Plugin Alternativen für Hudson, je nachdem welches Coverage Tool ihr verwendet.

Code Coverage machen wir momentan noch nicht...ist aber auch auf meiner Requirementsliste
Welches Tool verwendest du und warum...???

Gruß

 

[Gast2]

Ich hab ganz gute Erfahrung mit Open Source Code Coverage Tools in Java - Cobertura gemacht, gibt es auch ein Hudon Plugin fuer.

 

[wetzesa]

Ich hab ganz gute Erfahrung mit Open Source Code Coverage Tools in Java - Cobertura gemacht, gibt es auch ein Hudon Plugin fuer.

Danke für die Empfehlung...

 

[mvitz]

Oder wenn es eh maven2 Projekte sind direkt Sonar nutzen. Sonar

 

[wetzesa]

Oder wenn es eh maven2 Projekte sind direkt Sonar nutzen. Sonar

Was würdest du mit Sonar alles machen außer das Bugtracking...???

 

[Wildcard]

Du meinst Benchmarking von den einzelnen Projekten oder bin ich da auf dem Holzweg...???
Japex hab ich mir grade angeschaut...vom Konzept sieht es nicht schlecht aus...das einzige was mich etwas stört ist, dass die letzte Release vor fast einem Jahr war

Von einzelnen Projekten? Zum Benchmarken dort wo ein Benchmark sinn macht. Ich weiß ja nicht was eure Applikationen so tun und wo Performance dabei eine Rolle spielt. Dort wo die Performance eine Rolle spielt macht ein Benchmark Sinn. Letztes Release vor fast einem Jahr? Macht doch nichts, ist keine Runtime Library ist eine Metrik. Solange das Werkzeug seine Arbeit verrichtet ist egal wie alt es ist.

Code Coverage machen wir momentan noch nicht...ist aber auch auf meiner Requirementsliste
Welches Tool verwendest du und warum...???

Emma, weil Emma wunderbar integriert in Eclipse, Hudson und Buckminster ist.

 

[Jay_030]

Emma, weil Emma wunderbar integriert in Eclipse, Hudson und Buckminster ist.

Btw: Gibt es Features durch die Emma einen Mehrwert gegenüber Corbetura darstellt?

 

[Wildcard]

Btw: Gibt es Features durch die Emma einen Mehrwert gegenüber Corbetura darstellt?

Nicht das ich wüsste, Code Coverage ist Code Coverage. Nimm das was am besten in deine Toolchain passt, bei mir ist es aus genannten Gründen Emma. Das wichtigste ist IMO das es sich sauber in die IDE integriert, denn dort schreibt man schließlich die Unit tests...

 

[madboy]

Was würdest du mit Sonar alles machen außer das Bugtracking...???

Sonar macht kein Bugtracking (außer ich habe da was ganz entscheidendes übersehen) sondern stellt diverse Codemetriken bereit.
[OUOTE=sonarsource.org]Sonar is an open platform to manage code quality[/QUOTE]

 

[wetzesa]

Von einzelnen Projekten? Zum Benchmarken dort wo ein Benchmark sinn macht. Ich weiß ja nicht was eure Applikationen so tun und wo Performance dabei eine Rolle spielt. Dort wo die Performance eine Rolle spielt macht ein Benchmark Sinn.

Danke für die Info...ich würde dann in dann JMeter bei uns als Benchmarkingtool sehen...

Emma, weil Emma wunderbar integriert in Eclipse, Hudson und Buckminster ist.

Ich schau mir Emma auf jeden Fall auch noch an...!!!

Sonar macht kein Bugtracking (außer ich habe da was ganz entscheidendes übersehen) sondern stellt diverse Codemetriken bereit.
Sonar is an open platform to manage code quality

Oh da hab ich mir wohl eine falsche Info ausm Netz gezogen...
Was für Codemetriken nutzt du...???