Problemstellung • Entwickler benötigen schnelles Feedback über die Qualität und die Auswirkung ihrer Anpassungen • Entwickler benötigen schnelles Feedback über die Auswirkung ihrer Anpassungen auf die Kodequalität • Entwickler benötigen schnelles Feedback hinsichtlich der Auswirkung auf abhängige Module • Entwickler möchten kontinuierlich arbeiten und nicht durch Codefreezes gehindert werden • Entwickler möchten schnell zwischen verschiedenen Anpassungen wechseln können ohne diese einschecken zu müssen • Entwickler möchten unterschiedliche Anpassungen parallel bearbeiten können und diese aber getrennt commiten • Der Entwickler möchte jedes Kodeartefakt über einen Blackboxtest (JUnit) absichern • Der Systemtest möchte gezielt auszuliefernde Features abschließend und vollständig testen • Der Systemtest möchte jedes fertiggestellte Feature abschließend und vollständig testen • Der PO möchte vor Liveschaltung entscheiden welche Features ausgeliefert werden sollen und welche nicht
Konsequenzen •Es werden kurze Buildzeiten benötigt (max. 10 Minuten) •Continious Integration muss bereits auf dem lokalen Rechner erfolgen •Kodequalität und Testfälle müssen ebenfalls auf dem lokalen Rechner laufend geprüft werden •Mit dem lokalen Stand müssen auch Folgebuilds ausgelöst werden um Auswirkungen auf abhängige Module zu bemerken •Jedes Speichern müsste einen vollständigen lokalen Build mit Folgebuilds und der Erzeugung diverser Statistiken auslösen
Umsetzung ständiger, schneller Build • Umsetzung schwierig, da ein vollständiger Build nach jedem Speichern unrealistisch • Zu bestimmten Zeitpunkten könnte der lokale Stand vollständig in eine Cloud Umgebung transferiert werden um dort entsprechend schnell den geforderten vollständigen Build ausführen zu können • Synergieeffekte sind zu erwarten, wenn der lokale Stand auch nicht wirklich lokal abgelegt ist sondern ebenfalls in der Cloud liegt • Bei Letzterem würden lokal Terminals zur Entwicklung genügen (vgl. Arbeit mit Mainframe oder DECstation) • Die "bestimmten" Zeitpunkte festzulegen ist hier die Schwierigkeit. Denkbare Lösungen: • Der Entwickler löst manuell einen solchen Build aus • Ein vollständiger Build wird zeitgesteuert abhängig davon ob Änderungen vorliegen ausgelöst • Beides
Umsetzung flexibler Features • Wenn der PO kurzfristig entscheiden möchte welche Features integriert werden und welche nicht, so muss jedes Feature ein lieferbares Artefakt darstellen (z.B. Bundle) • Features sollten demnach von einander unabhängig und individuell deploybar sein • Sollten zwischen Features dennoch Abhängigkeiten bestehen so müssen Features in mehreren Versionen parallel deployed werden können (z.B. OSGI Bundle) • Die Erstellung eines Features muss in einem eigenen Repository oder einem eigenen Branch erfolgen • Der Merge des Feature Branches in einen Hauptbranch ergibt keinen Sinn, da damit die Buildzeit vergrössert wird und der Entwickler länger auf Feedback warten muss.
Umsetzung flexibler Entwicklungskontext •Damit der Entwickler Fehler 1 und Fehler 2 im gleichen Kode beheben aber getrennt nach Freigabe einchecken kann muss er in verschiedenen Kontexten arbeiten können •Eine virtuelle Unterscheidung der Kontexte (z.B. durch Mylyn) gnügt nicht, da letztlich nur Teile des geänderten Kodes eingecheckt werden sollen und dies einen unbrauchbaren Stand ergibt •Die einzige Möglichkeit wäre der Zugriff auf eine zweite Entwicklungsumgbung •Realisierbar durch Virtualisierung bzw. Einsatz einer Cloud
huluvu424242
panda728
minodriven
siroemk
akase244
uyuki234
seike460
falcon8823
___akari11
hollycummins
utakaha
.jpg){kind=avatar}
yumnumm
smashingmag
ryanjones
tammyeverts
cromwellryan
kneath
aleyda
baasie
destraynor
ammeep
lfama
rkendrick25
productmarketing
