# Requirements an ein Continuous Integration Tool



## wetzesa (22. Sep 2010)

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 (22. Sep 2010)

Hallo,



wetzesa hat gesagt.:


> 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.



wetzesa hat gesagt.:


> 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...



wetzesa hat gesagt.:


> 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 (22. Sep 2010)

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




kama hat gesagt.:


> 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...



kama hat gesagt.:


> Daraus schliesse ich, dass Ihr eine Java Entwicklung habt ?



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



kama hat gesagt.:


> 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 



kama hat gesagt.:


> 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...



kama hat gesagt.:


> 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...




kama hat gesagt.:


> 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 (22. Sep 2010)

Hallo,


wetzesa hat gesagt.:


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


Dachte ich mir doch....



wetzesa hat gesagt.:


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


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



wetzesa hat gesagt.:


> 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...



wetzesa hat gesagt.:


> Ja wir haben Multi-Module Builds...


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



wetzesa hat gesagt.:


> Als Repo-Management nutzen wir Subversion...


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




wetzesa hat gesagt.:


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


Übersichtlich...



wetzesa hat gesagt.:


> Mehrere Branches müssen nicht gebaut werden...


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



wetzesa hat gesagt.:


> 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 ?



wetzesa hat gesagt.:


> 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 (22. Sep 2010)

Hallo...



kama hat gesagt.:


> 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...



kama hat gesagt.:


> 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...



kama hat gesagt.:


> 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...  



kama hat gesagt.:


> 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 (22. Sep 2010)

Hallo,



wetzesa hat gesagt.:


> 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...



wetzesa hat gesagt.:


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


Kein Problem...



wetzesa hat gesagt.:


> 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...



wetzesa hat gesagt.:


> 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 (22. Sep 2010)

kama hat gesagt.:


> 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...



kama hat gesagt.:


> 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 (22. Sep 2010)

Hallo,



wetzesa hat gesagt.:


> 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...




wetzesa hat gesagt.:


> Ü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 (22. Sep 2010)

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 (22. Sep 2010)

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 (23. Sep 2010)

Wildcard hat gesagt.:


> 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 (23. Sep 2010)

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 (24. Sep 2010)

Moin,



Wildcard hat gesagt.:


> 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 



Wildcard hat gesagt.:


> 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 (24. Sep 2010)

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


----------



## wetzesa (24. Sep 2010)

fassy hat gesagt.:


> 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 (24. Sep 2010)

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


----------



## wetzesa (24. Sep 2010)

mvitz hat gesagt.:


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



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


----------



## Wildcard (24. Sep 2010)

wetzesa hat gesagt.:


> 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 (25. Sep 2010)

Wildcard hat gesagt.:


> 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 (25. Sep 2010)

> 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 (25. Sep 2010)

wetzesa hat gesagt.:


> 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 (28. Sep 2010)

Wildcard hat gesagt.:


> 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... 



Wildcard hat gesagt.:


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



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



madboy hat gesagt.:


> 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...???


----------

