In dieser Episode des Podcasts diskutieren die Gastgeber Alex Lichtenberger und Dierk Söllner mit dem Gast Matthias Zieger von Xebia Labs ausführlich über das Periodensystem der DevOps-Tools. Sie erörtern die Entstehung und Bedeutung des Systems, seine Struktur, und wie es die Auswahl und den Einsatz verschiedener DevOps-Werkzeuge in der Softwareentwicklung vereinfacht und verbessert. Der Fokus liegt dabei auf der Integration der Tools in den Continuous Delivery Prozess und der Rolle der Automation, mit besonderer Berücksichtigung verschiedener Technologien und Plattformen.
Inhalt
- Einführung und Vorstellung der Teilnehmer
- Entstehungsgeschichte des Periodensystems der DevOps-Tools
- Struktur und Klassifizierung der Tools im System
- Bedeutung und Anwendung von Continuous Delivery
- Unterschiedliche DevOps-Tools und ihre Funktionen
- Herausforderungen und Lösungen im Bereich der Tool-Integration
- Wichtigkeit von Automatisierung und Effizienz in der Softwareentwicklung
- Community-Einfluss auf die Entwicklung des Periodensystems
Shownotes
- Xebia Labs Website: Xebia Labs
- Periodic Table of DevOps Tools: Periodensystem der DevOps-Tools
- Jenkins: Jenkins
- Git: Git
- Jira: Jira
- Microsoft Team Foundation Server (TFS): TFS
- Kubernetes: Kubernetes
- Mesos: Mesos
- OpenShift: OpenShift
- Artifactory: Artifactory
- Ansible: Ansible
Transkript (automatisiert, keine Gewähr 🙂 )
Hallo und herzlich willkommen zum zweiten Podcast, zur zweiten Folge des Podcasts. DevOps auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner und ich bin einer der beiden Gastgeber. Und der Alex wird sich auch gleich nochmal ganz kurz vorstellen.
Ja, die zweite Ausgabe, die zweite Folge, die wir hier an den Start bringen. Wir haben heute zu Gast den Matthias Zieger von Xebia Labs.
Auch der wird sich nachher noch vorstellen. Wir haben das Thema Periodic Table of DevOps Tools. Ein sehr interessantes Thema.
Wir freuen uns, dass wir den Matthias dabei haben. Hallo Matthias, mal ein herzliches Willkommen schon mal an der Stelle.
Danke.
Ja, zweite Folge. Wir haben bei der ersten Folge dazu aufgerufen, ein paar Rückmeldungen zu geben. Und wir haben uns gefreut, es gab ein paar Rückmeldungen.
Und eine Rückmeldung war bezüglich der Technik. Da kam die Rückmeldung, dass die Aufnahme ein bisschen nivellierter sein könnte, ein bisschen mehr Qualität rein.
Das machen wir schon. Das, denke ich, werdet ihr merken oder hören, dass wir ein bisschen an der Technik gearbeitet haben.
Und insofern da.
Ja, herzlichen Dank für die Rückmeldungen. Alex, dann übergebe ich mal an dich.
Ja, vielen Dank, Dirk. Herzlich willkommen auch von meiner Seite.
Ja, wir haben ja ursprünglich, haben wir angekündigt im letzten Podcast, dass wir heute das Value Stream Mapping machen.
Das hat sich jetzt verschoben, weil die Leute müssen natürlich immer auch verfügbar sein für ein Interview.
Das hat für das Value Stream Mapping nicht geklappt. Aber wir werden das dann, denke ich, im übernächsten Podcast werden wir das bringen.
Aber wir haben heute auch ein ganz spannendes Thema, die Periodic Table of DevOps von Xebia Labs.
Bevor ich da übergebe an den Matthias, ja, die meisten von euch kennen wahrscheinlich diese Periodic Table.
Und wenn wir über DevOps sprechen, egal über welches Thema, eigentlich ist es immer so People, Process, Tools.
Also im Falle von DevOps, People, wie setze ich eine DevOps-Kultur?
Durch die neue Art und Weise zusammenzuarbeiten. Dann Process, wie bringe ich ein Continuous Delivery auf die Reihe?
Und wenn es dann um die Tools, die Technologie geht, wie bringe ich das dann effektiv auf den Boden?
Da hat sich ein riesen Tool-Universum aufgetan.
Verschiedenste Tools rund um Cloud, Continuous Delivery, Artifactory etc.
Und da, als ich das erste Mal diese…
Diese Table gesehen habe, das ist eigentlich so dann so wie, weil die Leute sind ein bisschen dann verloren in diesem ganzen Tool-Universum.
Eigentlich eine wunderbare Sache. Das gefällt den Leuten sehr gut.
Deshalb denke ich, ist heute auch das heutige Thema sehr spannend für die Leute.
In diesem Sinne möchte ich gerne jetzt an den Matthias übergeben.
Vielleicht mal kurz, dass du dich als Person vorstellst, auch Xebia Labs und was ihr macht.
Ja, vielen Dank.
Vielen Dank für die Einführung.
Mein Name ist Matthias Zigger. Ich bin bei Xebia Labs in Deutschland für die Technik zuständig.
Das heißt, ich mache alles von Produkt-Demos über Messen bis hin zu POCs, Piloten und Produkteinführungen.
Ich mache das jetzt seit zweieinhalb Jahren für Xebia Labs, eine ganze Zeit auch mit einem Partner zusammen, mit der Co-Centric.
Mittlerweile hat Xebia Labs ein eigenes Team in Deutschland und wer Xebia Labs nicht kennt, wir kommen ursprünglich aus Holland.
Da ist auch immer noch unser Hauptsitz, unsere Entwickler.
Das sind so 70 Entwickler, die wir haben, die an den Produkten arbeiten.
Die sitzen alle in Holland, in der Nähe von Utrecht, in Hilversum.
Und wir sind mittlerweile weltweit vertreten, haben ein zweites Headquarter noch in Boston, hauptsächlich aus Gründen Venture Capital und so weiter.
Aber Technik ist alles in Europa, von daher passt das auch alles so weit.
Bevor ich bei Xebia Labs und Co-Centric das Thema gemacht habe, war ich bei Microsoft und habe da das Thema Team Foundation.
Server gemacht.
Da hieß das noch gar nicht DevOps, da hat man noch Application Lifecycle Management gesagt.
Aber eigentlich ging es immer darum, wie bekomme ich meine Produkte eigentlich schneller vom Entwickler bis in Produktion.
Das ist das, was mich so die letzten 10, 15 Jahre mittlerweile umtreibt.
Sehr schön.
Dann, Matthias, vielen Dank für die Vorstellung, für die Einführung.
Ich habe ja vorhin gesagt, wir haben Rückmeldungen bekommen.
Und eine Rückmeldung war auch zum Thema.
Was ist DevOps?
Und der Teilnehmer hat gesagt, dass er das sehr interessant fand.
Insofern, Frage an dich, Matthias.
Wie würdest du denn DevOps definieren?
Kann man das definieren?
Wie würdest du DevOps beschreiben?
Was ist DevOps für dich?
Ja, man kann es versuchen zu definieren.
Es gibt ganz unterschiedliche Definitionen.
Es gibt natürlich die Definition und der Alex hat es ja schon genannt.
Es gibt ja die drei Perspektiven immer.
People, Process, Technology.
Wenn wir mal bei People anfangen, ist das natürlich ein Thema.
DevOps.
Das ist ein Kulturwandel.
Ein Kunde hat mal zu mir gesagt, wir haben Silos of Excellence,
die wir jetzt aufbrechen müssen im Sinne von DevOps.
Das heißt, wir müssen unsere sehr arbeitsteilige Arbeitsweise,
die wir hatten, wo es Requirements-Spezialisten gab.
Dann gab es die vielleicht Architekten, Modellierer, Entwickler,
QA-Teams, Produktionsteams, die häufig noch mal unterschieden waren
nach Infrastrukturbetrieb und Anwendungsbetrieb und Monitoring.
Das müssen wir eigentlich aufbrechen.
Ja, und das ist die Kernidee von DevOps.
Daran erkennt man schon, dass der Name eigentlich ein bisschen zu kurz gegriffen ist.
Ich sage immer gerne amerikanisch vereinfacht.
DevOps, ja, aber eigentlich müsste es bis Dev QA Security Ops irgendwie heißen.
Ja, so in der Richtung ist aber viel zu umständlich.
Deswegen hat sich DevOps eigentlich eingebürgert.
Aber im Kern geht es eigentlich darum, eine bessere Zusammenarbeit
der verschiedenen Spezialisten, die man hat, zu erreichen in sogenannten
cross-funktionalen Teams.
Das ist, glaube ich, der Kern von DevOps auf der People-Seite,
dass man diese, ja, ich bleibe bei dem Begriff Silos of Excellence einfach aufbricht
und sagt, wir gehen da hinüber, dass wir alle zusammen an einem Produkt
oder einem Problem arbeiten und nicht in so einer Fließbandartigen Geschichte
an dem Thema arbeiten, sondern eher in Gruppen daran zusammenarbeiten.
Das ist so das People-Thema.
Dann haben wir natürlich das Process-Thema.
Das ist dann noch ein bisschen größer und das
geht auch sehr stark dann in den kulturellen Wandel natürlich an den Kern der Unternehmen tatsächlich ran.
Und da ist natürlich das Thema, das geht deutlich über Technik und Technikabteilung auch hinaus.
Also da reden wir dann darüber, dass auch Unternehmen eine andere Art des Controllings
und der Steuerung eigentlich machen müssen.
Also deutlich mehr als ja, wir führen jetzt mal ein paar Tools ein und dann wird das schon gut werden.
Ja, das wird so nicht funktionieren.
Und das sagen wir auch als Toolhersteller natürlich.
Unseren Kunden, dass das so nicht funktionieren kann, wenn man das quasi vernachlässigt am Ende.
Und dann kommen wir ins Spiel.
Geht natürlich auch um Technologie, es geht um Werkzeuge, es geht um Automatisierung.
DevOps als manueller Prozess, glaube ich, kann nicht funktionieren.
DevOps hat als technischen Fokus den Anspruch Automate Everything, also alles zu automatisieren.
Das ist der Anspruch, den wir auch haben.
Beim Kunden kann man dem immer zu 100 Prozent erfüllen, wahrscheinlich nicht.
Aber man sollte das Ziel haben, möglichst weit zu kommen beim Automatismus
und möglichst wenig manuelle Geschichten zu haben.
Das ist so für mich das Thema DevOps.
Verschiedene Perspektiven.
Wir sind jetzt kein Beratungshaus.
CBA Labs ist ein Produkthaus.
Das heißt, wir kümmern uns rein um das Thema Technology.
Wir haben aber Partner an der Hand, wie eine Cozentrik, wie eine Direktgruppe, wie eine M-Vice,
ein paar andere noch, die sich um das Thema People and Process auch kümmern.
Ist jetzt nicht unser Fokus.
Aber wir sagen, das muss eigentlich sein.
Das muss eigentlich vorher geklärt sein, bevor wir mit unserer Technologie dann ins Spiel kommen.
Gut, vielen Dank.
Sehr gute Definition, finde ich.
Auch sehr schön, dass ihr als Produkthaus das schlussendlich holistisch seht.
Also nicht nur Technologie, sondern auch Prozesse und Kultur.
Bevor wir zur eigentlichen Table, also zum Inhalt selber kommen,
wäre vielleicht noch spannend, wie ist das Ding eigentlich entstanden?
Genau, in Vorbereitung auf den Postcard musste ich auch erst mal nachschauen,
wie alt ist eigentlich dieses Periodic Table of DevOps Tools.
Und die erste Version, die wir davon rausgebracht haben, war im Jahr 2015.
Also es ist ungefähr zwei Jahre alt, kann man sagen.
Entstanden ist das deswegen, weil wir bei den Kunden immer wieder die Diskussion geführt haben,
wir reden über, am Ende des Tages reden wir über Toolchains und Werkzeugketten mit den Kunden.
Und dann kam immer wieder die Diskussion, welche Bestandteile muss so eine Werkzeugkette haben?
Welche Prozessschritte sind darin überhaupt notwendig?
Und was sind so die typischen Vertreter, die wir in so einer Werkzeugkette halt sehen,
auch bei anderen Kunden am Markt?
Und dann hat sich unser Marketing überlegt, wie könnte man das eigentlich ganz gut visualisieren?
Und sind dann auf die glorreiche Idee gekommen, das so bei den Chemikern quasi sich zu holen.
Und dort das ja wohl,
bekannte Periodensystem der Elemente quasi zu adaptieren auf das Thema DevOps und Tools.
Und das ist so ein bisschen die Hintergrundgeschichte.
Mittlerweile ist online die zweite Version verfügbar von dem System.
Das heißt, das wird auch ständig abgedatet.
Da kann man aber nachher noch mal kurz drüber sprechen, welche Möglichkeiten es da gibt.
Und wir arbeiten gerade an der dritten Version davon.
Das heißt, das lebt auch so ein bisschen über die Zeit.
Das ist vielleicht der größte Unterschied zum Chemiker.
Ja, genau.
Also, das ist ein bisschen wie in einem chemischen Periodensystem, wo ja Naturgesetze quasi abgebildet sind.
So weit sind wir, glaube ich, in der IT noch nicht, dass wir über Naturgesetze reden.
Aber ja, die Idee ist einfach griffig, weil viele Leute damit ganz gut zurechtkommen.
Und vielleicht als Info mal, wir haben durchaus sechsstellige Downloadzahlen aus dem Internet für das PDF
und verteilen auch jedes Jahr so ein paar Tausend dann noch auf Messen und Konferenzen
in einem Format quasi als Poster.
Das vielleicht mal so als Info für die Zuhörer auch, dass ganz gut verbreitet ist, das Periodensystem.
Spannend.
Jetzt kommen wir, ist ein guter Zeitpunkt, mal auf den Inhalt zu kommen.
Mal gleich einen Versuch zu machen, die, also einerseits die Struktur der Periodic Table,
aber auch den ganzen Inhalt, das mal uns näher zu bringen.
Matthias.
Genau.
Also die Table, für die, die sie jetzt nicht vor sich haben, ist tatsächlich angelehnt an das Periodensystem der Elemente.
Das heißt, wir haben eigentlich eine Matrix.
Diese Matrix hat verschiedene Säulen, die quasi durch Farben repräsentiert sind.
Und diese Farben sind eigentlich dann die Prozessschritte, die man im Continuous Delivery quasi dann finden kann.
Das heißt, fängt ganz vorne dann an mit dem Thema Versionierung und Repositories,
geht dann über CI-Werkzeuge, also Continuous Integration, quasi auch die Grundvoraussetzung,
dass ich überhaupt etwas automatisieren kann, dass ich automatisierte Bills habe.
Geht dann über Artefakt-Repositories, wo dann meine gebauten Binär-Artefakte quasi reinfließen.
Oder wenn man eher moderner unterwegs ist, seine Container-Images auch dann liegen können.
Über Testing-Tools bis zu Deployment-Werkzeugen, Release-Werkzeugen.
Und am Ende haben wir natürlich dann das ganze Thema Orchestrierungs-Werkzeuge dann für Container.
Also sowas wie Kubernetes, Mesos, OpenShift.
Und ganz rechts findet man das, worauf alles dann aufbaut, quasi Infrastruktur-Themen.
Das sind die Sachen, über die auch die Continuous Delivery Lehrbücher, sage ich mal, sprechen.
Wir haben uns dann dafür entschlossen, unter dem Periodic Table nochmal einen separaten Absatz zu machen.
Für ergänzende Tools, die normalerweise in den Continuous Delivery und DevOps Lehrbüchern gar nicht auftauchen.
Das sind dann eher Collaboration-Werkzeuge.
Also da taucht dann sowas auf wie agile Planungs-Werkzeuge.
Also sowas wie ein Jira zum Beispiel oder ein Rally oder ein Version 1.
Dann gehören natürlich heute auch Chat-Werkzeuge dazu.
Also da taucht dann sowas auf wie ein Slack oder ein HipChat von Atlassian dann auch.
Bis hin zu sehr speziellen Werkzeugen, die das Thema Security,
Adressieren, die dann quasi so eine Querschnittsfunktion haben.
Die haben wir separat, so ein bisschen auch räumlich separiert von den anderen Themen,
weil sie ursächlich natürlich nichts mit Continuous Delivery oder DevOps zu tun haben,
aber aus unserer Sicht eine gute Ergänzung sind.
Das ist quasi die Abbildung des Prozesses.
Und das eignet sich eigentlich sehr gut, beim Kunden darüber zu reden,
welche Prozessschritte hat er überhaupt in seinem Unternehmen,
weil wir natürlich auch bei Kunden sind, die zum Beispiel sagen, wir sind Software-Lieferant,
wir haben gar nicht den Betrieb, weil den macht der Endkunde am Ende des Tages mit der Software,
die dann von einem Softwarehersteller zum Beispiel ausgeliefert wird.
Oder man hat vielleicht Kunden, die sagen, ja, wir wissen, dass Testautomation wichtig ist,
aber wir haben noch nicht da rein investiert.
Das heißt, wir haben da so einen kleinen Spot, so ein bisschen an der Stelle.
Und das sind so die Themen, wo man eigentlich sehr gut mit dem Kunden erstmal auf einer Prozessebene sprechen kann,
indem man sich anhand der Farben langhangelt und mit dem Kunden spricht und sagt,
was ist so dein Gefühl dafür, wo bist du gut aufgestellt, wo geht es so einigermaßen
und wo siehst du noch Verbesserungspotenzial.
Also eine reine Prozessbetrachtung.
Dabei helfen quasi die Farben dieses Periodensystems einfach sehr gut,
weil man wirklich die Prozesse als Säulen dann hat.
Und das Zweite ist dann, in den Säulen hat man natürlich dann die einzelnen Werkzeuge.
Also ich sage mal, beim Thema Versionskontrolle haben wir eine relativ große Bandbreite abgebildet.
Von Git-basierten Systemen, von Git-Pur über Bitbucket vielleicht, GitHub.
Aber auch noch Subversion natürlich drin, weil es immer noch Kunden gibt,
die auch eher auf älteren Systemen natürlich unterwegs sind
und noch nicht jeder auf die neueste Technologie an der Stelle gesetzt hat.
Und unsere Strategie ist eigentlich so, dass wir in jeder Säule die Tools abgebildet haben,
die wir bei unseren Kunden, und das ist die wichtige Aussage bei unseren Kunden,
als führende Tools dann in den jeweiligen Bereichen halt sehen.
Und das ist dann eine bunte Mischung aus Open-Source-Tools,
wenn wir jetzt mal beim Code-Repository bleiben, Open-Source-Werkzeuge wie Git zum Beispiel,
bis hin zu kommerziellen Werkzeugen, vom Schlager eines Bitbucket dann oder auch eines GitHub Enterprise.
Also es ist immer eine bunte Mischung aus Open-Source-Werkzeugen und kommerziellen Werkzeugen
und deckt so ein bisschen die Realität ab, die wir beim Kunden halt sehen.
Und das erhebt natürlich keinerlei Anspruch auf absolute Vollständigkeit.
Das geht gar nicht, wenn man sich allein mal das Thema Testen anschaut.
Da hat man natürlich, wenn ich mit dem Java-Entwickler rede,
Unit testen ist die Antwort relativ einfach, machen wir mit JUnit.
Aber wenn ich schon auf das Thema Oberflächen gehe, dann kommt schon sehr stark natürlich rein in Unterscheidung.
Der eine sagt, er nimmt Selenium,
der andere sagt, er testet Oberflächen.
Wenn ich zum Beispiel native Applikationen auf mobilen Geräten testen will,
brauche ich ganz andere Testwerkzeuge.
Also beim Testen ist es dann auch nicht mehr so einfach, einen Marktführer zum Beispiel dann rauszufinden,
weil das einfach auch technologieabhängig ist.
Wenn ich auf einem Windows-Client eine Microsoft.net-Applikation testen will,
brauche ich ganz andere Werkzeuge.
Also da ist es dann auch nicht mehr so einfach.
Und ja, wir haben quasi uns Mühe gegeben,
das so best of the best quasi in diesem Periodensystem abzubilden,
aber keinen Anspruch auf Vollständigkeit.
Das merkt man auch immer wieder, wenn wir zum Beispiel mit Kunden reden,
die jetzt eher aus dem Embedded-Umfeld kommen.
Da findet man plötzlich ganz andere Werkzeuge natürlich,
die man so in der klassischen Business-Applikationswelt gar nicht findet.
Und da muss man ein bisschen aufpassen.
Es ist quasi eine repräsentative Darstellung des Marktes,
aber auch eine sehr verallgemeinernde Darstellung des Marktes.
Und kann natürlich nur eine geringe Auswahl an den tatsächlich vorhandenen Tools geben.
Aber es deckt so ein bisschen die Marktführerschaft quasi dann aus den einzelnen Bereichen dann quasi ab.
Das vielleicht dazu.
Wir haben dann die Tools noch klassifiziert so ein bisschen.
Das sind quasi die Sachen, die man im Periodensystem so als kleingedruckt auch findet.
Auch wieder angelehnt an das chemische Periodensystem.
Wir haben dann nochmal klassifiziert, welches Business-Modell steckt eigentlich.
Hinter dem Anbieter ist es rein Open Source oder ist es zum Beispiel ein Freemium-Model,
wie man es vielleicht bei Jenkins hat, wo ich sage, es gibt eine Open Source-Variante
und darauf aufbauend gibt es eine kommerzielle Variante.
Oder ist es ein rein kommerzielles Angebot, was man quasi da findet, wie es bei vielen Herstellern halt auch der Fall ist.
Mal als Beispiel bei den Atlassian Tools.
Das sind halt reine kommerzielle Werkzeuge halt dann.
Und das ist dann quasi, bildet das dann das Periodensystem.
Also zusammenfassend könnte man nochmal sagen, wir haben quasi die Säulen, die die Farben bilden.
Das ist eher der Prozessgedanke, über welche Schritte muss ich eigentlich nachdenken und wo muss ich mir etwas auswählen.
Und der zweite Gedanke ist dann quasi, welches Tool nehme ich eigentlich.
Und dann kommen wieder Berater ins Spiel oder der Kunde selbst, wo er dann quasi die Qual der Wahl hat, sage ich mal.
Weil er muss aus jeder Farbe sich ein Werkzeug natürlich aussuchen.
Um die Kette komplett zu haben.
Ja, also wir nutzen das auch sehr oft, um in die Diskussion zu gehen mit dem Kunden.
Das ist ein super Instrument dafür.
Und schlussendlich ist es wahrscheinlich eine Illusion, dass man ein Tool hat, das alles abdeckt.
Stattdessen will man eher eine Toolchain, das ist eigentlich wie ein Puzzle, das man zusammenfügen muss.
Und wenn halt, sage ich mal, ein Element fehlt, also man sieht das auch schön am Continuous Delivery.
Wo ein manueller Bruch drin ist, dann hat man kein Continuous Delivery.
Vielleicht noch kurz zur Auswahl.
Du hast ja selber gesagt, das Tool-Universum ist riesig.
Ihr müsst eine Selektion vornehmen.
Ihr habt das ein bisschen nach Bestenwissen und Gewissen.
Was sind so die grossen Player für die einzelnen Bereiche?
Gibt es da vielleicht auch die Möglichkeit, das als Community zu beeinflussen?
Was da auf dir, zum Beispiel in der nächsten Version, aufhört?
Was kommt auf die Table drauf?
Genau, das ist ein wichtiger Punkt.
Die Frage ist, warum sind jetzt gerade die Tools drauf, die drauf sind?
Also bei ein paar Sachen kommt man einfach nicht drum rum, glaube ich.
Dass da ein Git draufsteht, ist, glaube ich, unstrittig.
Und dass bei CI-Tools halt ein Jenkins drauf ist und ein Bamboo und vielleicht dann noch ein TeamCity.
Ja, das sind die drei Großen.
Aber die Frage ist, wer wird dann Nummer 4 und Nummer 5?
Und da haben wir eigentlich mehrere Methoden, wie wir das ermitteln.
Die erste Methode ist eigentlich die,
dass wir natürlich ein Voting-Mechanismus haben im Internet.
Das heißt, man kann quasi voten und sagen, da soll jetzt ein neues Tool drauf.
Das hat eine gewisse Relevanz, das brauchen wir.
Der zweite Kanal, den wir dafür nutzen, ist quasi der Kanal,
dass wir selbst eine sehr aktive Community auf GitHub haben.
Da gibt es eine XebiaLabs-Community-Seite, wo quasi die Plugins für unsere Tools dann drauf sind.
Und das beobachten wir auch sehr genau.
Was macht die Community? Welche Plugins werden da gefragt?
Welche steigen massiv an von den Download-Zahlen her?
Und wir monitoren das sehr genau.
Und das ist natürlich für uns auch ein Indikator dann.
Was soll dann als nächstes vielleicht auf dieses Periodensystem?
Was können wir dafür rausschmeißen?
Weil der Platz ist halt auch nur beschränkt.
Ja, wir können nicht alle Tools draufnehmen, sonst wird es zu unübersichtlich.
Und die dritte Methode ist natürlich die, wenn wir auf Konferenzen sind, auf Messen sind,
in die direkte Interaktion gehen mit den Kunden.
Das ist quasi der dritte Kanal, wo wir dann auch Feedback dazu bekommen und dann fragen,
welche Tools nutzt ihr? Was glaubt ihr, was nächstes Jahr bei euch im Haus eine Rolle spielt?
Und da kommt man auch ganz gut auf Ideen, was dann als nächstes quasi auf diesem Periodensystem dann drauf sein soll.
Ja, also Community kann hier wirklich aktiv mitmachen und kann uns Hinweise geben und sagen, da fehlt was
und da hätten wir gern noch was dazu gebaut.
Ja, super. Das macht das Ganze auch viel glaubwürdiger.
Also wenn das dann auch von der Community gefüttert wird.
Noch eine andere Frage, die in den Sinn gekommen ist.
Kann man daraus auch so eine Art wie Beispielkonfigurationen ableiten?
So im Sinne von Starterkit, billige Variante, Open Source, Enterprise?
Eher nicht. Also die Idee ist eigentlich nicht, dass man jetzt sagt,
okay, ich nehme jetzt, sag ich mal, aus jedem Bereich nur die Open Source Tools zum Beispiel
und lande dann bei, sag mal, so eine typische Pipeline wäre, wenn ich sage, ich darf nur Open Source Tools nehmen,
dann wäre es halt Git, Jenkins-freie Version plus vielleicht Deployment und Provisionierung dann mit Ansible
und das Ganze lasse ich dann auf einem Kubernetes zum Beispiel laufen, ja, als Laufzeitumgebung.
Und das kann man zwar machen, ja, und kann sagen, okay,
das ist quasi dann die Billigvariante, aber das trifft eigentlich nicht den Kern,
weil der Kern ist eigentlich, den Kunden zu fragen, welche Anforderungen hast du eigentlich?
Und dann kommt man sehr schnell drauf, dass man am Ende eine Mischung haben wird,
vielleicht aus Open Source Tools, aus kommerziellen Tools.
Wir sehen relativ wenig Kunden auch, die jetzt ihre Pipeline komplett nur mit Open Source haben
oder komplett nur mit kommerziellen Tools. Meistens ist es eine ganz gute Mischung.
Meistens ist es auch so, dass man bei größeren Kunden, sag ich mal,
bei Banken, Versicherungen, große Handelsunternehmen, Logistiker, mit denen wir halt sprechen,
auch gar nicht mit einer Continuous-Delivery-Pipeline am Ende des Tages auskommt,
sondern man hat vielleicht verschiedene. Also es gibt natürlich Themen in dieser Pipeline,
die sind technologieunabhängig. Ob ich jetzt in einem GitHub-Repository
Java-Code, Node.js oder .NET Sachen verwalte, ist eigentlich egal.
Beim Build-Server wird es dann schon ein bisschen anders, da ist es nicht mehr ganz so egal.
Weil da muss ich dann schon mal Cross-Plattform unterwegs sein.
Das heißt, der muss im Zweifel dann auf Linux laufen oder auf Windows,
wenn ich Windows-Applikationen baue, oder muss vielleicht andere Technologien unterstützen.
Und spätestens beim Thema Testen bin ich plattformabhängig.
Da habe ich Plattformabhängigkeiten, weil ich einen Browser testen muss, der auf Windows läuft,
weil ich einen Browser testen muss, der auf macOS läuft. Und ähnlich ist es eigentlich auch bei Provisionierungstools.
Weil die meisten Provisionierungstools natürlich dann auch Betriebssystemabhängigkeiten haben.
Das heißt, es ist schon ein Unterschied, ob ich einen Windows-Server provisionieren darf
oder ob ich ein Linux- oder Unix-System provisionieren muss. Das ist dann natürlich ein Unterschied.
Bei Container-Orchestrators ist es dann wieder ein bisschen einfacher.
Da bin ich dann doch zum großen Teil plattformunabhängig. Aber spätestens dann, wenn es dann wieder darum geht,
meine Firmenstrategie eigentlich alles im eigenen Rechenzentrum zu haben oder gehe ich in eine Public Cloud
und wenn ja, ist es dann nur eine oder vielleicht zwei. Ist es AWS oder Azure oder AWS und Azure und Google Cloud.
Dann bin ich plötzlich wieder beim Thema, welche Tools unterstützen das eigentlich?
Und dann wird es auch manchmal sehr schnell dünn. Und dann kommt man auch schnell auf den Punkt, wo man sagt,
vielleicht reicht auch nicht eine Toolchain, sondern du brauchst vielleicht unterschiedliche Toolchains pro Technologie.
Also deine Java-Entwickler kriegen einen anderen CD-Toolchain in einer gewissen Ausprägung wie deine Microsoft-Leute.
Und SAP ist nochmal ein ganz anderes Beispiel, wo ich dann über ganz andere Tools wieder rede.
Und dann kommt man wirklich sehr schnell dahin, dass man sagt, wir haben Gemeinsamkeiten wie zum Beispiel GitHub und Nexus Artifactory.
Technologieunabhängig kann ich alles damit machen.
Aber die restlichen Sachen sind dann nicht da.
Und vielleicht Stack-spezifisch auszuwählen. Das trifft eher die Realität eigentlich.
Und da muss man ins Detail gehen. Dann kommen wieder die Berater ins Spiel, beim Kunden dann solche Sachen quasi auszusuchen.
Genau, es ist dann eben doch nicht so einfach. Und schlussendlich, wie du gesagt hast, hat man ja verschiedene Toolchains, verschiedene Pipelines.
Da kann man ja, denke ich, noch schön den Link machen, dann so die Dimensionen, Prozesse und People,
was jetzt viele IT-Abteilungen machen. Sie richten ihre Teams entlang ihrer Produkte aus.
Also Cross-Functional Teams, die sich dann End-to-End, also von der Anforderung bis in die Inbetriebnahme um das Produkt kümmern.
Und je nach Produkt sind dann natürlich auch eigene Plattformen darunter oder eigene Tools.
Aber zum Teil gibt es natürlich auch übergreifende dann. Und da wäre vielleicht auch mal schön, jetzt mal so ganz praktisch,
das ist auch immer eine Frage, die ich bekomme, weil die Leute haben in der Regel ein gutes Verständnis.
Was heisst jetzt kulturell DevOps mit dieser neuen, sagen wir, die agile Philosophie, die grundsätzliche Agile Leadership, das reinkommt.
Dann Prozesse, sagen wir, der Continuous Integration Delivery Prozess. Und wie das jetzt ganz konkret, also so ein Beispiel End-to-End.
Also ich würde mal so, aus meiner Erfahrung, also der Traum ist vom Entwickler, es fängt immer aus,
alles an mit der Anforderung, also man hat beispielsweise User Stories, man formuliert Testfälle dazu und dann geht man hin,
man entwickelt, man checkt ein, es durchlaufend, das ist ja dann Continuous Delivery, man testet die automatisiert ablaufend,
so dass man eigentlich jederzeit könnte live gehen. Also Software is always in a releasable state.
Value Stream von Anfang bis Ende, da hat man so auch aus Kundensicht, also der Kunde will was und er bekommt das relativ schnell, das Feature.
Kann man da mal so ein Beispiel durchspielen? Ich habe es jetzt mal so prozessmässig erklärt.
Und wie würde das jetzt an beispielsweise Tools, wie würden die untendran entlang von dieser Pipeline interagieren? Ist das etwas, das du könntest?
Ja klar, weil das ist das, was wir quasi täglich machen, uns genau in solche Themen,
quasi rein zu integrieren. Wenn wir jetzt mal das Beispiel, was du genannt hattest, mal entlang gehen mit so ein paar typischen Tool-Vertretern,
dann würde quasi im Idealbild natürlich die Anforderung nicht irgendwie in Word oder in Excel gebaut werden,
sondern würde vielleicht in einem Tool wie Jira dann stehen. Das heißt, ich habe da meine User Stories, die vielleicht dann runtergebrochen sind,
die fangen oben an relativ grob in irgendwelchen Epics, dann User Stories und dann geht das immer weiter.
Nach unten auf beliebig viele Hierarchiestufen. Dann hattest du einen wichtigen Punkt gesagt.
Was machen wir eigentlich mit den Testfällen? Die sollten eigentlich direkt auf die Anforderungen gemappt sein.
Ich sage jetzt eigentlich, weil das bei vielen Kunden immer noch ein blinder Fleck so ein bisschen ist.
Wir wissen alle, wie die Idealwelt aussehen sollte. Ich habe meine Testfälle, die zu meinen Anforderungen gehören und die sind irgendwie verlinkt.
Die könnte ich zum Beispiel auch in einem Jira machen. Da gibt es Ergänzungen für Jira, dass ich da auch Testfälle verwalten kann.
Oder ich habe ein separates Test-Management-Tool. Da gibt es auch verschiedene von HP, von Micro Focus und so weiter, die da eine Rolle spielen.
Dann arbeiten natürlich meine Entwickler mit einer IDI. Das heißt, im Java-Umfeld sehen wir dann Eclipse oder auch andere Systeme, die da eine Rolle spielen.
Vielleicht IntelliJ, bei Microsoft dominierend natürlich Visual Studio, die da eine Rolle spielen.
Und da bauen dann die Entwickler ihren Code, haben vielleicht auch von da direkt Zugriff auf die Anforderungen, was nicht so ganz schlecht wäre, wenn sie ihre IDE nicht verlassen müssen, um auf Anforderungen zuzugreifen.
Und dann wird der Code quasi ständig gebaut und dann relativ kleinteilig, sage ich mal, auch eingecheckt dann in eine Versionskontrolle.
Das macht natürlich dann mit Git viel mehr Spaß als mit so althergebrachten Systemen wie vielleicht Subversion oder noch älter wie Clear Cases.
Oder Clear Quest, ja, von den älteren Zuhörern, die werden sich noch daran erinnern können.
Die jungen Leute wissen heute gar nicht mehr, wie gut sie es eigentlich haben, weil sie direkt mit Git eigentlich einsteigen können.
Da wäre natürlich auch die Idee, dass ich dann eine Traceability habe von meinen Anforderungen bis zum Code.
Das heißt, meine Anforderungen im Jira vielleicht sollten natürlich auch verbunden sein mit meinen Codefragmenten, die ich dann gebaut habe.
Und aus der Versionskontrolle geht es dann quasi nach vorne.
Da kommt dann natürlich ein Jenkins ins Spiel, der dann quasi on demand ein Bild macht.
Wenn ich Continuous Delivery tatsächlich so auffasse, wie es gemeint ist, wird ja dann jede Codeänderung quasi isoliert gebaut und dann hoffentlich auch isoliert getestet.
Das heißt, da spielt dann gleichzeitig das Thema Testen mit rein.
Aber nicht nur Testen, sondern da sollte ein bisschen mehr noch passieren.
Das heißt, mit den Jenkins dann zum Beispiel orchestriert oder auch andere CI-Tools, die können das auch alle, wie ein Bamboo oder ein TeamCity.
Da sollten dann auch Codeanalysen natürlich laufen, statische Codeanalysen.
Da wäre so ein Vertreter mal typischerweise ein SonarCube mal zu nennen für die, sag ich mal, Java- und .NET-zentrierten Geschichten oder auch andere Technologien.
Wenn man eher so im Embedded-Umfeld ist, gibt es dann sehr spezielle Tools, die auch Codeanalyse für C zum Beispiel machen.
Oder sogar Assembler machen können, die kann ich auch alle in Jenkins natürlich reinhängen.
So, dann haben wir unseren Code gebaut und dann geht der Flow natürlich weiter.
Unser Value-Stream vom Jenkins aus sollen die Sachen natürlich nicht auf irgendeinem File-Share landen.
Das sehen wir auch mittlerweile nur noch relativ selten.
Die meisten Kunden haben dann doch schon sowas wie Artifactory oder Nexus im Einsatz als Binär-Repository.
Warum sollte ich dafür ein spezielles Repository nehmen?
Das ist einfach der Grund, dass die Source-Repositories einfach nicht dafür ausgelegt sind, dann groß mit Binär-Artefakten zu hantieren.
Und vor allen Dingen das Thema Abhängigkeiten-Management eigentlich nicht gut da abgebildet ist.
Von daher macht es auf jeden Fall Sinn, sowas wie ein Artifactory oder Nexus zu haben.
Und von da geht es dann natürlich nahtlos in das Thema eigentlich Deployment über.
Das heißt, da reden wir dann darüber, wie kriege ich jetzt eigentlich die Artefakte auf meine Zielumgebung.
Ich sag mal, da sind wir jetzt nicht ganz neutral als XebiaLabs, weil wir da selber ein Tool haben.
Aber ich sag mal, was man am Markt findet, ist eigentlich alles von, wir haben Millionenzeilen, selbstgeschriebene Bash-Skripte oder PowerShell-Skripte, die das Deployment machen.
Über klassische deskriptive Deployment-Verfahren, wie zum Beispiel ein Ansible oder auch ein Chef.
Und dann ganz oben stehen dann die modernen Deployment-Tools, die tatsächlich so ein modellbasiertes Deployment machen.
Und dann abbilden können. Das ist so die Bandbreite, die man halt am Markt sieht.
Und die Deployment-Tools, egal welches, die sollten sich natürlich die Artefakte dann aus dem Artefakt-Repository dann holen und sollten sie dann auf die Stages bringen.
Dann muss man noch ein bisschen mit der Herausforderung kämpfen, dass ich natürlich Stage-abhängige Parameter dann habe.
Mal als Beispiel mein Datenbank-Passwort einfach im Testsystem ist ein anderes, hoffentlich, als auf dem Produktionssystem.
Mein Paket, was ich aber deployen will auf die Datenbank, sollte umgebungsunabhängig sein.
Das heißt, da muss ich mir Gedanken machen, wie kriege ich das Thema Configuration-Management eigentlich damit untergebracht in dem ganzen Prozess.
Da muss man ein bisschen reingucken, dass das vernünftig funktioniert.
Und dann ist eigentlich, sage ich mal, aus der Sicht von Continuous Delivery eigentlich mein Value-Stream schon zu Ende.
Wir glauben aber, dass noch ein bisschen mehr kommen muss.
Was zum Beispiel sinnvoll wäre, ist, wenn ich ein Monitoring-Programm,
ein Monitoring-System zum Beispiel habe in Produktion, dass ich dem Monitoring-System zum Beispiel sage, hier gibt es jetzt ein neues Release von der Applikation.
Das Monitoring-System kann dann darauf reagieren und kann sagen, okay, hier gibt es eine gewisse Downtime vielleicht.
Wenn ich noch keine Architektur habe, die jetzt Zero-Downtime mir ermöglicht, dann habe ich halt eine Downtime.
Da sollte mein Monitoring-System Bescheid wissen.
Das heißt, ich muss so ein bisschen mich um die Randsysteme auch noch kümmern.
Was ist mit Netzwerkkonfiguration, Firewall und Loadbalancer?
Nicht nur, mein Deployment ist nicht zu Ende, nur weil ich jetzt ein Artefakt auf eine Zielumgebung deployed habe, sondern es ist noch ein bisschen mehr.
Sachen, die auch Entwickler nicht immer so im Blick haben.
Also mehr mit den Ops-Leuten dann auch mal reden, was die denken, was zu so einem Prozess dann noch dazugehört.
Und dann war es das eigentlich.
Und was ich eigentlich mache während diesem ganzen Prozess ist, dass ich eigentlich messen sollte, wie lange hat das gedauert, was hat das gebracht.
Ich sollte eigentlich jederzeit sagen können, welche Anforderung ist jetzt in welcher Stufe.
Weil nur das ist interessant für den Kunden.
Denen interessiert nicht, ob da ein IR-File deployed ist auf einen Application-Server oder ein Docker-Container XY auf einem Kubernetes läuft.
Das ist dem Anwender egal.
Denen interessiert, welche Anforderung ist morgen verfügbar von dem System.
Und da brauche ich eigentlich was, was mir diesen ganzen Tool-Zoo, sage ich mal, am Ende des Tages so ein bisschen zusammenhält.
Das heißt, ich brauche so einen Kleber zwischen den Tools.
Der meine Sachen quasi orchestriert.
Und da muss ich auch darauf achten, dass ich mir da was Vernünftiges hole.
Ich glaube, wir sind uns alle einig, dass Excel da am ungeeignetsten ist dafür.
Aber dummerweise ist Excel der Marktführer in dem Bereich, den wir halt sehr, sehr häufig sehen.
Was versuchen die Leute, wenn sie so einen Prozess managen müssen?
Sie versuchen das mit Excel zu machen.
Und das ist eigentlich das ungeeignetste Werkzeug.
Und das steht auch nicht auf unserem Periodensystem.
Von daher ist das ein Punkt, wo wir sehr häufig mit Kunden reden.
Schmeißt Excel aus diesem Prozess raus.
Schmeißt E-Mails aus diesem Prozess raus.
Schmeißt SharePoints und Wikis aus diesem Prozess raus.
Also alles, was so eine Art Checklisten sind, haben in dem Prozess nichts zu suchen.
Sondern das muss ein Automatismus eigentlich sein.
Und dann hat man eigentlich auch ganz gut einen Blick, wo stehe ich eigentlich in meinem Value Stream?
Und welche Anforderung befindet sich eigentlich gerade in welchem Status?
Und was kann ich meinem Kunden versprechen?
Was kann ich morgen eigentlich davon auf der Produktion?
Weil nur darum geht es.
Nur Sachen, die in Produktion sind, haben am Ende einen Wert produziert.
Und das ist ja auch ein Kerngedanke von DevOps.
Was zum Thema Excel noch.
Also das heißt, wenn etwas oft genutzt wird, das heißt noch lange nicht, dass es auf der Table landet.
Das stimmt, ja.
Wir sagen ja den Kunden immer, wir können über jedes Tool,
das wir diskutieren, was ihr im Einsatz habt.
Das Einzige, worüber wir nicht diskutieren, ist Excel.
Da reden wir über Ablösung.
Ja, das ist halt eine Realität.
Es gibt auch den berühmten State of Agile Report, also in der agilen Projektmanagement.
Was wird am häufigsten genutzt?
Und da ist auch Excel auf Platz 1.
Aber das kann natürlich langfristig nicht die Lösung sein.
Ja, also ich glaube, das war jetzt, ich denke, ein sehr schönes, also beeindruckendes Beispiel.
Ich glaube, wir haben uns den ganzen Values, wie das beispielhaft durch Tools unterstützt werden kann.
Und am Schluss ist ja, wenn man sich das Ganze aus Kundensicht anschaut, es geht ja auch um Time to Market.
Das heisst, wenn der Kunde will, was er hat, ein Requirement, und aus seiner Sicht bekommt er es geliefert.
Klar, die Welt hört nicht dort auf, wenn man dann auch den Betrieb im eigentlichen sieht.
Aber wenn man das so hinkriegt, ohne Brüche,
dass man eigentlich die Time to Market drastisch verkürzen kann,
und auch die Qualität verbessern.
Wenn man das so mit dem Testing, und ich meine, wir arbeiten auch viel mit Kunden zusammen,
und da ist auch ganz klar, das ist ja nicht etwas, was man von heute auf morgen erreichen kann,
sondern es ist ja mehr ein Weg.
Also man will ja irgendwann eine Toolchain, man will Tools automatisieren, man will Tests automatisieren.
Das ist ja eher ein Weg, der sehr lange gehen kann, Jahre auch.
Das ist sicher auch etwas, das ihr seht auf eurer Seite, wenn ihr jetzt Kunden unterstützt.
Absolut, also es ist ein Weg, der gegangen werden muss, aber der muss, und das ist ein wichtiger Punkt,
man muss irgendwann mal anfangen, diesen Weg zu gehen.
Das sehen wir auch bei sehr vielen Kunden, die sagen, ja, wir entwickeln jahrelang erst mal so ein Konzept, wie sowas aussehen kann.
Das funktioniert aus unserer Sicht nicht, sondern man muss eigentlich irgendwann mal anfangen.
Es gibt ein paar einfachere Sachen, wie eine Versionskontrolle, eine vernünftige, sage ich mal, einzuführen.
Das ist auch bei den meisten Kunden schon passiert.
Es gibt ein paar Sachen, die sind bei vielen Kunden relativ schwierig, weil sie immer noch dort sehr arbeitsteilig unterwegs sind
und zum Beispiel immer noch eigene Testabteilungen haben, die nicht mit der Entwicklung so eng verzahnt sind.
Dann wird es mit der Automation ein bisschen schwieriger, aber man muss einfach mal anfangen, diesen Weg zu gehen.
Ich glaube, das ist die wichtige Aussage.
Das ist ein Weg.
Man muss einfach mal den ersten Schritt gehen für diesen Weg und ansonsten werden meine technischen Schulden quasi so hoch,
dass ich den Berg gar nicht mehr besteigen kann.
Ich muss quasi die ersten kleinen Schritte tun und dann ist eigentlich der Weg in die richtige Richtung.
Genau, und wenn es ich nicht mache, dann macht es ein anderer und da hat dann das Business ein Problem,
wenn es die Konkurrenz macht und da schneller ist.
Genau, das ist ein wichtiger Punkt.
Das sehen wir natürlich auch so ein bisschen nach Branche unterschiedlich.
Im E-Commerce spüren den Druck alle, im Bankenversicherungsumfeld fängt es jetzt so gerade an.
Im Automobilumfeld ist natürlich im Moment ein anderes Thema weiter oben, aber auch da wird das das nächste Thema sein.
Wie kriege ich eigentlich auch im Automobil meine Applikationen schneller ausgeliefert und so weiter.
Ich glaube, dass das auf alle Branchen quasi übergreift mit unterschiedlicher Intensität,
aber ich glaube, es kann sich niemand da rausziehen.
Gut, vielen Dank.
Für den Moment habe ich keine weiteren Fragen.
Möchtest du, Matthias, vielleicht noch irgendwas ergänzen?
Ich habe auch keine Ergänzung.
Ich bedanke mich, dass ich bei euch sein durfte und wünsche noch viel Erfolg mit weiteren Podcasts und mit anderen Teilnehmern.
Vielleicht hört man sich ja mal wieder.
Ja, und vielen Dank von unserer Seite für deine Bereitschaft, da mitzumachen.
An diesem Punkt möchte ich noch gerne hinweisen auf den nächsten Podcast, circa in einem Monat.
Da werden wir jemanden von der Direktgruppe interviewen, der wird uns die MetroMap vorstellen.
Das ist eine DevOps-Implementation.
Sicher auch ein sehr entspannendes Thema.
Vielen Dank.
So, dann auch ein Dankeschön von mir in die Runde.
Ich weiß nicht, ob es allen Teilnehmern aufgefallen ist.
Ich war recht still.
Ich hatte technische Probleme.
Insofern hat Alex das super zu Ende geführt mit dem Namen Matthias.
Matthias, von mir auch herzlichen Dank an der Stelle.
Und insofern freue ich mich auf den nächsten Podcast, dann ohne technische Probleme.
Und ja, schönen Abend noch.
Vielen Dank.
Vielen Dank.
Vielen Dank.