Wie erklärt man Continuous Integration in einem Satz?

M&F Engineering und über 40 Seminarteilnehmerinnen und - teilnehmer haben letzten Freitag versucht, Continuous Integration zu verstehen. Dabei lernten wir sieben Sachen.

Geschätzte Lesezeit: zwischen 5 und 10 Minuten.

Die Situation

Es ist Freitag 6.30 Uhr während der Hitzewelle. Jetzt ist es noch kühl, aber die Sonne scheint, keine einzige Wolke ist zu sehen und 35° C sind vorhergesagt. Meine Freundin packt Sonnencreme, ein Buch über Organische Chemie und ihr Bikini. Sie geht an den Zürichsee lernen. Ich trinke meinen Kaffee fertig, ziehe ein langarmiges Hemd an, packe mein ThinkPad und steige in den nächsten Bus nach Fahrweid ZH.

Heute findet bei der M&F ein wichtiges Seminar statt. Es ist schon 8.15 Uhr und unser Haus in Fahrweid ist voll mit Softwareentwicklerinnen und -entwicklern, die mehr als 20 Unternehmen aus der Deutschschweiz vertreten. Da hinten steht ein junges Talent von der Bosch. Für sein Projekt hat er selbstständig eine funktionierende Continuous Integration Pipeline entwickelt. Vor ihm sind zwei Kollegen von der Siemens, die interne Applikationen für Techniker entwickeln. Wir haben Industrie-Freunde eingeladen, um Kaffee zu trinken, über Probleme zu reden und eine wichtige Frage zu beantworten.

Was ist Continuous Integration?

Benutzen wir es schon? Sind wir alle noch nicht agil? Oder muss ich mir ein neues Tool kaufen und das Wort DevOps regelmässiger brauchen, so wie ich es in diesem einen Webblog mal gelesen habe?

Es ist 9 Uhr und Michael Palotas übernimmt das Wort. Ja! Der Entwickler vom W3C Standard Selenium, CEO von Element34 und ehemaliger Head of Quality Engineering Europe von E-bay ist auch ein Freund von uns! Und er kann agile Softwareentwicklung wirklich gut erklären! Zwischen Kaffee, Gipfeli und vielen spannenden Fragen verbringen wir so die nächsten vier Stunden.

Unsere sieben Take Aways

Ich bin kein Michael Palotas, aber ich habe versucht, die wichtigsten Punkte unseres Gespräches in 500 Wörtern zu sammeln.

1) Nicht alle Entwickler müssen agil sein.

Manchmal sind die Anforderungen bekannt und spezifisch genug. Die Deadline ist fest, keine Änderungen sind zu erwarten und ähnliche Projekte wurden vom Entwicklungsteam schon mal gemacht. In so einer Situation ist ein Wasserfall-Vorgehensmodell legitim.

2) Wenn Veränderungen im Projekt eine zentrale Rolle spielen, kann man von Agilität profitieren.

Ist die Anpassung an Veränderungen wichtig für dein Projekt? Für die über 40 Entwicklerinnen und Entwickler, die am Freitag bei der M&F über Agilität, Continuous Integration und DevOps diskutiert haben, ist diese Frage mit einem Ja zu beantworten.

3) Bei der agilen Softwareentwicklung liefert man in kurzen Zeitfenstern.

Früher kam jedes Jahr oder alle paar Jahre ein grosser Release. Der Bug ist bekannt und der Patch kommt im Update 9.X von der Software YZ in 16 Monaten.

In der agilen Software-Entwicklung liefert man alle paar Wochen funktionierenden Code, der schon getestet und dokumentiert worden ist. Klingt unmöglich? Die Developers von Element34 brauchen nur wenige Minuten, um einen Bug-Fix in ihrem Produkt zu patchen und im Live-System zu pushen. In der Zeit sind die Kunden noch nicht einmal von ihrer Kaffeepause zurück. ;-)

4) Agilität funktioniert besser, wenn man eine Continuous Integration Pipeline hat.

Reto Bättig ist der erste in der Gruppe, der diese Idee formuliert hat. Unser CEO hat über 20 Jahre Arbeitserfahrung als Softwareentwickler und hat wahrscheinlich an über hundert Projekten in verschiedensten Unternehmen teilgenommen. Dabei konnte er sehen, wie manche agile Projekte scheitern und wie andere erfolgreich sind. Die erfolgreichen agilen Projekte haben etwas gemeinsam: eine CI Pipeline.

Agilität scheint eine Mentalität zu sein, während Continuous Integration eine Vorgehensweise ist, mit der man diese Mentalität realisieren kann.

5) Für Continuous Integration braucht man Tests, Tests und Tests

Und damit meinen wir natürlich automatisierte Tests. Die Zeit von einer Softwareentwicklerin ist wertvoll! Sie sollte coden, sich Gedanken über das Design machen, Kaffee trinken und automatisierte Tests schreiben. Wenn sie regelmässig liefern will, kann sie nicht bei jeder Änderung unzählige Features manuell testen. Und eine Armee von Testern für jede Entwicklerin und jeden Entwickler einzustellen, ist teuer und unnötig. Also schreibe Tests!

6) Eine CI Pipeline automatisiert kritische Prozesse der Softwareentwicklung.

Wir sind nicht Amateure - sondern Spezialisten. Unser Code ist nicht fertig, bis er bestimmte Qualitätsmerkmale erreicht hat. Das Team kann beispielsweise wollen, dass mindestens 40% vom Code anhand von Unit-, System- und UI Tests automatisch geprüft wird. Die Dauer des Builds könnte einer Obergrenze unterworfen sein (Ja, das ist möglich. Stichwort: modularisieren). Bei uns ist die Obergrenze die Dauer einer Kaffeepause --- am besten die Dauer eines Espressos.

Die Gefahr: Qualitätsprüfung braucht Zeit. Unter Abgabestress wird Qualität manchmal vernachlässigt. Beim nächsten Entwicklungszyklus hat man technical Debt gesammelt und der Entwicklungsprozess verlangsamt sich jetzt. Eine CI Pipeline kann dagegen helfen, indem viele Schritte zur Qualitätssicherung automatisiert werden.

7) Sowohl kommerzielle Software als auch Open-Source-Software haben ihre Existenzberechtigung.

Zum Beispiel: Die kommerzielle CI Pipeline von Microsoft übernimmt viele Entscheidungen für den User, was die Nutzung der Pipeline vereinfacht. Währenddessen bieten Open-Source-Komponenten viel Flexibilität.

Bei der kommerziellen Software muss man eine Lizenz bezahlen. Bei einer Open-Source-Lösung muss man an den Bytegott beten, dass die Contributors im github das Produkt in den nächsten Jahren auf dem neuesten Stand halten. In beiden Fällen muss man die Lizenz verstehen.

Die Entscheidung ist nicht einfach. Es gibt nämlich ein riesiges Angebot. Vielleicht kann dir der Periodic Table von Continuous Integration dabei helfen.

Eine CI Pipeline klingt gut und alles, aber gibt es überhaupt Leute, die wirklich so arbeiten?

Gegen 13 Uhr hatte ich schon zwei Cappuccinos und drei Espressos getrunken. Wie es unter Developers halt so ist, hatten wir stundenlang geredet und trotzdem gab es jetzt mehr neue Fragen als Antworten. Eine CI Pipeline zu planen und zu erstellen klingt aufwendig. Und was, wenn die Software mit Hardwarekomponenten kommunizieren soll? Geht das überhaupt?

Erfreulicherweise übernahm in diesem Moment unser neuester Mitarbeiter, Uche Mennel, das Wort. Wenn man Glück hat, hat man Glück. Und wir haben seit Mai die Ehre, Uche zu unserem Team zu zählen. Seit seinem Masterstudium in Informatik an der ETH hat Uche schon jahrelang "krasse" Software geschrieben. Es sind noch keine zwei Monate vergangen und er arbeitet schon Vollzeit in einem von unseren spannendsten Projekten: dem Teilchenbeschleuniger.

Die CI Pipeline und der Teilchenbeschleuniger

Uche schreibt Software für den Teilchenbeschleuniger von Ionplus. Verrückt, gell? Obwohl er alle drei Wochen neue Features schreibt (ich habe Angst, dass er ein Speeding-Ticket bekommt), muss seine Software makellos sein. Ein kleiner Fehler und die ganze Zürcher Stadt wird von einem schwarzen Loch verschlungen (Ok, vielleicht auch nicht so schlimm, aber es wäre auf jeden Fall sehr teuer). Wie schafft er das?

Uche arbeitet mit der CI Pipeline von Azure DevOps (Microsoft). Er schreibt nicht nur Code für seine Software, sondern auch viel Test-Code (Unittests, Systemtests, ...). Die CI Pipeline kann die Software dann automatisch builden und den neuen Code in einer Testumgebung überprüfen. Für die Testumgebung benutzt er einen Virtual Twin --- ein schon implementiertes physikalisches Modell vom Teilchenbeschleuniger.

Softwareentwicklung bei der M&F Engineering ist ein sozialer Event. Nachdem der neue Code von Uche alle automatischen Tests und Qualitätskriterien bestanden hat, schaut sich ein Arbeitskollege den Code nochmal an. Erst nach diesem letzten Code Review lädt Uche seine Erweiterungen in die Live-Umgebung hoch. Zusammengefasst: Jede neue Funktionalität wird automatisch getestet und von mindestens vier Augen kontrolliert, bevor sie in der Produktionsumgebung landet.

Und da bisher kein schwarzes Loch die Zürcher Stadt zerstört hat, scheint die CI Pipeline und Methodologie von Uche zu funktionieren. Schauen wir weiter, er arbeitet ja noch zwei Jahre an diesem Projekt.

Also jetzt endlich, was ist Continuous Integration?

Wie gesagt, wir waren über 40 Softwareentwicklerinnen und -entwickler von über 20 Schweizer Unternehmen. Denkst du wirklich, dass wir uns auf eine Definition einigen konnten?

Wie auch immer es sein mag, wir alle haben viel von einander gelernt. Jetzt ist es Freitag, 18.34 Uhr, die Sonne ist heiss und die Limmat ist kühl. Ich klappe mein ThinkPad zu und gehe jetzt schwimmen.