Nachdem mir ein Bekannter (Hallo Alex!) mitgeteilt hat, dass mein Blog schon auf Platz 5 der Suchergebnisse von "Scrum Continuous Integration" steht, möchte die dürftigen Infos die man bisher finden konnte noch etwas erweitern. Scrum hat als Grundprinzip, dass man ständig lieferfähig ist. In der Regel liefert man die Ergebnisse des letzten Sprints aus. Ggf. muss oder möchte man noch einen gesonderten Test-Sprint machen in dem superkomplizierte nicht-automatisierbare Integrationstests durchgeführt werden. Letzteres ist insbesondere bei der SW-Entwicklung für Geräte interessant. Bei mir/uns haben sich Jenkins und buildbot als CI Server gut gemacht. Jenkins gefällt mir besser, da er leichter zu erweitern ist und es schon ganz viele Plugins gibt (für git, Sonar, ClearCase uvm.). Nach jedem git push läuft Jenkins los und macht einen clean build. Den Installer kann man sich (wenn man weitere Tests durchführen möchte) vom Server holen und loslegen. Nach dem Build werden die Metriken (Unittest, Code Coverage, PDM, FindBugs) in Sonar eingepflegt. Dort erkennt man dann auch Schwachpunkte und hat vor allem einen Verlauf über die Zeit. Scrum benötigt IMHO CI, da sonst weder schnell noch effizient ein Liefergegenstand vorliegt und zeitnahes Feedback fehlt.

Nachdem mir ein Bekannter (Hallo Alex!) mitgeteilt hat, dass mein Blog schon auf Platz 5 der Suchergebnisse von “Scrum Continuous Integration” steht, möchte die dürftigen Infos die man bisher finden konnte noch etwas erweitern.

Scrum hat als Grundprinzip, dass man ständig lieferfähig ist. In der Regel liefert man die Ergebnisse des letzten Sprints aus. Ggf. muss oder möchte man noch einen gesonderten Test-Sprint machen in dem superkomplizierte nicht-automatisierbare Integrationstests durchgeführt werden. Letzteres ist insbesondere bei der SW-Entwicklung für Geräte interessant.
Bei mir/uns haben sich Jenkins und buildbot als CI Server gut gemacht. Jenkins gefällt mir besser, da er leichter zu erweitern ist und es schon ganz viele Plugins gibt (für git, Sonar, ClearCase uvm.). Nach jedem git push läuft Jenkins los und macht einen clean build. Den Installer kann man sich (wenn man weitere Tests durchführen möchte) vom Server holen und loslegen. Nach dem Build werden die Metriken (Unittest, Code Coverage, PDM, FindBugs) in Sonar eingepflegt. Dort erkennt man dann auch Schwachpunkte und hat vor allem einen Verlauf über die Zeit.

Scrum benötigt IMHO CI, da sonst weder schnell noch effizient ein Liefergegenstand vorliegt und zeitnahes Feedback fehlt.