Warum will ich CI? • Schon einmal vergessen, eine neue Datei einzuchecken? – Wie lange hat es gedauert bis das bei Kollegen auffällt? – Kollege noch da zum nachliefern? • Schonmal Seiteneffekte produziert? – Wie lange hat es gedauert bis die auftraten? – Gab es hier schon einmal Regressions?
Ablauf • Checkout des letzten integrierten Standes • Arbeit, Arbeit J • Erst Bauen, dann schauen (lassen) (autom. Tests) • Vor dem commit (bzw. push) – update des letzten integrierten Standes, test
Der Weg zu CI • „Verwaltete“ Quellcodeverwaltung – Alles benötigte im Repository • Autom. Buildprozess – Siehe meine EKON 16 Slides zu MSBuild • Selbsttestender Code – xUnit
Der Weg zu CI • M. Fowler: „Jeder commited täglich in den Trunk“ • Ich: „Wehe!“ • JEDER Commit ins zentrale Repository sollte (automatisch) integriert werden. • Moderne CI-Systeme können auch Branches automatisiert integrieren
Der Weg zu CI • Man muss CI leben – Tooling kann helfen, aber es muss vorher schon funktionieren • Der Buildprozess muss schnell sein – Maximal 10 Min. sollte das Ziel sein – Meistens sind Tests der Flaschenhals – Staged Builds / Build Pipeline kann helfen
Der Weg zu CI • Tests: In Kopie der Live-Umgebung – 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
Der Weg zu CI • Übergang zu Cont. Delivery fliessend • Build-Status publik machen – z.B. Lava-Lampen (nicht zur Zustand, sondern auch Indikation der Dauer) – Gerne auch Chat-Bot, E-Mails etc. • Mit Tooling kann auch ein Überblick über die Änderungen gewährt werden
phoenixhawk
kamilahsantos
morikann
piyoppi
doggy
morux2
texmeijin
huffon
okuzawats
nano72mkn
fbei_ot
chimame
seike460
palkan
dougneiner
bkeepers
swwweet
jmmastey
lynnandtonic
sstephenson
lauravandoore
carmenintech
matthewcrist
phodgson