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,
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 😉
In der Podcastfolge erwähnte Folgen zur Vertiefung:
Connecte dich gerne hier mit uns:
