Continuous Integration. Ihr habt ja jetzt schon mal ein bisschen Kontakt damit gehabt. Gibt es vielleicht

jemanden unter euch, der schon mal mit einem größeren Projekt mit Continuous Integration

gearbeitet hat? Hat schon mal jemand Erfahrungen mitgemacht? Kannst du vielleicht mal was dazu

sagen? Also wie waren deine Erfahrungen? Ich habe schon mal ein Change-In gemacht und TFS. Ich fand TFS viel angenehmer.

Ich konnte schön Pipelines bilden, ein großes Projekt bilden, viele Sachen automatisch machen.

Ich habe sehr viel Arbeit gemacht. Sehr gut. Also es haben schon ein paar Erfahrungen gemacht. Das ist sehr gut.

Eigentlich in sich das Problem von Continuous Integration wird gerade bei größeren Projekten eher klar, weil es

darum geht, man zieht sich den aktuellen Stand des Repositories, baut seinen eigenen Code drauf,

testet das ja meistens nochmal lokal. Klar, logisch. Wenn es dann darum geht, das Ganze in das Repository

zu pushen, geht es aber los. Also da hat der Kollege vielleicht auch schon was geändert. Gibt es da Konflikte?

Läuft da was vielleicht nicht? Das heißt, man muss die Tests nochmal ausführen, man muss das Ganze Projekt

bilden. Wenn man das natürlich manuell macht, dann ist das ein unglaublicher Overload und hat man eigentlich

auch keine Lust dazu. Und da kommt es natürlich auch dazu, dass man das schön rausschiebt und dann

werden die Probleme halt leider immer größer. Genau, Continuous Integration hackt genau an der Stelle ein.

Also dort hat man die Möglichkeit, genau man pusht seinen Code in das Repository und in dem Moment wird

hier ein CI-Server getriggert automatisch und dort finden dann verschiedene Abschnitte statt. Also das

ganze Projekt wird gebildet, es werden Tests durchlaufen und am Ende erhält der Nutzer oder

der Entwickler ein Feedback, weiß was Sache ist, weiß wo auch eventuell Fehler liegen könnten und

es macht die ganze Sache natürlich ziemlich einfach und der große Vorteil ist, dass so die

verschiedenen Stände bei den verschiedenen Entwicklern auch nicht weit auseinander liegen,

um am Ende große Integration zu vermeiden. Genau, wie ich es bereits gesagt habe, also es gibt

verschiedene Vorteile. Es macht ziemlich sicher, dass man auf dem Stand, wo man gerade auf dem

Projekt arbeitet, dass das ein gesunder Zustand ist, dass man weiß, okay das, was hier gezogen ist,

das läuft auch gut. Schnelle Integration, wie ich auch gerade gesagt habe, man bekommt ein gutes

Feedback. Je nachdem, wie die Tests gearbeitet sind, wie die Reports zurückgegeben werden,

ist es natürlich dann auch einfacher, die ganzen Bugs zu finden, einfacher zu lokalisieren. Genau,

aufgrund der Schnelligkeit des Feedbacks macht man natürlich auch eine regelmäßige Integration und

kann so auch wirklich auch auf Dauer die Qualität des Quotes verbessern. Es erzieht natürlich auch

manche Programmiere in mancher Hinsicht, manche Fehler nicht immer wieder zu tun und es reduziert

auch die Risiken bei größeren Änderungen, also wie Refactoring beispielsweise. Genau, es wurde schon

ein Anbieter genannt, das ist Jenkins. Jenkins wird relativ häufig verwendet, weil man das auch

selber hosten kann. Also das haben dann die Unternehmen lokal und der große Vorteil ist

natürlich auch Datensicherheit im Moment. Travis CI habt ihr jetzt schon kennengelernt,

das gehört zu der Kategorie Software as a Service und GitLab CI gibt es tatsächlich noch, das ist

ziemlich cool, hängt direkt am Repository dran und hat auch eine sehr schöne Darstellung der

Pipeline. Tatsächlich hat jetzt glaube ich auch GitHub eine ähnliche Funktion rausgegeben und es

gibt natürlich unglaublich viele weitere Tools und Anbieter. Als Beispiel ist hier eben auch mal

Buddy dargestellt. Buddy hat den Vorteil, es kann beides. Es kann in der Cloud-Version genutzt werden,

es kann aber auch lokal gehostet werden. Genau, hier ist jetzt mal ein Abriss, so sehr abstrakt

dargestellt von einer Pipeline dargestellt. Also es fängt an, man hat hier verschiedene Stages,

die Stages laufen grundsätzlich seriell ab. Innerhalb der Stages hat man jetzt verschiedene

Jobs, die dann wiederum parallel ablaufen und hier kann man das beispielsweise sehen,

wenn innerhalb eines Stages ein Job failt, laufen alle Jobs in diesem Stage durch,

aber danach bricht die Pipeline ab und danach gibt es den Feedback, das Feedback direkt an

den Entwicklern. Innerhalb eines Jobs gibt es wiederum verschiedene Phasen. Hier ist jetzt

mal ein Ausschnitt von der Travis CI, von dem Skript der Travis CI dargestellt und das sind jetzt

beispielhaft die Phasen bei Travis CI. Die können sich natürlich unterscheiden, gerade im Detail,

also beispielsweise bei GitLab gibt es wiederum ein paar Unterschiede, bei Jenkins wird es auch

Unterschiede geben, aber grundsätzlich beginnt es meistens mit einem Installationsteil, wo eben

auch noch Technologien nachinstalliert werden können und anschließend über die Skripte werden