Con­ti­nuous In­te­gra­ti­on: Die kon­ti­nu­ier­li­che In­te­gra­ti­on erklärt

Wer in der Soft­ware­ent­wick­lung arbeitet, der kennt die Probleme von In­te­gra­ti­on: Neuer Code ist ge­schrie­ben, die ei­gent­li­che Aufgabe erledigt, nun muss der Quelltext nur noch in das große Projekt eingefügt werden – und dabei treten dann die Probleme auf. Damit nicht am Ende einer langen Ent­wick­lungs­pha­se eine Ka­ta­stro­phe passiert, weil nichts zu­sam­men­passt, ent­schei­den sich viele Teams für Con­ti­nuous In­te­gra­ti­on: Än­de­run­gen werden dadurch jeden Tag direkt in das Projekt eingefügt, im besten Fall sogar mehrmals täglich.

Con­ti­nuous In­te­gra­ti­on ist – genau wie Con­ti­nuous Delivery – vor allem im Umfeld von agiler Soft­ware­ent­wick­lung sehr beliebt. Ziel bei dieser modernen Her­an­ge­hens­wei­se ist es, klein­schrit­ti­ger zu arbeiten, um dadurch den Ent­wick­lungs­pro­zess selbst ef­fek­ti­ver gestalten und auf Än­de­run­gen flexibler reagieren zu können. Das erste Mal erwähnt wurde Con­ti­nuous In­te­gra­ti­on folglich in der Be­schrei­bung der agilen Methode Extreme Pro­gramming von Kent Beck. Grund­sätz­lich exis­tier­te die Idee einer kon­ti­nu­ier­li­chen In­te­gra­ti­on aber schon zuvor. Sie spielt bei­spiels­wei­se auch bei der Booch-Methode eine Rolle.

Mit der kon­ti­nu­ier­li­chen In­te­gra­ti­on schafft man eine Lösung für Szenarien folgender Art: Das Un­ter­neh­men arbeitet an einem großen Projekt. Der Kunde soll eine um­fang­rei­che, komplexe Software erhalten. Einzelne Teams er­ar­bei­ten nun Teil­aspek­te der Anwendung und die Ent­wick­ler pro­gram­mie­ren wiederum einzelne Funk­tio­nen. Nach mo­na­te­lan­ger, viel­leicht jah­re­lan­ger Arbeit, muss alles zu­sam­men­ge­fügt werden – und dabei treten dann Probleme auf. In einem solchen Fall kann es dann abermals Monate dauern, bis die Fehler auf­ge­spürt und bereinigt und alle Code-Schnipsel zu­sam­men­ge­fügt sind und man sich schließ­lich dem finalen Testing und dem De­ploy­ment nähert.

Bei der Con­ti­nuous In­te­gra­ti­on erfolgt die Ein­bin­dung von neuem Code viel früher und nicht erst, wenn sämtliche Be­tei­lig­ten ihren Teil­be­reich fer­tig­ge­stellt haben. Die Ent­wick­ler fügen statt­des­sen ihren fer­tig­ge­stell­ten Code einmal oder mehrmals am Tag in die Mainline ein – dem Quelltext, der allen Pro­gram­mie­rern of­fen­steht. Da es sich dabei immer nur um relativ kleine Code-Ab­schnit­te handelt, fällt auch die In­te­gra­ti­on eher kurz aus. Nur wenige Minuten sollte ein Ent­wick­ler brauchen, um sein Ar­beits­er­geb­nis dem rest­li­chen Team zur Verfügung zu stellen. Entdeckt man hierbei einen Fehler, kann dieser sofort auf­ge­spürt und im besten Fall schnell behoben werden.

In der Praxis läuft Con­ti­nuous In­te­gra­ti­on meist so ab: Ein Ent­wick­ler hat den Auftrag, eine Funktion zu erstellen. Bevor dieser nun mit der Pro­gram­mier­ar­beit beginnt, lädt er sich die aktuelle Version des kom­plet­ten Codes der Anwendung herunter, die so­ge­nann­te Mainline. In dieser Version, die sich nun auf seinem per­sön­li­chen Computer befindet (auch Working Copy genannt), kann er arbeiten. Hat er seine Aufgabe erledigt, testet er das Programm aus, beseitigt etwaige Fehler und kann nun die neue Version wieder in die Mainline stellen.

Al­ler­dings arbeitet der Ent­wick­ler ja nicht allein an dem Programm. Während er seine Än­de­run­gen vor­ge­nom­men hat, haben seine Kollegen höchst­wahr­schein­lich andere Aufgaben erledigt und so hat jeder Ent­wick­ler des Teams nun eine un­ter­schied­li­che Fassung auf dem Ar­beits­rech­ner. Auch die Fassung der Mainline dürfte sich in­zwi­schen verändert haben und so muss der Pro­gram­mie­rer alle Än­de­run­gen zunächst in seine Working Copy einfügen. Sollte nun ein Fehler auftreten, ist es an ihm, diesen zu beheben. Erst dann kann der Pro­gram­mie­rer seine Än­de­run­gen der Mainline hin­zu­fü­gen. Und dann testet er das Programm erneut. Erst wenn hierbei ebenfalls keine Fehler auftreten – was passieren kann, wenn er seine Working Copy nicht korrekt ak­tua­li­siert hat – ist der Vorgang tat­säch­lich ab­ge­schlos­sen und der Ent­wick­ler kann sich der nächsten Aufgabe widmen.

Wenn man auf diese Weise arbeitet, muss man sich an einige Regeln halten: Meist ori­en­tie­ren Pro­gram­mie­rer sich dabei an den Grund­sät­zen, die Martin Fowler (seines Zeichens selbst Soft­ware­ent­wick­ler) einst für die er­folg­rei­che Con­ti­nuous In­te­gra­ti­on er­ar­bei­tet hat. Sie stellen in erster Linie sicher, dass sich alle Be­tei­lig­ten auf dem gleichen Level befinden und niemand durch ab­wei­chen­des Vorgehen ein Chaos ver­ur­sacht.

Es klingt selbst­ver­ständ­lich, ist aber einer der wich­tigs­ten Faktoren: Alle Team-Mit­glie­der müssen dieselbe Quelle (dasselbe Re­po­si­to­ry) verwenden, wenn sie am Code arbeiten. Das gilt nicht nur für den Quelltext an sich. Denn für eine funk­tio­nie­ren­de Anwendung sind weitere Elemente, wie zum Beispiel Da­ten­ban­ken, nötig. Auch diese müssen gesammelt an einem Ort gebündelt werden. Daher empfiehlt Martin Fowler, ein Re­po­si­to­ry so auf­zu­bau­en, dass auch ein Ent­wick­ler mit einem komplett neuen Ar­beits­com­pu­ter mit­ar­bei­ten kann und sämtliche be­nö­tig­ten Dateien zentral an einem Ort ver­sam­melt findet.

Um aus dem Quelltext ein funk­tio­nie­ren­des Programm zu gestalten, müssen sie diesen kom­pi­lie­ren, Da­ten­ban­ken ak­tua­li­sie­ren und Dateien an den richtigen Platz ver­schie­ben. Diesen Prozess kann man au­to­ma­ti­sie­ren. Es sollte idea­ler­wei­se möglich sein, einen Build-Prozess mit nur einem Kommando aus­zu­füh­ren.

Von noch mehr Au­to­ma­ti­sie­rung und damit Be­schleu­ni­gung der Con­ti­nuous In­te­gra­ti­on pro­fi­tiert ein Team, wenn es Testing-Me­cha­nis­men in den Build-Prozess ein­glie­dert. Genau wie der Build-Prozess selbst müssen die Tests (am besten man im­ple­men­tiert eine ganze Riege ver­schie­de­ner Prüf­me­cha­nis­men) sich mit möglichst wenig Aufwand ausführen lassen.

Kon­ti­nu­ier­li­che In­te­gra­ti­on kann nur funk­tio­nie­ren, wenn auch alle Team-Mit­glie­der das System mittragen. Sobald ein Kollege seinen Code nicht permanent in die Mainline in­te­griert, gehen die Kollegen von falschen Prämissen aus. Alle nehmen an, dass sie an einem stabilen System arbeiten, aber sollte jemand zu lange (mehr als einen Tag) den Code zu­rück­hal­ten, kann die an­schlie­ßen­de Feh­ler­su­che zu einem Problem werden. Wie so oft im Leben ist auch bei der Con­ti­nuous In­te­gra­ti­on Kom­mu­ni­ka­ti­on ein wichtiger Faktor: Wenn die Ent­wick­ler sich aber ge­gen­sei­tig auf dem neuesten Stand halten, lassen sich kleinere Schwie­rig­kei­ten schnell klären.

Der Pro­gramm­code, den man in der Mainline findet, sollte immer getestet und funk­ti­ons­tüch­tig sein. Deshalb darf jeder Ent­wick­ler seinen Code nur in diesen Haupt­zweig in­te­grie­ren und nicht in einem eigenen Ne­ben­zweig arbeiten. In diesem Zu­sam­men­hang sollte auch jeder Ent­wick­ler Sorge tragen, dass sein eigener Beitrag funk­ti­ons­tüch­tig ist. Nach der In­te­gra­ti­on muss er also den Code und den Build testen. Tritt ein Fehler auf, muss er diesen beheben. So ist si­cher­ge­stellt, dass der Code immer feh­ler­frei ist.

Von oberster Wich­tig­keit bei der Con­ti­nuous In­te­gra­ti­on ist, dass niemals eine feh­ler­haf­te Version in der Mainline bleibt. Das bedeutet für die Ent­wick­ler, dass man die Reparatur nicht auf­schie­ben darf. Laut Martin Fowler ist es kein Problem, wenn Builds nicht funk­tio­nie­ren und der Code über­ar­bei­tet werden muss, aber das System der kon­ti­nu­ier­li­chen In­te­gra­ti­on verlangt, dass die Reparatur sofort geschieht. Denn alle Ent­wick­ler müssen davon ausgehen können, dass der Code in der Mainline funk­tio­niert – ist das nicht der Fall, baut das ganze Team in in­sta­bi­len Systemen und löst so eine Lawine an Fehlern aus.

Die ei­gent­li­che In­te­gra­ti­on des Codes (inklusive des Testings) sollte möglichst schnell erfolgen. Extreme Pro­gramming (XP) sieht hierfür nur 10 Minuten vor. Da ein Ent­wick­ler unter Umständen mehrmals am Tag in­te­griert, würden lange Build-Zeiten zu hohen Ar­beits­zeit­ver­lus­ten führen. Deshalb ist es notwendig, Me­cha­nis­men zu eta­blie­ren, die den Prozess be­schleu­ni­gen. Um solche hohen Ge­schwin­dig­kei­ten zu er­mög­li­chen, muss man auch in Kauf nehmen, nicht jeden denkbaren Test direkt durch­zu­füh­ren. Statt­des­sen im­ple­men­tiert man ein zwei­stu­fi­ges System: In der ersten Phase, die bei der täglichen Arbeit auftritt, werden Tests so durch­ge­führt, dass man kurze Build-Zeiten erreichen kann. Die zweite Testphase dauert hingegen mehrere Stunden und umfasst auch tie­fer­ge­hen­de Über­prü­fun­gen.

Es ist grund­sätz­lich sinnvoll, Tests in einer aus­ge­la­ger­ten und sicheren Umgebung durch­zu­füh­ren. Es muss dabei al­ler­dings ge­währ­leis­tet sein, dass diese genau so kon­fi­gu­riert ist wie die Pro­duk­ti­ons­um­ge­bung. Das kann unter Umständen sehr kost­spie­lig werden, denn die Maschine müsste exakt gleich auf­ge­setzt werden. Durch Vir­tua­li­sie­rung kom­plet­ter Computer wird dieser Kos­ten­fak­tor aber immer kleiner.

Alle Be­tei­lig­ten sollten einen einfachen Zugriff auf den ak­tu­ells­ten Stand haben und das Programm ausführen können. Dies um­zu­set­zen ist relativ einfach: Da Con­ti­nuous In­te­gra­ti­on es ohnehin erfordert, alle Dateien in einem Re­po­si­to­ry zu ver­sam­meln, muss dieser Ort nur allen bekannt sein. Dafür gibt es mehrere gute Gründe: Tester können so bereits zu­sätz­li­che Tests im laufenden Pro­gram­mier­pro­zess beginnen, Stake­hol­der aus­führ­ba­re Dateien zu De­mons­tra­ti­ons­zwe­cken nutzen und Qua­li­täts­ma­na­ger die Zahlen über­prü­fen.

Es ist nicht nur wichtig, dass alle Be­tei­lig­ten Zugriff auf den Quelltext und die aus­führ­ba­re Datei haben, ebenso muss deutlich sein, welche Än­de­run­gen von wem durch­ge­führt wurden. Zur Kom­mu­ni­ka­ti­on gehört auch, dass Ent­wick­ler sich ge­gen­sei­tig ver­stän­di­gen, wenn sie in einem Build-Prozess sind. Dafür verwenden manche Teams ge­son­der­te Displays oder visuelle Dar­stel­lun­gen, die zeigen, dass man gerade mit einer In­te­gra­ti­on be­schäf­tigt ist.

Schließ­lich sollte man auch die Soft­ware­ver­tei­lung au­to­ma­ti­sie­ren. Dateien müssen von einer Umgebung in eine andere überführt werden, was zeit­auf­wen­dig sein kann. Deshalb ist es sinnvoll, hierfür Skripte ein­zu­set­zen. Diese au­to­ma­ti­sie­ren und be­schleu­ni­gen den Prozess.

Trotz ihrer positiven Merkmale zeigt sich im Ar­beits­all­tag oft, dass Con­ti­nuous In­te­gra­ti­on nicht aus­schließ­lich Vorteile hat. Zwar erspart man sich eine große und lang­wie­ri­ge In­te­gra­ti­ons­pha­se zum Ende des Projekts und kann Probleme früh­zei­tig in Angriff nehmen, aber für ein­ge­spiel­te Teams kann eine Um­stel­lung auf Con­ti­nuous In­te­gra­ti­on sehr schwierig sein. In einem solchen Fall kann das Verfahren sogar mehr Zeit kosten, anstatt Zeit zu sparen.

Prin­zi­pi­ell kann man kon­ti­nu­ier­li­che In­te­gra­ti­on auch ohne extra dafür erstelle Werkzeuge managen, denn alle Ar­beits­schrit­te lassen sich durchaus manuell erledigen. Das erfordert aber sehr viel Disziplin und noch mehr Aufwand. Man kann sich die Arbeit daher auch mit nütz­li­chen Tools er­leich­tern. Diese stellen meist einen Server zur Verfügung und helfen beim Building und der Ver­si­ons­kon­trol­le.

• Jenkins: Bei dem sehr populären Java-Programm handelt es sich um einen Fork von Hudson, der in­zwi­schen nicht mehr wei­ter­ent­wi­ckelt wird. Die Open-Source-Software arbeitet mit ver­schie­de­nen Build-Tools und Ver­si­ons­ver­wal­tungs­sys­te­men.
   
• Travis CI: Dieses Werkzeug zur kon­ti­nu­ier­li­chen In­te­gra­ti­on ist ins­be­son­de­re deswegen so beliebt, weil es rei­bungs­los mit GitHub zu­sam­men­ar­bei­tet. Das Online-Re­po­si­to­ry in­for­miert Travis über Än­de­run­gen am Code. Die Software gibt es für Open-Source-Projekte in einer kos­ten­lo­sen und für alle anderen Vorhaben in einer kos­ten­pflich­ti­gen Version.
   
• Bamboo: Mit dem Server Bamboo können Ent­wick­ler In­te­gra­ti­on, De­ploy­ment und Release-Ma­nage­ment erledigen. Der Her­stel­ler Atlassian bietet die Software als Web­ober­flä­che auf Basis von Java an. Bamboo un­ter­stützt Ent­wick­ler durch Au­to­ma­ti­sie­run­gen und arbeitet mit ver­schie­de­nen Build-Tools zusammen. Für Open-Source-Projekte steht das nor­ma­ler­wei­se kos­ten­pflich­ti­ge Angebot auch kostenlos zur Verfügung.
   
• Gitlab CI: GitLab bietet ein eigenes Programm zur kon­ti­nu­ier­li­chen In­te­gra­ti­on an, das mit der bekannten Ver­si­ons­ver­wal­tung funk­tio­niert. Die Pipeline lässt sich in­di­vi­du­ell gestalten und so an jedes Projekt anpassen. Zu­sätz­lich un­ter­stützt auch GitLab CI Docker.
   
• CircleCI: Von diesem Programm für die Con­ti­nuous In­te­gra­ti­on gibt es zwei ver­schie­de­ne Versionen. Entweder ent­schei­det man sich für eine Variante direkt in der Cloud des Anbieters oder man erstellt zur Nutzung einen eigenen lokalen Server.
   
• Crui­se­Con­trol: Ur­sprüng­lich von Thought­Works (einer Firma rund um Martin Fowler) ent­wi­ckelt, besteht Crui­se­Con­trol in­zwi­schen als ei­gen­stän­di­ges Projekt. Die freie Software basiert auf Java und ist damit platt­form­un­ab­hän­gig. Unter anderem bietet Crui­se­Con­trol für Ent­wick­ler ein Dashboard – eine eigene Webseite – auf der man den Status der Builds erkennen kann.
   
• Codeship: Codeship versucht Ent­wick­lern eine sehr einfache Mög­lich­keit zur Con­ti­nuous In­te­gra­ti­on zu liefern. Auf der Basis der Container-Tech­no­lo­gie lassen sich leicht Au­to­ma­tis­men erstellen. Für diese Aufgabe bietet das Un­ter­neh­men zwei ver­schie­de­ne Versionen an: Basic und Pro.
   
• TeamCity: Die kom­mer­zi­el­le Software TeamCity legt sehr viel Wert auf In­ter­ope­ra­bi­li­tät mit anderen Werk­zeu­gen. Viele Programme werden bereits in der Stan­dard­ver­si­on un­ter­stützt, zu­sätz­lich lässt sich das Spektrum aber auch noch durch Plug-ins erweitern. Eine Be­son­der­heit findet man zudem im Pre-Tested Commit. TeamCity überprüft den neu­ge­schrie­be­nen Code bereits vor der In­te­gra­ti­on in die Mainline selbst­stän­dig und in­for­miert den Ent­wick­ler bei Fehlern.