Wie lange hat es gedauert, bis es Kollegen auffällt? ! War der Kollege zum nachliefern schonmal weg? ! Jemals Seiteneffekte produziert? ! Wie lange hat es gedauert, bis sie auaraten? ! Gab es schon einmal Regressions (gefixte Bugs die wieder auaraten)?
! Fehleranfällige manuelle SchriAe eliminieren ! Beschleunigung ! Release Prozess kann Zeitaufwändig sein ! Bei Smarthouse früher 4h pro Produkt ! Heute: ca. 45 Minuten pro Produkt
Bauen, dann schauen“ ! Arbeit, Arbeit J (Build) ! Schauen: Tests ! Schauen lassen: Automa&sierte Tests ! Vor dem commit (bzw. push) ! Update des letzten integrierten Standes ! gleiche SchriAe wie oben
„Das tut bei mir aber.“ ist keine Ausrede mehr ! Jederzeit Release-‐fähiger Zustand im Repo ! Durch remote-‐Builds & Tests können unterschiedliche Umgebungen einfach ergänzt werden
Trunk“ ! Ich: „Wehe! Besser: Jeder merged täglich die aktualisierte Source in seinen branch.“ ! JEDER Commit ins zentrale Repository sollte (automa&sch) geprüa werden ! Moderne CI-‐Systeme können auch Branches automa&siert getestet werden
helfen, aber: ! Der Prozess muss vorher schon funk&onieren ! Der Build-‐Prozess muss schnell sein ! max. 10 Minuten sollte das Ziel sein ! Meistens sind Tests der Flaschenhals ! Staged Builds / Build Pipeline kann helfen
Soweit möglich ! Self-‐Containing ! Virtualisierung kann helfen ! Ergebnisse der Builds bereitstellen ! Jeder soll möglichst einfach an das Ergebnis kommen ! z.B. Installer generieren, Artefakte bereitstellen
publik machen ! Großer Bildschirm an der Wand mit Statusinfos ! z.B. Lava-‐Lampen (neben Zustand auch Indika&on der Dauer) ! Gerne auch Chat-‐Bot, E-‐Mails etc. ! Mit Tooling kann auch ein Überblick über die Änderungen gewährt werden ! Changesets im Commit etc.
! CruiseControl / CruiseControl.NET ! Cruise ! Jenkins / Hudson ! Team Founda&on Server ! Con&nua CI (Finalbuilder Server als CI-‐Lösung) ! und (wirklich) viele mehr…