Hallo, ich bin Mario Manu und rede heute über ConcourseCI, also kleine Projektvorstellungen. Ich selber entwickle nicht mit an ConcourseCI, weil ich benutze die Software quasi täglich

und dachte, es macht Sinn, die auch mal in einem deutschen Vortrag vorzustellen. Ich selber entwickle Open Source Software, zum Beispiel, also in meiner Freizeit die Konferenzmanagement Software, die auch die FrostCon benutzt. Beruflich arbeite ich bei SUSE Linux und arbeite da an Cloud Foundry und aus dem Umfeld

kommt eben auch ConcourseCI. Ich glaube, neu habe ich diesen Laserpointer hier, um die Folien umzuschalten. Der funktioniert aber nur, wenn ich den in der linken Hand halte. Wofür brauchen wir Continuous Integration? Also Continuous Integration würde ich als Verfahren einordnen, um Software zu entwickeln.

Das ist kleiner als ein Prozess, es ist eine Methode, die wir benutzen können, um sicherzustellen, dass der Code, der entwickelt wird, sich auch tatsächlich zurückbringen lässt in den Hauptzweig der Software. Sonst hat man oft das Problem, dass einzelne Entwickler einen Monat oder zwei Monate an irgendeinem Feature arbeiten, wenn die fertig sind und das integriert werden

soll, ist der Hauptzweig der Software so weit fortgeschritten, dass eine Integration nicht mehr möglich ist. Continuous Integration nimmt hier quasi jede Änderung, die gemacht wurde und versucht, einen Zustand zu erreichen, wo man eigentlich mindestens täglich die erstellte Software teilt. Und in dem Moment, wenn man sozusagen den Check-In macht, wenn die Versionskontrolle

sollen auch die Tests laufen. Und diese Tests stellen sicher, dass die Software funktioniert und dass bestehende Teile der Software nicht kaputtgegangen sind durch den Check-In. Also das macht CI und dafür braucht man CI Server. So, also diese Tests bedeuten, dass CI eigentlich auch immer oder häufig in einem

Umfeld eingesetzt wird, in dem testgetrieben, also TDD entwickelt wird und helfen dabei, diese enge Feedback-Schleife zu erzeugen. Den Ursprung hat das alles im Extrem-Programming.

Verfahren aus den 90ern, ich glaube, das Buch zu TDD wurde 99 geschrieben von Kent Beck. Kent Beck kennt man von J-Unit, von dem J-Unit-Testing-Framework und das hat er zum Beispiel gemeinsam entwickelt mit Erich Gama von Design Patterns.

Das Buch kennen bestimmt viele. Das ist so ein bisschen der Hintergrund. XP ist ein agiles Verfahren der Softwareentwicklung. Also ganz ähnlich wie Scrum, hat XP auch Werte, die es verfolgt und einer der ganz zentralen Werte von Extrem-Programming ist der Wissensaustausch, der wird häufig erreicht, indem man zum Beispiel per Programming macht, also nur im Paar

entwickelt und auch immer die Partner in dem Paar tauscht, sowie auch die Storys tauscht, an denen entwickelt wird. So, das ist so ein bisschen der Hintergrund. CI Server helfen dabei. Wir benutzen die im Rahmen von Cloud Foundry. Cloud Foundry ist Open Source Software, muss man erst mal sagen, und dient dazu,

Application Container in der Cloud aufzumachen. Also wer Heroku kennt, das ist so ein bisschen so was wie Heroku. Nur, dass Cloud Foundry eben auch self-hosted sein kann. Man kann das auf OpenStack zum Beispiel selber installieren.

Die Orchestrierung in dieser Cloud, das Deployment von Cloud Foundry wird mit Bosch gemacht, das ist die Komponente, an der wir arbeiten. Bosch installiert sozusagen das gesamte Cloud Foundry, das sind minimal, glaube ich, 17 Maschinen und in dem Umfang ist natürlich klar, wenn man

jetzt irgendwas an Bosch ändert, wenn man sozusagen testen, ob diese Deployments noch gehen, man will Unit-Tests ausführen, man will Integration-Tests ausführen, man will Cloud Infrastruktur mit Terraform starten, man will die wieder runterziehen von Testsystemen, also es sind keine einfachen Test-Pipelines, sondern es ist nicht einfach ein einzelner Testaufruf, es sind komplizierte Pipelines, die hier laufen.

Um an Cloud Foundry mitzuarbeiten, muss man erst mal, das ist keine klassische Open Source, dafür muss man Community License Agreements unterschreiben. Zum Beispiel, ich war außerdem bei einem Dojo, wo ich sechs Wochen sozusagen trainiert habe mit den Leuten, die schon an Cloud Foundry

arbeiten und daher auch der Kontakt mit Concourse, weil Concourse aus derselben Firma kommt wie Cloud Foundry. CI Server kennen wir, kennen wir Jenkins, viele benutzen Jenkins,

ich selber muss gestehen, meine Jenkins-Erfahrungen liegen ein paar Jahre zurück und ich kann jetzt mehrere Sachen über Jenkins sagen, aber Jenkins-User werden wahrscheinlich bei allem sagen, das ist falsch, Jenkins kann das heute sehr viel besser, das mag so sein, also der historische Jenkins benutzt im Wesentlichen Plugins, um Tests auszuführen.

Früher funktionierte das für Java auch sehr gut mit dem Java-Plugin, sobald man zum Beispiel in Ruby oder sowas gearbeitet hat, war man weitgehend auf Skripte angewiesen und diese Skripte führen dazu, also das wurde damals alles in die Web-Oberfläche gepastet, händisch, damit die Tests laufen und man hatte sehr viel State,

man hatte sehr viel einfach, was man so händisch einträgt und auf den Workern, die dann die Tests tatsächlich ausführen, hat man auch sehr viel State, also da geht man hin, da installiert man Datenbanken, oft macht man SSH auf diese Worker, um da irgendwas einzurichten, es ist schwer diese Worker zu back-upen und soweit ich weiß,

ist das alles ein bisschen besser geworden und insofern ist das also kein ganz fairer Vergleich, aber früher waren diese Worker Schneeflocken, kleine Schneeflocken, wenn man die verloren hat, braucht man üblicherweise ein paar Tage, um sie wieder herzustellen, man konnte sich schon gar nicht einfach umziehen, zum Beispiel auf seinen Laptop.

Eine weitere Schwachstelle von Jenkins ist das Fehlen von Pipelines. Jenkins hat sehr wohl Plugins, die zum Beispiel Bildreihenfolgen festlegen, also wo man dann sagen kann, wenn meine unit-Tests durchgelaufen sind, möchte ich meine Integration-Tests starten, aber nur, wenn die unit-Tests erfolgreich waren, weil unit-Tests

dauern zwei Minuten, Integration-Tests leider zwei Stunden, will man also selten ausführen. Pipelines sind nie so richtig Bürger erste Klasse geworden, glaube ich, bei Jenkins, ja, sind sie? Seit einem Jahr, ok. Ok, seit einem Jahr gibt es gute Pipelines in Jenkins für euch aus dem Publikum und ich habe auch gehört, Jenkins kann

mittlerweile diskriptive Konfix, also ich kann meine Konfig irgendwo in einem Git Repository stecken und kann die später in die Oberfläche zurückladen, also ich habe versionierte Konfiguration. Bisher, wenn man das nicht selber baut, würde ich behaupten, dass bei Jenkins die Jobs weiterhin auf VMs laufen oder auf

Workern, Bare Metal, was man so rumstehen hat, aber nicht in Containern. Wahrscheinlich gibt es ein Plugin. Dann gibt es Travis und GitLab, das ist so ein bisschen ein modernerer Ansatz, die Tests laufen in Containern, ich kann also mit Sicherheit sagen, es ist immer wieder ein frischer Ausgangszustand, der hier hergestellt wird. Es gibt Manifeste, die beschreiben, wie Sachen installiert werden, also die Konfiguration ist größer als

das tatsächliche Deployment, die hat Vorrang und es gibt so ein bisschen, es gibt einem so ein bisschen Sicherheit bei der Ausführung. Allerdings, zumindest für Travis würde ich sagen, kann man nur einfache Tests beschreiben. Komplizierte Testabläufe sind schwierig, wie man die voneinander abhängig macht, ist unklar.

GitLab CI gefällt mir sehr gut, hat auch den Vorteil, dass man es selber hosten kann und das nicht irgendwo in der Cloud ist oder gar teuer, wenn man keine Open Source Software schreibt. Aber auch hier also Bild-Artefakte aus einem Test in einen anderen bringen, ist irgendwie schwierig.

Und was mir sehr gut gefällt, ist, dass Travis und GitLab CI diese Services haben, also dass man im Manifest sagen kann, dieser Test braucht einen Postresquell-Server und dann wird er für mich bereitgestellt von der Testumgebung, finde ich sehr gut. Concourse, zeige ich hier einfach mal das

Dashboard von Concourse. Hier links sind alle Projekte aufgelistet, die haben so Start-Stop-Buttons dazu, damit kann man sie anhalten. Hier oben ist eine Gruppierung, das ist erst mal nicht so wichtig und hier in der Mitte sehen wir diese ganzen Boxen, das sind Jobs, die laufen,

also dieser gelbe Rahmen bedeutet, die laufen gerade und die kleinen hier, das sind Ressourcen, die in diese Jobs Eingang finden. Das nur so als Übersicht, später mehr dazu. Und dann ein großartiges Feature von Concourse, das man direkt am Anfang eigentlich nennen muss, ist die Ausgabe von farbigen Log-Dateien.

Also man muss sich nicht länger aus der CI die Log-Files herunterladen, um die dann irgendwie in less irgendwie mit minus R oder sowas in Farbe sehen zu dürfen, sondern direkt in der Lab-Oberfläche ist zum Beispiel farbige Ausgabe möglich. Aha, ja und Concourse ist komplett deskriptiv,

also alles kommt irgendwo aus GitHub-Repositories und diese Manifeste, hier zum Beispiel so ein kleines Beispielmanifest, beschreiben eigentlich alles, was notwendig ist. Das ist ein YAML-Manifest, mit YAML hat man sehr viel zu tun bei Concourse. Alle externen Abhängigkeiten sind hier

als Ressourcen aufgelistet und normalerweise hat man also irgendwo in seinem GitHub-Repository einen Unterordner CI und da wird auch das Manifest abgelegt. Die Credentials sind dann in einer externen Datei, die kann man irgendwo sicher vorhalten und werden sozusagen als Variablen hier in das Manifest reingeladen. Setup dieser Manifeste macht man nur über

das Command-Line-Interface. Können wir die Helligkeit des Beamers regeln? Na gut, okay, also ist auch egal, es ist so ein Command-Line-Interface, hier sehen wir zum Beispiel die Builds, die gerade laufen, die roten Builds hier, die sind

fehlgeschlagen und darüber setzt man sozusagen die Manifeste, also man kann sich einfach ein Shell-Script schreiben und wenn man auf einen neuen Concourse- Server umzieht, führt man das Shell-Script aus, alle Pipelines werden wieder hergestellt, Zustand ist erreicht. Concourse hat keinen State. Man kann die CLI auch benutzen, um zuzuschauen,

wie ein Test gerade läuft, also man kriegt den Bild-Output auf die Konsole, man muss nicht die Web-Oberfläche benutzen und eins der interessantesten Features ist, dass man sich an laufende Container anhängen kann und dann sozusagen auch eingreifen kann, nochmal vielleicht ein paar Zeilen code

modifizieren, den Test im Container nochmal starten. Ich habe viel über Pipelines geredet, das hier wäre jetzt mal so eine Pipeline, diese Pipeline hier benutzen wir, um Open-Stack- Installationen zu validieren, ob sie für den Einsatz mit Cloud Foundry geeignet sind, also da müssen so der

Blob-Storage muss aufgesetzt sein und es gibt da so Bedingungen und hier oben geht sozusagen der Source Code ein, wenn der sich ändert, fängt diese Box hier an irgendwie den Test, den Unit-Test auszuführen, hier ist ein Zeit-Trigger als externe Ressource und wenn das hier erfolgreich ist, dann geht

das also in einen Task, der Validate heißt und dann tatsächlich den Validator auf einen Open-Stack, das hier für den Test benutzt wird, ausführt. Hier unten dieser Clean-Up- Job ist halt notwendig, um das Open-Stack wieder aufzuräumen fürs nächste Mal und falls das alles

geklappt hat, gibt es einen Release- Job, der dann also tatsächlich hier die Versionsnummer erhöht, Versionsnummern sind auch externe Ressourcen und ich vermute, das ist eine Webseite. Interessant sind hier die gepunkteten Linien, das heißt dieser Job hier hat keine direkte Abhängigkeit, der wird nicht getriggert, den muss man manuell auslösen, also nicht jedes

Mal, wenn die Validierung gelingt und eine neue Version da ist, wollen wir natürlich ein Release erstellen, sondern so eine manuelle Komponente kann man hier reingehen, plus drücken und dann wird ein Release erstellt. Die Job-Ansicht, das ist

also jetzt ein einzelner Task, also eine einzelne Box, die wir vorhin gesehen haben, hat hier oben alle Builds gelistet, also hier sind wir schon bei Build 5600, rote Builds sind fehl geschlagen, grüne Builds erfolgreich und ich glaube die Orangenen hier sind abgebrochen und hier kann man jetzt halt aufklappen, die Ressource-Konkurs zum Beispiel,

hier sieht man die Git-Commit-Message, die hier eingegangen ist, ist eine durchgezogene solide Linie, das heißt die hat den Bild getriggert, die hat sich zuletzt geändert und hier sieht man halt die ganzen anderen Tasks, die ganzen anderen Schritte des Bildplans und die könnte man jetzt auch aufklappen und würde sozusagen den Konsolen-Output sehen, den sie generiert haben und die Kernkonzepte

von Konkurs sind Jobs, Tasks und Ressourcen. Die Tasks werden komplett in Containern ausgeführt, das heißt die sind lediglich Skripte, die werden aus einer Git-Ressource

geladen üblicherweise und haben Inputs und Outputs, wie hier gerade in der Pipeline, also dieser Validate hier zum Beispiel hat hier die beiden als Input und diese Ressourcen werden einfach wie Verzeichnisse gemountet und dann sind die für die Skripte als Verzeichnisse sichtbar

und man kann da Dateien einfach rauslesen und reinschreiben. Also Ressourcen sind eigentlich, wenn sie ausgeführt wurden für den Task, nur noch Verzeichnisse. Diese Task-Container, die hier aufgemacht werden, verschwinden nicht einfach, sondern man kann sich also eine gewisse Zeit lang auch noch wie mit Docker-Attach oder sowas an den Container

dranhängen für eine Nachbereitung, um Debug-Informationen rauszuholen oder sowas. Ressourcen selber sind auch wieder nur Container und Concourse kennt zahlreiche Ressourcen, die sind alle gleich, also es ist keine Plugin-Architektur, sondern es sind immer drei Skripte, ein In-Skript, ein Out-Skript und ein Check-Skript, also

Check sagt, es ist eine neue Version da bei GitHub zum Beispiel, es hat sich irgendwas geändert an dem Commit-Shar, der ist sozusagen neu. Das In-Skript downloadet die Ressource in ein Verzeichnis und das Out-Skript würde bei GitHub zum Beispiel ein Commit machen und ja, das

alles ist JSON, also wie auch immer man dieses Skripte schreibt, ob in der Bash oder in Go oder sowas, wichtig ist nur, dass JSON kommt rein, JSON kommt raus. Wir haben zum Beispiel bei Suze, braucht man eine Ressource, um den Open-Build-Service zu überwachen, wir haben, da werden die RPMs gebaut und man will sozusagen,

wenn es jetzt ein neues RPM gibt von irgendeiner Software, möchte man zum Beispiel Tests fahren, das Check-Skript guckt dann, ob in Open-Build-Service irgendwie ein neuer Commit auftaucht und wenn ja, wird das RPM geholt und getestet. Also alle Ressourcen sind extern, nichts davon ist auf dem Concourse-Server, das wird immer gedownloadet, wenn die Pipeline läuft. Es war nicht schwer diese

individuelle Ressource zu bauen. Ja, also so viel dazu, bei Concourse kein lokaler State, alles ist extern und wir benutzen hier die skriptive Manifeste, das ist alles reproduzierbar, wenn man das mitnehmen

will auf den Laptop oder sowas, das kann man einfach machen, so lange sichergestellt ist, dass man natürlich die Zugriffsrechte auf die Ressourcen hat. Also toll, viele Container und wie installieren wir das jetzt? Es gibt verschiedene Wege zu installieren, falls man irgendwo

eine Cloud hat, auf seinem eigenen OpenStack oder Google Cloud Plattform oder sowas und man hat schon einen Bosch Director, passiert jetzt wahrscheinlich nicht so vielen, dann kann man es einfach als Bosch Release deployen, das ist aufgrund der Historie der Software auch sozusagen der native Weg, um Concourse zu

bekommen. Bosch ist sehr viel leichter geworden im letzten Jahr, würde ich sagen, also es sind nur noch zwei, drei Befehle, bis man so einen Bosch Director hat, bis man den für seine Cloud aufgesetzt hat mit den Security-Regeln und so, es ein bisschen involvierter, aber auch da gibt es viele Vereinfachungen. Ganz neu ist Concourse Lite, zum Beispiel, wenn man auf seinem Laptop

einen Concourse haben will, in VirtualBox. Standalone ist genauso möglich, sind nur ein paar Dienste und ich glaube es gibt auch irgendwas mit Docker, ich weiß nur nicht, ob das aktualisiert wird, ob das von der Community ist oder offiziell. Hier ist der Concourse Lite Weg, wenn man diese Bosch Command Line Interface Software hat, kann man sozusagen einfach das

Manifest downloaden von Concourse, Create, Env aufrufen und dann downloadet ihr den Release, startet eine VM und man hat einen Concourse im VirtualBox laufen, kann sich einfach einloggen auf der Konsole und unter der URL ist dann das Web Interface. Bessere Installationsanleitungen gibt es auf der richtigen Webseite. Standalone, falls man selber aufsetzen

möchte, ist auch unterstützt und auch dokumentiert, im Wesentlichen war auch mal Post, SQL, Redis und Docker, das ist also auch keine schwierigen Abhängigkeiten, da werden mehrere Dienste gestartet und hier zeigt sich auch schon, dass Concourse aus so einer Welt kommt, wo diese ganzen Begriffe vom Flughafen kommen,

also da gibt es den Web.UI Scheduler, der heißt natürlich Air Traffic Control, dann gibt es die Workerverwaltung, also die Jobs an Worker zuweist, es gibt ja Concourse Installationen, die haben irgendwie einen Dutzend Worker, es gibt Concourse Installationen in VirtualBox, die haben natürlich nur einen Worker. Also TSA, Transportation Security und dann

gibt es halt die tatsächlichen Worker. Verbunden sind diese Demons über SSH, also das heißt, man kann sie auch verteilen, man kann zum Beispiel jeder Cloud einen Worker haben oder wenn man mehrere Standorte hat, kriegt jeder Standort seine Worker. Man kann dann sozusagen die Tests taggen, so dass sie nur auf bestimmten Workern laufen. Ja, ich habe viel über

Manifeste geredet, ich würde jetzt nochmal im Detail auf Manifeste eingehen wollen. Ich habe dafür so ein Schema angelegt, das hier und hier haben wir halt wieder diese Pipelines, Pipelines haben

Ressourcen. Ich kann natürlich Ressource wiederverwenden in verschiedenen Pipelines, also streng genommen können wir auch hier sagen, ganz ehrlich. Und in einer Pipeline sind mehrere Jobs, das sind diese Kästen, die wir vorhin gesehen haben in der Pipeline Darstellung und jeder Job hat einen Bildplan. Dieser Bildplan besteht im Wesentlichen aus Schritten, die

Get, Put oder Task sind, also entweder Ressourcen holen, Ressourcen irgendwo hinschreiben oder einen Task ausführen. Und hier also Ressourcen gibt es zum Beispiel S3, Git, R-Sync, Time-Ressource, haben wir alles schon gesehen. Jobs werden getriggert, wenn Ressourcen

sich ändern und die Schritte im Bildplan werden erstmal sequenziell ausgeführt. Also da kann man sich darauf verlassen, dass wenigstens die der Reihe nach laufen. Task läuft nicht wirklich in Docker, in Wirklichkeit wird RunCy verwendet, was so eine Art Embedded-Docker ist, aber am Ende sind es Linux-Container.

Und hier wäre noch so ein kleineres Beispiel, um diese Time-Ressource zu zeigen. Die hat jetzt hier den Namen 1M und als Intervall eine Minute. Also jede Minute gibt es eine neue Version von dieser Ressource. Und ja, ich hoffe, ich

kann da jetzt scrollen, ne, kann ich nicht. Und der erste Job hat hier, also der holt diese Ressource und hat dies annotiert mit Trigger True. Also wenn die sich geändert hat, so wenn

die sich geändert hat, dann wird der Task ausgelöst. Und dieser Beispiel- Task hier holt ein Docker-Image von Docker-Hub zum Beispiel. Curl wird jetzt hier nicht gebraucht, aber das ist einfach ein sehr kleines Docker-Image und würde hier einfach den Befehl ls ausfüllen mit einem Argument. Also ein ziemlich sinnlose Pipeline, die

einfach nur ls ausführt jede Minute, aber mehr gehört eigentlich nicht in Manifest. Kannst du dich jetzt vorstellen, wenn man größere Pipelines hat, wird das schlimmer. Zum Beispiel diese Benchmark-Pipeline hier, die auch hier, also irgendwas von Git holt, aber

auch nicht automatisch losläuft, hier wieder keine durchgezogenen Linien. Hier die Benchmark ausführt und das dann irgendwie wegspeichert in irgendeinen Store. Das Docker-Image hier, das zum Benchmarken verwendet wird, wird durch diesen Job hier gebaut, also sodass auch das Docker-File, um das Docker-Image zu erstellen, natürlich irgendwo in den Assets zu dieser

Pipeline gespeichert werden muss. Und das wird dann hier unter, weiß ich nicht, Forenics oder sowas auf Docker Hub abgelegt. So, das Manifest dazu sieht so aus, dass erst mal hier ein Ressourcetyp neu definiert wird. Also die Ressourcen, die nicht Teil von

Cloud, von Concourse sind, muss man sich von extern reinholen. Also hier ist sozusagen die Ressource einfach nur wieder ein weiteres Docker-Image. Das legt man vorher da ab und um die R-Sync-Ressource zu benutzen, wird erst mal das Docker-Image gedownloaded, das weiß, wie man R-Sync

macht. Und dann gibt es hier die Git-Ressource, ganz klar Branch, alle fünf Minuten wird die gecheckt. Ich versuche wieder runter zu scrollen.

Das Docker-Image hier, das war die Box rechts, also wenn ein neues Image erstellt, wird es hier in diesem Repository abgelegt. Diese geschweiften Klammern sind variablen, die man auf der Kommandozeile von außen reingeben kann. Da könnte man zum

Beispiel, was auch immer man benutzt, um Passwörter sicher abzulegen, LastPass reinpipen oder irgendwas mit GPG oder so weiter. Und hier ist dann tatsächlich die Konfiguration für die R-Sync-Ressource, die dann sagt, auf diesem Server die Daten ablegen.

Das mit dem scrollen habe ich mir besser vorgestellt. Hier der Task, der das Docker-Image baut und hier tatsächlich der Benchmark. Der Benchmark läuft als root, der läuft privileged. Das muss man hier in das

äußere Pipeline-Manifest schreiben. Es gibt auch ein Task-Manifest, das ist dieses hier. Man darf es nicht in das innere Task-Manifest schreiben, weil man die wieder verwenden möchte und sozusagen sich hier schützen möchte, dass man von irgendwo ein Task-Manifest importiert, das dann privileged läuft. Deshalb muss es draußen sein. An Task können wir

Parameter übergeben, auch hier wieder geschweifte Klammern, also beim Deployment der Pipeline, beim Setup der Pipeline sozusagen steuerbar. Über den Bildplan habe ich geredet, dass es dieser Teil hier des

Manifests, wo das Get steht und dann der Task ausgeführt wird. Wenn ich jetzt nach unten scrollen könnte, würdet ihr sehen, dass unten ein Out kommt im Bildplan, das die

Klammern wegspeichert. Na ja, glaubt mir das einfach. In dem Out könnte auch stehen Aggregate, das heißt, diese Schritte werden gleichzeitig ausgeführt, wenn man zum Beispiel drei GitHub-Repositories klont. Es hat keinen Sinn, darauf zu warten, dass eins fertig ist, bevor man mit dem

nächsten anfängt. Und wenn man Aggregate schon macht, kann man in Aggregate auch noch Do benutzen, um wieder sequenziell zu werden für größere Pipelines. Ja, das ist das Task-Yammel, von dem ich gerade geredet habe. Also auch hier wird wieder das Docker-Image angegeben, in dem der Task ausgeführt wird.

Das ist jetzt genau das Docker-Image, das die Pipeline vorher gebaut hat. Hier wird der Input, dieses Git-Repository als Input gemountet. Out gab es vorher nicht. Das wird einfach ein leeres Verzeichnis, was wir da reinschreiben, kann anschließend von der Ersync-Ressource weggespeichert werden. Tja, hab ich jetzt schwarz

geschaltet. Okay, ich geb das jetzt auf mit dem Scrollen. Das hier wäre dann so ein Skript, das tatsächlich also in dem Task-Yammel unten unter Rand steht, wo wir vorher LS gesehen haben. Und das setzt einfach diese Phonics- Benchmark-Suite auf und führt die dann aus. Ja, interessant an

den Jobs ist, dass diese Jobs keine Reihenfolge haben. Die laufen eben nicht der Reihe nach oder sowas. Diese ganzen Boxen sind also nicht wie jetzt bei anderen CIs miteinander verknüpft in einer bestimmten Reihenfolge. Das muss ich

sozusagen selber herstellen, wenn ich sowas möchte, sondern die laufen einfach, wenn Ressourcen sich ändern. Und dann eine von denen wird schon starten. Ich kann aber Ressourcen in eine Serial-Group packen, dann läuft aus dieser seriellen Gruppe nur eine gleichzeitig. Zum Beispiel, wenn die dieselbe Infrastruktur benutzen, wenn ich jetzt nur eine OpenStack Installation habe oder irgendwas nur einmal habe, dann kann ich

halt sicherstellen, dass es auch nur einmal gleichzeitig benutzt wird. Und ich kann auch sagen, wenn ich zwei neue Versionen habe, dann möchte ich den Task natürlich wird er dann auch zweimal ausgeführt, der Job. Also jede Version wird getestet. Aber ich kann hier sicherstellen, dass das nicht gleichzeitig passiert, sondern dass das sozusagen in eine Warteschlange kommt und dann zum

Schluss abgehandelt wird, wenn der erste durchgelaufen ist. Ja, also Ressourcen, ich finde dieses Zitat ganz wichtig, sind eigentlich der Weg, wie Artefakte durch diese Pipelines bewegt werden. Und die Einfolge, in der das passiert, wird halt durch die Abhängigkeiten

festgelegt. Ich würde sagen, ist nicht deterministisch in der Praxis. Also, ja, aber auch hier, also haben wir gerade in dem Manifest gesehen, es gibt Trigger an alle Ressourcen, an die wir Trigger schreiben. Und da stellen wir sicher, dass das Ressourcen sind, die den Job ausführen und passt.

Damit können wir also so Filter machen. Also der nächste Job wird nur ausgeführt, wenn es eine erfolgreich getestete Version der vorigen Ressource gibt. Wie man sich jetzt vorstellen kann, werden diese Pipelines ziemlich groß. Das hier ist jetzt von dem CF OpenStack

Validator, wo wir anfangs das Manifest gesehen haben. Das GIT Repository, der CI Ordner. Hier oben CI Pipeline Jaml, das hat sich so etabliert als Name für die Hauptpipeline. Und dann folgen die ganzen Assets. Hier ist ein Task- verzeichnis mit den ganzen Skripten. Und hier unten sind dann weitere Skripte, die in den

Shell-Skripten oder die die Shell-Skripte ersetzen und dafür sorgen, dass z.B. Infrastruktur aufgebaut wird oder Dokumentation veröffentlicht oder so. Alles auf GitHub und damit auch wiederverwendbar zwischen verschiedenen Installationen von Concourse. So sieht eine große

Pipeline aus. In der Auflösung jetzt leider nicht ganz erkennbar. Diese Pipeline baut Betriebssystem-Images und testet die anschließend. Ja, wir haben also auf der

Arbeit tatsächlich so viele Pipelines und so viele Tests, dass wir ein eigenes Team dafür haben, diese Pipeline zu verbessern. Also ab und zu kommt das in die Rotation rein, dass man die Pipeline Skripte verbessern muss. Und wir haben auch ein Label, dass wir täglich vergeben für das Team, das sich darum kümmern muss, dass diese Pipelines grün bleiben. Einfach auf der Komplexität und der

Abhängigkeit von der darunterliegenden Infrastruktur muss immer mal wieder was aufgeräumt werden. Ich zeige jetzt nicht noch eine Demo. Ich würde sagen, es ist spät genug. Schönen Dank. Und falls ihr Fragen habt, wäre jetzt der richtige Zeitpunkt. Ja, bitte.

Also ich weiß, Mac und Windows, Concourse unter Mac und Windows laufen lassen. Hab das selber noch

probiert. Die Virtual Box läuft natürlich. Versionen von Concourse läuft natürlich unter beiden. Und ich weiß, dass es Worker gibt. Also ich weiß, dass es Windows Worker und Mac Worker gibt. Also wenn ich Windows Software testen will, kann ich das auf dem Windows Worker. Das

letzte Mal, wo ich das gesehen habe vor ein paar Monaten, war das allerdings mit Einschränkungen versehen. Ich glaube, weil Windows keine Container kennt, muss man das öfters rücksetzen. Das war also sozusagen Vm, die gesnapshotted war und irgendwann ist die sozusagen zugemüllt, weil die Container halt fehlen, um da den State wieder

sauber zu machen. Ich denke, das wird sich bald ändern. Und ich glaube, auch moderne Windows Versionen können Container oder die nächste soll oder so. Ja, dann danke ich

schön und einen schönen Sonntagabend.