135 Continious Integration (CI)

Continious Integration (CI)

Heute ist das Thema Continious Integration, kurz CI. Es ist damit
der erste Teil einer CI/CD Kette, wie wir sie häufig bei
Software-Team vorfinden. Vor allem im Agilem Umfeld. Doch die
Prinzipien, die dahinter stecken lassen sich auch auf andere Jobs
anwenden. Vielmehr noch: Sie wären auch in anderen Berufen und
Umfeldern sehr wertvoll.


Wir haben vor einer Weile mal eine Folge aufgenommen, wo es um
Flow geht. Dieses Thema schließt daran nahtlos an.


Diese Folge auf Youtube: https://youtu.be/Tiy9pbi3W7o
Continious Integration

Eventuell in den ersten Zügen als Permanente Integration von Kent
Beck im XP Framework erfunden. Da das erste XP Projekt 1995 mit
C3 starte könnte das irgendwo zwischen 1996 und 2001 geschehen
sein. Quelle hierzu:
https://de.wikipedia.org/wiki/Extreme_Programming


Kent Beck ist heute eine bekannte Größe aus der Agilen Szene und
auch einer der Initiatoren und Unterzeichner des Manifestes für
Agile Softwareentwicklung.


Continious Integration bedeutet in der Übersetzung das
kontinuierliche integrieren von Arbeitsergebnissen. Das heißt ein
Team produziert lieferbare Arbeitsergebnisse, welche
kontinuierlich integriert werden. Also in ein größeres Ganzes
zusammengefasst werden. Dies ist steht im Kontrast zu klassischem
Projektmanagement, wo erst nach langer Zeit in einem Big Bang
integriert wird. Hier sei der Berliner Flughafen BER als
Beispiel, genannt, welcher erst am Ende integriert wurde und wo
die Teile nicht zusammenpassten. Aus der Softwareentwicklung
kennt man es, wenn alle Softwaremodule zusammen integriert
werden. Hier nun also permanent.
Beispiele

Ähnlich verhält es sich beim Hausbau. Gerade bei Fertighäusern
wird häufig erst am Ende integriert. Eine andere Vorgehensweise
wäre direkt vor Ort ständig jeden Tag jedes Stück zu integrieren.


Witzig wird dies auch bei Brückenbauprojekten zwischen Ländern.
Länder nehmen unterschiedliche Meereshöhen durch unterschiedliche
Referenzmeere an. So kann es bei Brückenbauprojekten zwischen
zwei Ländern zu enormen Abweichungen kommen. Quelle: Meereshöhe
ist nicht gleich Meereshöhe – SWI swissinfo.ch | Höhe über dem
Meeresspiegel – Wikipedia


Bei einer kontinuierlichen Integration merken wir sehr schnell ob
sich Dinge eventuell verschieben.


Ein weiteres Beispiel ist der Elterngeldantrag in Niedersachsen.
https://www.elterngeld-digital.de/ams/Elterngeld Hier ist sehr
auffällig, dass die unterschiedlichen Seiten, scheinbar einzeln
beauftragt und nicht miteinander integriert wurden. Es
funktioniert und gleichzeitig muss man viele Informationen
redundant pflegen und das ist mitunter nervig. Was wir meinen?
Beispielsweise kommt die Frage ob beide Elternteile zusammen in
einem Haushalt leben und dann die Frage ob der Vater mit dem Kind
in einem Haushalt lebt und dann kommt die Frage ob die Frau mit
dem Kind in einem Haushalt lebt, obwohl sich dies aus dem
vorherigen ergibt. Dann werden die Adressdaten von allein einzeln
abgefragt, obwohl alle im selben Haushalt leben. Problematisch
wird genau dies dann, wenn auf den unterschiedlichen Seiten
dadurch unterschiedliche Angaben gemacht werden.


All das erzeugt Aufwand und technische Schulden.
Das wird teuer!

In klassischen Projekten stellt man diese Integrationsfehler
häufig erst am Ende fest und dann wird es teuer. Meist werden
diese Integrations-Fehler, die häufig Logikfehler sind, auf die
Anwenderin abgewälzt. Beispielsweise durch Treppen bei den
Höhenunterschieden der Brücken. Wenn im ausgelieferten Fertighaus
beispielsweise ein Loch von einem Meter in der Wand ist, dann ist
die Ausbesserung nachträglich doch recht teuer. Oder wenn auf
Grund dessen ein Fenster versetzt werden muss. Klar kann man dies
durch andere Prozesse wiederum auffangen und meist geht es gut.
Lösung

Die Lösung wirkt recht simpel und doch ist sie nicht trivial:
Kontinuierlich integrieren.


Es gibt den großen Wasserfall, wo erst am Ende, oft nach Jahren,
integriert wird. Dann gibt es Scrum, den kleinen Wasserfall, wo
in kurzen Abständen integriert wird und es gibt Continious
Integration (CI), wo bei jedem Schnipsel sofort integriert wird.
Scrum nähert sich dem quasi als Kompromiss, durch einen sehr
klein getakteten Wasserfall.


Diese, häufig Code Schnipsel, werden dann häufig automatisiert
integriert und direkt getestet. Continious Integration setzt also
auch einen hohen Grad an Automatisierung voraus, den wir auch
gern propagieren.


Wir reden hier wirklich von Zeitabschnitten von kleiner einem
Tag. Oft nur Minuten oder Stunden.


Um wieder in den Hardwarebereich zu schauen: Wir haben von den
Vorträgen von Joe Justice gehört, dass Tesla wohl auch
Konstruktionsänderungen ihrer Fahrzeuge sofort integrieren und
testen. Das Fahrzeug entwickelt sich also während der Produktion
mitunter weiter. Quelle: https://youtu.be/FE7OUGC4OB8


Ähnliche Implementierungen, wie bei Tesla, gibt es wohl auch bei
Scania in deren Truck Module und bei Saab in der Entwicklung des
Gripen Fighters. Quelle:
Release-version_Owning-the-Sky-with-Agile.pdf (scruminc.com)
Prämissen

Für Continious Integration (CI) gibt es ein paar Prämissen, damit
es reibungslos funktioniert.


Unter anderem ist wichtig, dass man modulweise entwickeln kann.
Dies macht beispielsweise auch Netflix.


Genauso ist automatisiertes Testen absolut notwendig dafür.
Gerade bei Hardware bedeutet dies natürlich, dass wir uns
wahnsinnig komplexe Strukturen aufbauen dürfen um diese Hardware
automatisiert testen zu können. Als Belohnung können wir dafür
schneller integrieren und auch schneller Neuerungen auf den Markt
bringen.
Continious Deployment

Es gibt neben Continious Integration und Continious Delivery auch
Continious Deployment. Es muss also nicht alles, was integriert
wurde, auch verteilt und damit auch ausgeliefert werden. Das sind
zwei weitere Schritte.


Diese Unterscheidung ist vor allem wichtig um Releasemanagement
zu ermöglichen und Releases vielleicht auch anders schneiden zu
können. Wir sind darauf schon etwas in der Release BurnDown Folge
eingegangen.
Bücher schreiben

Um das Ganze für Dich vielleicht einmal etwas greifbarer zu
machen: Wir schreiben gerade mit dem lieben David Symhoven ein
Buch. Dieses Buch entsteht auch indem wir unterschiedliche Module
(Kapitel) haben und diese regelmäßig integrieren um zu schauen,
dass alles zusammenpasst. Dies ermöglicht uns auch kontinuierlich
abzugleichen ob die Kapitel noch stimmig zusammenpassen.
Prozesse

Das Ganze funktioniert auch mit Prozessen. Wir könnten einzelne
Prozessschritte wie Module betrachten und müssen natürlich die
vorgelagerten und nachgelagerten Prozessschritte oder ganze
Prozesse kennen. Dann können wir aber auch kleinere Änderungen
bei uns integrieren ohne immer direkt die komplette Prozesskette
aktualisieren zu müssen. Auch ein Unterschriftendurchlauf wäre so
wahrscheinlich nicht mehr nötig. Trotzdem bräuchten wir eine
Automatisierung, die diesen Prozess wiederum testet.
Verhaltensweisen & Grundsätze

Martin Fowler, auch Gründer des Manifests für Agile
Softwareentwicklung, hat nun ein paar Verhaltenweisen für
Continious Integration (CI) festgeschrieben. Erst daraus wird es
wirklich Continious Integration.




Nur eine Quelle (Gemeinsame Codebasis)




Automatisierte Builds / Übersetzung




Selbsttestende Systeme / Kontinuierliche Test-Entwicklung


Häufige Integration



Funktionstüchtige Mainline / Trunk




Sofortige Reparatur




Kurze Integrationszeit




Gespiegelte Produktionsumgebung




Einfacher Zugriff




Automatisiertes Reporting


Automatisierte Verteilung



Zudem ist Transparenz ein sehr wichtiger Wert hinter genau diesem
System. Zudem brauchen wir eine Versionsverwaltung um Änderungen
zu erkennen und Abweichungen von unserem Stand zu identifizieren.
Was also wenn jemand anderes in die Quelle integriert hat,
während ich auch daran gearbeitet habe?


Die Versionsverwaltung ist auch wichtig um eventuelle Fehler
später schnell wieder rückgängig machen zu können.


Genau aus diesem Grund ist es übrigens sinnvoller OKR in Systemen
statt in Excel-Tabellen zu pflegen. Selbiges gilt für
Anforderungen und Offene Punkte Listen.
Qualitätssteigerung

Das oberste Ziel, warum wir das alles tun, ist die Verbesserung
der Qualität.


Wir bekommen so sehr früh mit, wenn Module nicht so
zusammenpassen, wie geplant.


Zusätzlich können wir uns jederzeit aus der einen Quelle bedienen
und bekommen ein funktionsfähiges Produkt daraus.


Janina Kappelhoff geht da noch einen Schritt weiter:


Wenn das nicht existiert, kann auch keine Psychologische
Sicherheit entstehen.
Takt

Die kontinuierliche Integration gibt auch den Takt vor oder
ermöglicht diesen überhaupt.


Dadurch könnten wir Sprints oder kurze Iterationen machen und
stellen erst hierüber frühzeitig Abweichungen im Ergebnis fest.
Klassische Integration

Als Henry Schneider noch als klassischer Projektmanager unterwegs
war, wurden alle IT-Systeme einmal im Jahr gleichzeitig
integriert. Nur dieses eine Mal. Dafür gab es zwei Monate
Integrationstestzeit. Es wurden eigentlich immer Fehler
festgestellt und durch diese großen Integrationen war es gar
nicht so leicht herauszufinden wo der Fehler nun wirklich liegt.
Tools

In der Softwareentwicklung gibt es viele Tools, die uns dabei
unterstützen können.


Hier ein paar davon und es gibt noch viele mehr: Jenkins, Bamboo,
Cruise Control, TeamCity und Travis CI


 


Get shit done,


Janina & Henry


Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen
weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du
magst verlinke @znip_academy_agile und wir teilen deinen Like mit
unseren Hörern.


Du möchtest dich von uns in der Tiefe in eurem
Veränderungsprozess begleiten lassen, eure größten
Komplexitätsnester auflösen und die besten Teamtipps bekommen?
Dann buch uns


Janinas Ultimativer OKR Guide


In der Podcastfolge erwähnte Folgen zur Vertiefung:


Flow

Agilität

Team

Scrum

Testmanagement

Transparenz

OKR

Sprints



Connecte dich gerne hier mit uns:


LinkedIn


Instagram


YouTube


Facebook


Webseite


Facebook-Gruppe


The post 135 Continious Integration (CI) appeared first on
Znipcast - für gute Zusammenarbeit | Agile, Scrum, KanBan,
Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy.