Jens Bräuer (number4) hat beim letzten DevOps Berlin Meeting einen interessanten Vortrag zu CD in der Amazon Clound gehalten, so Schlomo Schapio in seinem Blog. Die Folien findet man natürlich auch in der Amazon Cloud 
.
Schade, dass ich nicht kommen konnte.
Jay Banks hat mein Confed Bridge Bild in seinem Artikel zu den größten kanadischen Bauwerken übernommen…
Das Buch “Clean Code” kennen vielleicht einige Programmierer schon. Seit längerem gibt es auch die passende Initiative dazu.
Die Clean Code Developer setzen sich mit dem Schreiben von gutem Code auseinander. Reflektieren ihr tägliches Handeln und stellen Liebgewordenes gern mal infrage. Persönlich habe ich Martins Buch schon vor einigen Jahren gelesen und bin 2009 auf die Initiative gestoßen und das Infragestellen ist mir auch nicht fremd. Hinzu kommt, dass jeder Scrum Master auch ein Wanderprediger ist (Hallo Falk!) und als solcher natürlich sein Evangelium verbreiten möchte. Also? In unserer Firma moderiere ich derzeit einen sechsteiligen Workshop zu diesem Thema. Die ersten Folien findet man in der Dropbox
Clean Code Developer – Roter Grad
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.
Das wir Wohneigentum erwerben wollen und sich dies als schier endlose Kette verschiedenster Ereignisse darstellt, habe ich mich dazu entschieden, dies als Blog zu dokumentieren.