DevOps und Code-Automatisierung #57

Was? 9 zufolge 57 von einfach komplex. Heute zum Thema Death Ops und CICD Wir lösen gleich auf, was das bedeutet, aber erstmal Moin Burkhard. Moin Gerrit und eigentlich schon wieder guten Abend. Wieder ein bisschen später am

Abend aber. Wir sind in Hamburg, wir sagen immer Moin. Ah, das stimmt ja, da hast Recht. Ja und bloß nicht moin Moin, nee verhoffen sich die Touristen. Genau, ja, später Abend, du sagst es also wir geben es fast noch volle Mühe hier zum Thema Deffops und CICD und als Vorbereitung habe ich mir mal eine alte Folge von uns angehört.

Folge 10 das klingt jetzt schon ganz schön weit weg, ja, wenn man einfach weiß, dass wir jetzt bei 57 sind, also es ist über ein Jahr her eigentlich, inzwischen haben schon ganz schön was runtergespult und da kann man auch mal wieder ein bisschen was ja zum Teil wiederholen, aber auch mal vertiefen und vielleicht sagst du da heute auch was ganz anderes zu, wer weiß. Ich habe es mit Absicht nicht angehört. Dann weiß ich wenigstens nicht, was ich wiederhole oder was ich vertiefe.

Damals war Cecd so ein. Das ist übrigens Continuous Integration und Continuous Development, ein Teilthema einer Folge für Software Development Tools. Heute soll es um dev Ops und Ciacd gehen und deswegen wollen wir natürlich erstmal verstehen, was ist da vorab, was ist denn cicd, wie hängt das miteinander zusammen.

Was gibt es da für Phasen? Was gibt es da für Tools, wie ist deine persönliche Erfahrung, weil du bist eigentlich ja bist da quasi Teil eines sehr kleinen Teams hier bei der High Sinware und und daher auch auf jeden Fall Dev Ops Ingenieur könnte man sagen, also Development und Operations liegen voll in deiner Hand und zwangsweise ja genau zwangsweise richtig. Gucken wir mal, was wir aus der Folge so machen. Ja, lass uns mal starten. Ja, was ist denn für dich oder

was nicht, was ist für dich? Erklär doch mal uns, was ist was ist Death orps was ist da auch insbesondere der neue Ansatz gegenüber dem traditionellen, Ich sag mal softwareentwicklungsansatz. Development Operation, das heißt Glaube ich entlang. Ja genau, also ich, ich glaube

Devob steht für alles, was außerhalb des eigentlichen puren Code entwickelns ist. Was also Code entwickeln zum Feature des eigentlichen Produktes, was ich bauen möchte?

Das verdient einen eigenen Namen, weil halt heutzutage ja so ein Stück Anwendung. Ich wage gar nicht zu sagen, was es eigentlich ist, was rauskommt, weil es kann ja so versatil sein, früher war es halt meistens einfach ein monolithische Software, ganz oft für den Desktop geschrieben, da kommen wir ja her und heute ist es halt irgendwie Cloud basierter Kram, der im Notfall gar nicht auf einem Server läuft, sondern auf ganz vielen mit verteilten Datenbanken und

so weiter und sofort und die Development Operations oft sind die auch wieder, oft muss man da auch ein bisschen coden. Oder es gibt Low Coat, Frameworks und so weiter ist quasi der ja der surrounding Code der es mir erlaubt das ganze Ding quasi an den Mann zu bringen.

Sag ich mal. Ja, also von der von während sich beim Coden ja tatsächlich irgendwie wieso n ja wieso n Ingenieur einfach auf dem Blatt Papier quasi meine Sachen mache ich das ja noch nicht am Kunden, wenn ich irgendwas skalierbar am Kunden haben will, dann wird es ein ziemlich komplex heutzutage und und wie ich das quasi wie ich den ganzen Prozess organisiere bis ich zum Kunden kriege und wie oft ich zum Kunden kriege und wie ich das quasi manage mit verschiedenen

Versionen von dem einen Ding und alles dieses. Beschreibt Deavops und ich hab mir ein ganz kleines Bild überlegt. Ich mal gucken, ich hab's nicht komplett durch überlegt für diese Folge, mal gucken wie weit

wir kommen. Aber ich finde, es ist n gutes Startbild und ich nehm das den das den Autobau, den kennt ja jeder in Deutschland haben ja auch n paar Autobauer und im Vergleich den vielleicht n Dreirad oder irgendsowas ja und der moderne Autobau, der ist nämlich sehr ähnlich wie das moderne Softwareentwicklung. Also jetzt mal ein Beispiel warum weil moderne Softwareentwicklung halt, da hab ich halt nicht mehr alle Teile die ich brauche selber in der

Garage nämlich das Beispiel vom ich schraube ein Dreirad zusammen, das kann dann schon so ich bin eine Firma die baut 3 Räder dann hab ich vielleicht alles was ich brauche. Alle Materialien, alle schrauben und so weiter bei mir selber in der Garage und kann 3 Räder produzieren und bring die raus. Ja also ich kann also da kann ich alles selbst machen.

Der Designprozess des Dreirads, ich setz mich halt hin mal das auf auf dem Blatt Papier oder im CAD Programm hab vielleicht noch 3 D Drucker da rumstehen und so weiter kann dann quasi die Teile produzieren also ganz viele Reifen ganz viele Rahmen vom Dreirad ganz viele Sitze und eine Stange hinten und. Und kann das quasi aus eigener Kraft, quasi und ohne viele

Abhängigkeiten rausbringen. Ja so n Beirat, so war Softwareentwicklung früher ja, ich hatte nicht so viele Abhängigkeiten, ich musste nicht irgendwie aus dem Internet noch was runterladen um was hinzukriegen. Ich nehme das Beispiel, ich hatte keine großen Zuliefererketten oder Irgendsowas, ja keine Abhängigkeiten. Ne, ich war selber in der Lage ohne Abhängigkeiten mit Sachen zu schaffen.

Ja und deswegen war der Prozess auch nicht so kompliziert und deswegen gab es früher auch dieses Wort Deverbots eigentlich nicht so. Weil am Ende hab ich n Stück kurz geschrieben, dann war n make file dran, dann drück ich auf make, dann wurde dann ne Executive rausgebaut, den hab ich dann irgendwo hingeschickt und da war es so gut ja mehr oder weniger vereinfacht gesagt ja.

Und heute ist Software ist ein Softwareprodukt eher so anzusehen wie n wie n. Neues modernes Auto und ich muss mich halt um. Ich brauche Leute die Design die Reifen in ne andere Karosserie, motorenbau und so weiter und ich hab ganz viele Teile die Teile kommen gar nicht aus von einem Entwickler sondern von ganz vielen, vielleicht sogar gar nicht von einem Haus, sondern ich hab da noch Abhängigkeiten, Zulieferer Open Source Komponenten das sind die

Zulieferer. Ich kaufe zum Beispiel irgendwo Knöpfe ein und sowas die ich dann verbaue modular. Und auf einmal hab ich einen hab ich ein riesen komplexes Produkt was ich managen muss und es ist nicht mehr so einfach das so zusammenzubauen, sondern auch der Prozess des Zusammenbauens wenn ich alle Teile zusammenbringen will. Ist halt, ist halt einer wo ich Abhängigkeiten beachten muss wo ich neue Versionen abhängig beachten muss.

Ne zum Beispiel wird ja mal vielleicht n Fehler aus einem Zuliefererteil ausgebessert und ich hab ne neue Version. Ich, ich spring mal kurz rein das. Ist ja das kenn ich. Jetzt kenn ich mich nur zufällig bisschen aus in der Automobilindustrie. Ein bisschen muss ich sagen und du beziehst das jetzt sogar alles nur auf das Auto und du sagst jetzt okay das ist dev ops, weil da so viele verschiedene Zulieferer sind.

Denk das nochmal ein bisschen weiter und denk mal in der wirklich vertikalen Lieferkette von dem Auto, wo fängt das eigentlich alles an, das fängt sogar an ich sag mal.

In einer Eisenerzmine, da wird das Eisen abgebaut, da wird daraus irgendwie stahl gemacht, dann wird Stahl in Form gebracht, dann wird dieses in Form gebrachte Stück Stahl ein Auto geschraubt, dann wird das aber auf den Zug gesetzt, dann wird es irgendwo hingeliefert, dann wird so ein Händler gestellt, dann wird es ausgeliefert, dann ist noch eine Bank die das Ganze finanziert et cetera PP ja, das heißt also ein Autobau ist und und vor allem ein Auto auch an den Mann

bringen oder an die Frau, das ist noch viel viel längerer Prozess und in der Automobilindustrie, sprich oder auch in der. Industrie allgemein spricht man dann von von der vertikalen Integration. Ne von unten nach oben. Die gesamte Wertschöpfungskette ist vertikal integriert, also so wäre da das das Beispiel vielleicht in Autobahnindustrie vielleicht noch n Tick korrekter, oder? Ja, wahrscheinlich.

Ich hab es natürlich jetzt so verkürzt, dass es mit meinem Beispiel, ich glaube, die Softwareentwicklung ist dann auch nicht ganz so komplex, aber ich wollte quasi darauf hinaus, dass quasi zum Beispiel ein Entwickler oder Entwicklerteam sich um nur um Reifen kümmert und einen Plan hat von den Reifen und das Horsecode ist halt der Plan von dem Reifen. Hat der Reifen mal an das ganze Ding angeschraubt werden? Und ja, und das ist ein komplexes Phänomen.

Und das ist also, das heißt, du sagst also DEV Ops es erstmal auf, ermöglicht dir Aufgabenteilung oder so. Ich geb da noch n paar Stichworte, also wenn man deops einfach mal Google, dann kommt als allererstes immer so ne. So n unendlich Zeichen so ne so ne horizontale 8.

Also so ne liegende 8 ne unendlich und da steht dann immer sowas drinne wie Plan also planen und dann Code und dann steht da drin Build und Test und das sind alles Sachen die unter Death fallen und dann geht es in die in den zweiten Ring rein und da ist dann Release deploy Operate und Monitor und dann geht's wieder los mit Plan. Die Sachen, die ich jetzt zuletzt gesagt habe, fallen unter Operations in den rechten Ring dieser liegenden 8. Ja, genau, aber das ist so.

N Auto plant ja gut, vielleicht plant jemand irgendwie mal das Gesamtdesign von so einem Auto wie das aussehen soll von außen ne, aber diese ganzen Einzelteile werden ja auch nicht, das sind ja verschiedene Leute die das planen, diese Phase gibt es auch im Autobau planen von von einem bestimmten Dingen und ja ich sage schon. Haben das auch in der Software es vielleicht gar nicht mehr einen ganzen globalen Plan gibt?

Es gibt keinen, keinen wahrscheinlich, der alles in jedem Detail weiß, sondern es gibt wir, wir haben ja so eine Software Architektur die verteilt wird, also es gibt bestimmte Unteraufgaben, es gibt die UI Entwicklung, also nur Frontend, es gibt die Backend Leute, es gibt die Leute machen authentifizierungs Integration, die nächsten machen Konnektivität zu irgendeiner Hardware oder irgend sowas sind alles verschiedene Teile die alle verschieden geplant werden

und die auch verschieden, also die auch quasi auf Teileebene getestet werden. Also Plan coden, also quasi zusammenbauen und dann testen. Was habe ich da gemacht. Ja, das passiert halt erstmal auf ganz ganz ganz nah am Level.

Ja ich teste ist das dreht das Rad quasi rund, da habe ich vielleicht einen Test. Vielleicht können wir ein bisschen weg von diesem Auto. Irgendwie kann ich es noch nicht so ganz damit verstehen, wenn ich ehrlich bin, so wie ich es verstanden habe, ist ja dev Ops die Kombination aus Entwicklung und Betrieb, das heißt, ich habe auf der einen Seite Software Entwicklung dazu gehört die Planung, die Entwicklung selbst.

Natürlich auch das testen klassische Entwicklungsaufgaben schon immer entwicklungsaufgaben gewesen und auf der anderen Seite habe ich Aufgaben des Betriebs von Software und des Ausrollens. Also dazu gehört dann zum Beispiel das Ausrollen, also das Deployment ne, aber eben das auch das Überwachen, also zum Beispiel Server überwachen oder Auslastung dieser Server zu überwachen etc. Und das nach meinem Verständnis wird in Dev Ops eben kombiniert

beziehungsweise ist dev Ops irgendwie so eine Art Sammlung an Methoden etc. Um das zu ermöglichen, dass das quasi in einer Rolle oder dass diese Teams eng aneinander rücken können. Ja genau. Und zentrale Aufgabe ist, das quasi weg zu automatisieren, dass ich quasi, dass wenn ich dass wir nicht als Coder quasi einen neuen Code herstellen, dass dann alle Folgeschritte,

die du gerade erwähnt hast, nämlich das testen, das Zusammenführen, das Versionieren von den anderen Sachen und das Verpacken in Artefakte und auch dann das quasi das an den Ja, das das zur Verfügung stellen an der richtigen Stelle in der Cloud, nämlich nicht auf meinen Laptop. Ich entwickle typischerweise auf dem Laptop, das heißt, ist ja Teil, aber das soll ja nicht jeder wieder, immer automatisch, also nicht jeder immer manuell machen soll, aber es soll halt

automatisch. Funktionieren und dafür gibt es Toolings und Prozesse, die da ineinander greifen und die zusammen würd ich sagen, nennt man dann devapser. Und diese Toolings und Prozesse, welche welche sind das erstmal so? Also kannst du da ein paar Beispiele geben. Ja, also das erste was du machen musst, ist typischerweise aus deinem Source Code quasi mal ein

Artefakt zu bauen. Artefakt ist ein allgemeines Wort für irgendwas, was man dann ausführen kann, das kann im einfachsten Fall ist das irgendwie ein Programm zum Beispiel also eine Windows exe oder irgendwas oder vielleicht

eine Bibliothek eine dll. Oder aber auch ein Image eines Docker Containers. Und da gibt es immer einen Prozess, das, man nennt es irgendwie kompilieren oder einfach bauen oder Irgendsowas der Code, den als Source Code hat, der muss halt immer irgendwie nochmal optimiert zusammengefasst werden und da kriegt dann quasi ein Siegel dran. So das ist halt die Version so und so die Bildversion von irgendwas und das ist ein Teil der der Integration, also ein Teil der Devaps am Anfang, das

Bauen quasi. Und dann kommt das typischerweise, das Testen das Ganze auch schon auf 2 Arten geben, das kann quasi auf teilgebauten Aspekten geben, also quasi sehr nah am Sourcecode. Es kann aber auch Tests geben, die quasi dann schon dieses Artefakt brauchen. Je nachdem ne das testen gibt es

gibt es halt ganz nah. Also die sogenannten Unittest, die sind halt sehr kleinteilig in den kleinsten Funktionen und dann gibt es das Testen von immer größeren zusammengebauten Komponenten, weil halt so ne Software ne aus kleineren Komponenten die quasi aufeinander gestapelt werden und immer was Komplexeres ergeben, habe ich quasi auch Tests die dann auf verschiedenen Leveln testen, also so sogenannte Integration Tests ungefähr in der Mitte, wo ich dann schon die

Zusammenarbeit von mehreren Modulen teste, aber noch nicht das ganze Wesen und ganz zum Schluss kommt immer der Ende zu Ende Test wo? Sie wirklich das voll deployate Wesens, die ganze App irgendwie Ende zu Ende teste und da müssen, da müssen alle Komponenten gut miteinander arbeiten, damit die irgendwie grün werden, ne? Dann bin ich jetzt also getestet und kann releasen, quasi oder? Und du könntest eigentlich releasen, sofern deine Tests.

Sofern du deinen Test vertraust, ja, und aber aber da will man

eigentlich hin. Ja und ich glaube das ist 1 der zentralen Ziele von jetzt sag ich nicht nur dev OPS sondern CI, also Continuous Integration und jetzt muss ich noch mal kurz akkurat werden, kontinuierlich, kontinuierlich das d. Das CD kann für 2 Sachen stehen und meistens meint man Continuous Delivery, es heißt aber auch Continuous Deployment, es sind aber, wenn man es akkurat betrachtet 2 verschiedene Dinge. Ich habe Developer gesagt, das

war natürlich völlig falsch. Nee, ich glaube du hast sogar Deployment gesagt jetzt am Anfang, aber ich weiß es auch nicht mehr, nagel mich nicht fest. Also Continuous Delivery und Continuous Deployment, also der Unterschied ist vielleicht auch ein bisschen akademisch, aber also wenn man es unterscheiden möchte ist continued delivery

ist quasi das herstellen. Des fertigen Produktes atme hatte noch nicht die Freigabe an den Endnutzer, also noch nicht das Deployen direkt der App in den Endnutzer hinein, sage ich mal, sondern man hat quasi bei Continuous Delivery noch eine letzte manuelle Phase, wo dann irgendwelche Experten oder also interne Teams noch mal einen Check machen können, ob wirklich alles super ist. Ob das Produkt, so wie es jetzt

da steht. Weitergegeben kann an den Endkunden und wenn das der Fall ist, dann macht man das Deployment tatsächlich in den Live Produktions ne, dann kannst du quasi unter deiner Domain oder irgendsowas das Ding dann sehen. Ne genau und wenn man das gut automatisiert hat, dann das testen gut automatisch. Hast dann hast du natürlich nach hinten heraus weniger zu tun. Jetzt sind wir quasi in diesem, in dieser 8.

Quasi gerade von dem Linken in den rechten Kreis gesprungen, also in der Linie 8 im Moment nicht. Zeichen also vom genau da ist nämlich der Übergang dann beim Deployment ist jetzt das Ops. Äh, quasi zuständig oder, oder, oder. Wenn die Methoden des Operations angewendet, ja, genau. Gottes Integration befasst sich mit Building Testing und Artefakt zur Verfügung stellen und dann kommt dieses Delivery mit Staging. Staging und Production Readiness also.

Als Keywords, die ich mal mitgebracht habe, sind sowas wie Provisioning oder Infrastructure as Code. Was an der Stelle zum Einsatz kommt.

Da wird sie da vielleicht ein bisschen was dazu sagen. Also wenn man irgendwas deployed heutzutage oder vor allen Dingen von der Webtechnologie sprechen, dann ist ja. Das ist ja nicht nur ein Computer, auf dem ich irgendwas hochladen muss, sondern sind im Notfall sehr viele.

Da muss ich quasi auf vielen verschiedenen Computern was updaten, Teile, die zusammenarbeiten als großes Ganzes, wenn ich ein skalierbares System habe und muss quasi dann auch an der richtigen Stelle so Sachen machen wie Internet, also IP Adressen, umrouten und so weiter innen drin. Ich will zum Beispiel ja nicht, wenn ich jetzt ein Produkt habe, was stark im Markt ist und stark benutzt wird, dann will ich eigentlich Zero Downtime haben. Ich will eigentlich, dass die neue Version.

Sofort an die alte anschließt. Und das kann ich nicht

erreichen. Indem ich also, wenn ich, wenn ich versuche, quasi auf dem auf der gleichen Hardware einfach das neue Produkt anzufahren und das Alte abzuschalten, schaffe ich das nicht mit Zero Downtime. Es geht einfach nicht, muss die Server runterfahren, ich muss das neue hochfahren, läuft vielleicht noch ne Migration ab oder irgendsowas, das braucht auf jeden Fall, da bin ich immer kurz weg, also muss ich noch viel mehr machen, ich muss quasi ich brauche Komponenten, die

haben ja auch schon mal gesprochen sowas wie Reverse proxies die quasi dann die die Anfragen vom User, der fragt ja nicht eine IP Adresse an Tipps ja nicht wenn du irgendwas suchst 147. 10 34 oder irgendwas da rein, sondern heisenwert Cloud oder so. Und da gibt es jetzt quasi wieder Technologien und das nennt man dann halt die Infrastruktur, das ist die ganze Infrastruktur dieser ganzen

Anwendung, dazu gehört. Auch das Auflösen von Domainnamen in IP Adressen und diese Infrastruktur muss jetzt dafür sorgen, dass ich quasi das neue Release sauber reinfahren kann. Das heißt, da wird dann quasi das neue System gestartet auf einem ganz anderen Server wird vielleicht einer ganz anderen IP Adresse. Wenn das alles fertig ist und wir wissen, dass das quasi losgehen kann, dann schaltet der Reverse Proxy auf einmal um und die nächste Anfrage auf die gleiche Adresse.

Eigentlich. Wird aber umgeroutet auf ne ganz andere, auf ganz andere Hardware, auf der quasi das neue System läuft und das alte ist in dem nächsten Moment

abgeschaltet. Ja nur so Krieg ich solche Effekte wie Zero Downtime, das ist Teil des das ist Provisioning was du hier beschrieben hast oder oder welche das jetzt auch ein bisschen die Antwort von deinem Infrastructor is a code was damit zu tun hat, denn die Anwendung an sich, also der eine Webserver, der auf Anfrage quasi ne html Seite zurückgibt, das ist ja nur ein ganz kleiner Sandkorn im ganzen Bild, deswegen spricht man von

Infrastruktur, du brauchst halt. Ne Skalierende Cloud Anwendung deploys brauchst du halt viele Komponenten die funktionieren müssen die aufeinander abgestimmt sein müssen. Die die meistens nicht auf einer gleichen Hardware laufen sondern verteilt sind und alles das muss aber in sich zusammenpassen und richtig konfiguriert sein und dafür gibt es so Tools wie zum Beispiel Terraform und das nennt man Infrastruktur, weil du hast.

Das ist eine echte, eine echte Infrastruktur, ein echtes System von verschiedenen Komponenten die verschiedene Sachen machen und das musst du auch als Ganzes in der Lage sein rauszunehmen aus dem System und wieder hinzu Deployen. Es ist in sich ein komplexes Wesen, das macht es wirklich. Das macht diese Aufgabe relativ komplex, und dafür gibt es halt, dafür gibt es sehr Advanced Tools, die.

Ja, die ganze Serien von Servern irgendwie mit irgendwelchen Skripts bespielen, die dann da passieren dann sehr, sehr, sehr viele Dinge gleichzeitig. Ja, und die werden aber quasi zentral gemanagt dann von so Infrastructure as a Code toolings ja, wollen wir. Dann auf diesem unendlichen Prozess weitergehen. Da kommt dann der. Nach nach des nach dem Deployment quasi das Operate,

also der Betrieb selber. Da sind so Stichwörter, Virtualisierung oder Kontenarisierung, die wir nun auch häufig schon besprochen haben. In der Webwelt ist es ja so, dass wir viel mit Containern arbeiten heutzutage. Das heißt, da guckt man dann, wie ist die Last live im System, das sind also auch Parts von, ich hab gar nicht mehr so n statisches Deployment wie früher, da hab ich das irgendwo auf dem.

Sag mal so klassisches Slamstab wenn ich, wenn ich mal so ne Anwendung gemacht hab, da hab ich mir irgendwie n dedizierten Server geholt und dann hat der halt irgendwie das gemacht was er kann und heute ist sind die Anwendungen in diesen sinnvollen Teilen aufgespalten und die Hardware dahinter ist alles virtualisiert, das heißt man kann quasi automatisch erkennen,

dass große Last entsteht. Viele User wollen ein Ticket kaufen, zum Beispiel weil irgendeine Deadline ausläuft und moderne Systeme erkennen das und fahren quasi dynamisch mehr Hardware hoch. Und es geht deswegen, weil die, weil die Softwarelogik quasi in kleinen kontinuierisierten Einheiten ist. Und das ist so, als würde ich einfach n größeres Schiff zur Verfügung stellen und mehr Container aufladen können und mehr Last abzunehmen.

Ja und das geht alles dynamisch und es fährt auch wieder runter, dynamisch wenn die Last weg ist. Also alle haben gebucht und danach macht der Server irgendwie noch eine Anfrage pro Woche. Ja dann will ich ja nicht irgendwie zig Server damit das Wasser heiß machen lassen, sondern so soll das quasi auch wieder die Hardware die benutzt wird um diese Software zu betreiben auch dynamisch runterfahren. Das sind die komplexen Herausforderungen heute von modernen Softwaresystemen.

Alles dieses ist quasi meta Informationen, die ja nicht wirklich mit der Business Logik meiner Anwendung zu tun haben, sondern mit dem skalierbaren Verhalten meiner Anwendung deswegen. Operations genau deswegen. Nennt man das DEV Ops genau und das das ist in sich ein so komplexes Thema, dass es auch neben den Softwareentwicklern, die das Produkt eigentlich entwickeln, halt die DEV Ops Engineering gibt oder Deops Team Pampers, die sich exklusiv nur

darum kümmern. Und das hat ja nicht nur was mit Skalierbarkeit und Performance zu tun, sondern auch mit Kosten. Dass der Kram wirtschaftlich auch läuft. In der Firma entstehen ja quasi Kosten, wenn zu viel Hardware benutzt wird, vor allem wenn ich die irgendwo Miete bei so einem. Bei so einem Azure oder oder was auch immer AWS ne. Also eine weitere Aufgabe von DEV Ops, insbesondere vom Obst

Teil aus. Dev OPS ist hier in dem Fall Hardware Ressourcen ja effizient einzusetzen, das beschreibt es eigentlich glaub ich ganz gut ne so viel wie man braucht aber auch nicht zu wenig, das ist quasi vielleicht nicht erreichbar ist die Anwendung du hast gerade schon so das Monitoring bisschen mit angerissen was der letzte Anführungsstrichen der letzte Punkt ist in diesem 8 oder nicht Zeichen. Da Stichpunkte sind einfach logging Visualisierungen, solche Sachen, die für uns bei heißen

wir jetzt auch gerade total spannend sind, ja.

Genau im besten Falle hast du, und da schneiden sich aber glaube ich so ein bisschen die Bereiche, also im besten Falle weißt du ziemlich genau, wie deine Nutzer deine Software benutzen, um sie besser zu machen, das kennen wir ja auch überall, also Windows und Telefon, neues Telefon kaufst, wirst ja ständig gefragt, dürfen wir anonym irgendwie Daten zur Benutzungseigenschaften und so weiter senden, das muss man abfragen, weil es Datenschutz. Rechtliches Thema wenn du so das

nennt sich Telemetrie, das Fachwort, also ich sende senden einfach nutzereigenschaften Metadaten quasi zurück und das kann auch auch auf allen Levels passieren. Ne, also es kann das können die Klicks sein auf meiner App, das kann aber auch einfach die die Loks sein die hinten im Backend passieren wo irgendwelche Fehlermeldungen aufploppen und so weiter und im besten Falle wird das alles ins

Entwicklungsteam zurückgespielt. Auch das sind viele Daten im Notfall. Da gibt es dann auch schon wieder Tools, das gehört auch dazu, elastic Search und so weiter die dir dann das rausfinden, was relevant ist, also quasi die signifikanten Ereignisse herausholen, da gibt es auch statistische Methoden und auch schon AI tatsächlich.

Für dieses ganze Monitoring von CPUS und so weiter weil das kann auch kompliziert sein, wenn du ja über Wochen oder Monate quasi ne App im Feld hast und musst dann analysieren das Big Data gegeben allen CPU Usages und RAM Usages und dann auch noch dem Nutzerverhalten, das korreliert ja vielleicht hat einen Grund warum irgendwo CPU hochgeht weil halt irgendwie eine Deadline war und alle haben gleichzeitig geklickt und so weiter aber da

gibt es halt wieder ein ganzes Set von Tools die dir helfen diese monitorten Daten quasi zu analysieren und die brauchst du quasi in der nächsten Runde der 8, weil sonst eine Software soll ja dann verbessert werden, also wenn es dann quasi gestoppt hat weil Überlastbar oder Irgendsowas, dann müssen die Entwickler das verstehen. Und dann müssen entweder die Software Jungs oder die DEV op Jungs irgendwas machen, damit das irgendwie geschmeidiger funktioniert, ja.

Cool, jetzt hast du den Kreis oder die 8 geschlossen, dann können wir wieder daraus planen und dann wieder anfangen zu coden, wieder zu bauen, wieder zu testen, zu Relesen und zu Deployen, betreiben und wieder zu überwachen, zu Monitoren letzten Endes, das darf man sich jetzt, denke ich mal nicht so als Prozessvorschläge. Immer Schritt für Schritt abläuft, sondern die ganzen Sachen laufen ja irgendwie gerade in größeren Teams irgendwie dauernd parallel und

eher themenbezogen vermute ich mal ne. Ja, und das ist das Wort Continuous ne. Also das ist du willst das eigentlich nicht sehen und wissen ja dann als Entwickler nicht ja, also als Entwickler

bin ich interessiert, ich schilder euch mal kurz die Perspektive vom Entwickler was du eigentlich haben will, der kriegt im Prinzip der geht zum Beispiel macht noch Kanban agiles Coden, so ist es modern und dann sieht er einfach in der to do Liste was zu machen ist. Ja und woher sich diese to do s die kommen jetzt von der letzten Runde der 8. Also es wurde irgendwie gemonitor, dass hier irgendwie Fehler sind, Bugs sind reported von User und so weiter

resultiert. Ende des Tages in kleinen Aufträgen Tickets, sogenannte Tickets für die Entwickler. Die schnappen sich diese Tickets. Machen einen sogenannten Brunch, das ist n wichtiges Konzept, also die Hauptlinie des Codes, das heißt meistens Main oder Master Brunch, das ist wichtig an der Stelle, das ist quasi das laufende getestete Ding, was immer funktionieren muss, ja darf nie kaputt gehen, ne. Das ist auch n Vorteil von diesen continuisten du bist halt zu jederzeit im Prinzip Release,

fertig, fertig und fähig. Ja kommt der Chef rein und sagt ich brauch jetzt n Release dann muss es gehen, dann muss hier einer n Knopf drücken und dann sagen OK es dauert ne halbe Stunde dann hast du es ja du musst nicht in Schweißperlen auf den Kopf kriegen, dann hast du was falsch gemacht ja aber um das letzte Mal fertig zu machen, dann hast du quasi ein Ticket als Entwickler und Du arbeitest an diesem Ticket und zwar so, dass du quasi von dem Hauptbrunch einen kleinen

nebenbranch abzweigst, also quasi nicht direkt was kaputt machst. Machst du deine Codeänderung und dann. Sogenanntes Merch request. Und damit fängt die ganze Geschichte der Automatisierung an. Dieser Merch request. Der kann dann gesehen werden von deinen Kollegenentwicklern oder von deinen Seniorsoftwareentwicklern, da gibt es dann einen Code Review. Das kann man nicht automatisch machen. Da guckt also meistens ne 4 Augen Prinzip einer noch mit drauf.

Gibt hier Review, also kannst sagen hier das hast du bisher besser noch hier und hier fehlt noch n Test und so weiter. Und aber wenn das dann fertig ist und das Review durch ist, dann kann man quasi so ne kleine so ne kleine Veränderung am Code. Hinzufügen zu diesem Masterbrunch. Und es wird quasi verändert. Die, die die Software und dann müssen quasi oder am besten noch davor passiert das meistens, weil wenn es wenn nichts drin hab hab ich es drin, ja dann werden diese ganzen Sachen

angestoßen, das testen. Von ganz nah an diesem Modul, was ich da gemacht hab, da ich vielleicht auch neue Tests geschrieben, aber dann werden die ganzen anderen Tests auch angestoßen, dann werden die ganzen Artefakte gebraucht um das zu testen. Ja nur für diesen, für dieses eine Ticket quasi. Ja damit ich am Ende sicher bin. Dass dieses kleine Änderung an Code dem Gesamtprodukt keinen Schaden zufügt, das ist der der Hintergrund von Continuous.

Ja, ich will halt wissen, wenn ich irgendwie irgendwas verändert hab, ist das immer noch Release fähig.

Ja und wenn ich das gut gemacht hab, dann dann stößt quasi diese dieser kleine Effekt ne riesige Reihe von von weiteren Prozessen an, die dazu führen, dass ich irgendwie in der Staging Umgebung was neues habe oder sogar wenn es ganz krass ist, ist tatsächlich deployed bis zum Ende gleich durch pro Ticket oder das ist nicht der extremste Fall oder man einigt sich natürlich drauf und das machen wir auch so, dass man sagt man fasst jetzt hier einige Tickets zusammen und macht so eine Art

Release. Das muss dann nicht 1.3.4 heißen. Das können dann auch einfach so Releases sein, die durchgezählt werden und dann fasst man mehrere Sachen zusammen, vor allem was sich komplett durch automatisiert hat, sondern wenn ich auch nochmal klicken will, dann wird das quasi das neue Release, das hat so und so viel Features und so und so viel Bugfixes und dann kommt das in so eine Art Staging wo man das schon mal so benutzen kann wie

als wäre es fertig. Dann heißt aber die Domain irgendwie staging heisenware irgendwas. Und dann wird das normal alles auf, auf auf. Wie sagt man so schön, Herz und Nieren getestet, ja genau das fehlt mir gerade, danke und dann drückt man auf deploy und dann ist es halt dann am Kunden ne und aber als Entwickler will ich das eigentlich alles gar nicht wissen, ne?

Dann mache ich meine Tickets. OK, dann machst du deine Tickets. Da hab ich dann gleich noch mal ne Frage zur Zusammenarbeit. Aber vorher noch ein Einschub, woran ich mich noch erinnern kann von von früher, wo wir auch schon gemeinsam ja gearbeitet haben bei Netzangestellte. Da ging, da gab es immer den Release Train, das weiß ich noch. Ja, da kann man der Release Train irgendwie an manchen Tagen.

Was war das noch mal? Ja, das ist, das ist das Zeichen, wenn es noch nicht so richtig automatisiert ist.

So, ja dann. Ich glaub das hab ich in vorher gesehen, dass ich erinnere mich hab ich glaub ich auch gesagt, da gab es dann Release Tagen kamen die Softwareentwickler mit dem Bauhelm an. So irgendwie ne.

Heute ist Release Tag, heute muss schwer geschuftet werden, ne und dann schwer geschwitzt werden, weil manchmal ist das so ne du hast ne also das Management zum Beispiel oder aus irgendwelchen anderen Gründen gibt es n Release date das muss gehalten werden in der Gamingindustrie ist das total

krass. Ja, die Versprechen haben wir mal n Release Date, da muss das Spiel rauskommen und an diesem Tag muss dann halt irgendwie alles so zusammengebaut werden da da entwickeln vielleicht 500 Entwickler zusammen alle ihre verschiedenen Teilchen und Hühnchen und aber an diesem Tag muss halt alles so aufbereitet werden, dass wirklich alles gut zusammen funktioniert, nichts mehr kaputt ist. So ja und wenn das nicht automatisiert ist, dann kriegst

du, dann musst du arbeiten sag. Mal aber war der Release Train, also der Zug der Train im Sinne von Zug, jetzt nicht so, dass der wirklich immer regelmäßig fuhr in Anführungsstrichen also. Immer dienstags, so wie es jetzt unseren Podcast gibt. Und dann guckst du halt, dass du, wenn du da dein Ticket abarbeitest, dass du das entweder noch auf den Zug aufschmeißt und du wartest halt auf den Zug, der dann eine Woche später erst fährt oder 2. Ja. Das ist so. Ja, das stimmt.

Also das war tatsächlich das Meaning von dem Release Train, auch wenn die Bauräume auch mal da waren so, aber das ist so, ja es wurde immer Release zu einem Takt genau continuous, also es wurde nicht relevant wenn irgendwelche Features drin waren und da Bugs nicht, sondern es wurde zum festen Zeitpunkt released genau das Ganze machen und da so eine Pipeline hast genau. Dann dann ist das mit den

Tickets was ich sagte. Entweder ist das noch mit drin, weil das das Review gepasst hatte und wurde quasi noch mit eingebaut in den. In den Featuresatz oder in den Bugfixesatz oder halt auch nicht. Genau. Und wenn du es nicht geschafft hattest, dann war es halt irgendwie erst zum nächsten. Mal was ganz Wichtiges war für den Kunden, dann wurde der Zug auch mal kurz blockiert. Ne irgendwie. Mal. Was in die Speicherschlüssel noch. Einmal noch einmal noch einmal

im Kreis geführt. Weiche, oder?

Ja, dann noch mal nachtanken. OK, ich glaub das das passt zum zum Death orps also es sind irgendwie es es ist so ne so n Oberbegriff hab ich jetzt auch verstanden noch besser der eigentlich alles zusammenfasst was irgendwie in ne Softwareentwicklung und aber auch den Betrieb der Software anfällt, da Tools und Methoden zur Verfügung stellt und auch das ganze oder bei der Disziplin als als als 1 begreift weil am Ende dient das alles dem, dass die die Nutzer der Software

eigentlich eine tolle Software bekommen. Die auch immer zur Verfügung steht. Auf meinem Spicker steht so eine Sache, die ich erwähnen wollte, damit man versteht, warum das, also man kann lange darüber reden, was da alles gibt und so weiter aber ich glaub man

versteht immer noch schwierig, warum das wirklich notwendig ist. So viel Krams irgendwie ja.

Ich, ich will ein Beispiel geben, wenn wir heute, wenn man nur ne ganz einfaches Frontend macht, mit React zum Beispiel ne Single Page Application und das startet zu entwickeln und man sagt einfach nur krei mir mal die Grundlage um jetzt ne React App zu bauen und ich hab noch gar nichts gebaut, da dreht nur n Logo irgendwie auf der Seite. In dem Moment habe ich schon 1000 ich hab's nicht ausprobiert heute morgen 1490 Pakete runtergeladen, die Penancies aus dem Netz nur um die Basis

hinzustellen. 1490 ja, 1400. 90 die penancies hast du ja also 1490 Gitarre Repositories, die irgendwo verteilt sind, die irgendeine Version haben, die aber ziemlich genau aufeinander passen müssen, damit das alles zusammen funktioniert. Und das ist ja nur der Start und dann fängst du erst an Software zu entwickeln, darauf bauen sich dann noch deine Dependencies

auf, die du brauchst. Also so große Projekte haben unglaublich viele Dependencies und wenn man sich jetzt anguckt, wie das heute funktioniert, das normale Web Development, das muss man sich auf der Zunge zergehen lassen, dann ist es so, wenn du das. Von Scratch neu installierst. Also du hast deine Codebase und dann sagst du NPM ist zum Beispiel der Paketemanager für Node Note Package Manager, der macht das so. Ja dann sagst du NPM in Stall und dann lädt der sich just in Time.

Diese ganzen Dependencies aus dem Netz, von diesen ganzen Repositories runter. Und dann nimmt er deinen Code und bastelt ihn dazu und so weiter das heißt ein Artefakt, dein Produkt, was du da machst, ist total abhängig davon, wann

du es tust. Ja, machst du 3 Tage später die gleiche Übung, hast du n ganz anderes Produkt, weil um dich rum irgendwelche Entwickler vielleicht schon wieder ihr nächstes Patch gemacht haben oder den nächsten Miner Update und dann kriegst du diese Patches und meine Updates typischerweise auch mit rein in deinen Kram.

Und das willst du aber nicht haben, wenn du wenn du es wäre eine Katastrophe du testest zum Beispiel irgendwie eine Woche lang ja und dann kannst du es nicht schaffen reproduzierbar. Dieses getestete Ding in das finale Artefakt zu verpacken, was dann das Docker Image ist, wird was ausgeliefert wird.

Allein dafür braucht es schon Tools und diesen Komplex ja gibt es so Log Files und so weiter dass du dann quasi gibt es sekundäre Files, die speichern dir ab welche exakte Version von welchem Paket habe ich hier genutzt? Diese ganzen Sachen die musst du richtig kriegen. Ja das ist alles Teil von diesen Automatisierungsprozessen weil am Ende ist da sogar ein Softwareentwickler das lange macht mit überfordert das alles selber.

Richtig hinzubiegen, ne, also das wollt ich mal so sagen da da muss ich mal so ne Idee kriegt was so los ist. Ja und auch wichtig, du musst ja wenn du jetzt mal n Bug hast und du willst den Nachstellen reproduzieren, das muss man auch einmal verstanden haben, ein fertig ausgerolltes System das. In die Hand kriegen ist Hochoptimiert da sind die Code

zahlen nicht mehr leserlich. Das wird alles so zusammengedampft sag ich mal von automatischen anderen Computerprogrammen, dass das hoch optimal läuft mit maximaler Geschwindigkeit. Ein Entwickler kann da nicht mehr reingucken, das ist wie n wie ne Blackboard ja.

Wenn man jetzt aber n Fehler findet und sagt, in dieser Version war was kaputt und du musst das in dieser Version noch fixen und das ist ja kein seltener Fall, dann muss ich ja in der Lage sein, dieses komplexe Produkt nachzustellen, aber so, dass es quasi der Code wieder offen ist, nicht komprimiert und den Fehler finden könnten um ihn dann zu fixen und auf dieses Ganze rückwärts Korrespondenz, dass ich quasi in der Lage bin eine bestimmte Version mit diesen

ganzen vielen verteilten Komponenten nochmal quasi in der Entwicklungsumgebung quasi hinzubauen, damit ich Bugs nachstellen kann. Das ist alles hochkomplexe Materie und das Bedarf dann solcher Tools. Jetzt komme ich noch zum Anfang von diesen Infrastructure as a Code, die in der Lage sind das quasi zu tun für dich automatisch, weil sonst wirst du wahnsinnig, da musst du ja die

zig Systeme anfassen jetzt bist. Du noch mal ein bisschen abgetaucht, auch noch mal ein bisschen in Deavups rein oder in einzelne Methoden daraus oder so genau. Aber nur noch mal, um Anzuteasern, damit unsere Nutzer verstehen, warum man das Macht. Als der Softwareentwickler genau warum? Macht man das als Softwareentwickler? Jetzt will ich aber ganz gerne noch mal zum Abschluss eine. Höher gehen. Ja warum führen Team Staff Ops ein?

Ja also du hast jetzt viel von Automatisierung gesprochen und von Tools. Wirkt sich dann das eigentlich auf die Zusammenarbeit in Teams auf aus und auf die Kommunikation, also auch Dev ops, aber wie auch CICD? Ist jetzt klingt es für mich so, als wäre das alles so. Stark definiert und automatisiert und die Schnittstellen sind ganz klar, dass da eigentlich keiner mehr

miteinander sprechen muss. So n bisschen ne und Kommunikation hinfällig wird, Zusammenarbeit also auf ganz klare Schnittstellen Übergabepunkte beschränkt ist. Ja ist das so oder ist das eigentlich anders in Teams und welche Vorteile hat das eigentlich und welche Nachteile sowas einzuführen? Sehr gute Frage. Also ich würde sagen, wenn du ein sehr großes Team bist und hast ein Produkt mit sehr sehr vielen Komponenten, wo sehr viele Entwickler an verschiedenen Komponenten

arbeiten. Meistens ist das so, dass die Entwickler nicht komponentenübergreifend arbeiten, sondern es gibt Spezialisten für bestimmte Bereiche. Also mindestens Frontend und Backend wird oft getrennt. Full Stack Entwickler gibt es gar nicht so viele. Willst du eigentlich schon auch die Kommunikation ein bisschen limitieren?

Also du willst ja effizientes Projekt haben, das heißt du willst minimal kommunizieren müssen um maximal zu wissen ob das funktionieren wird und deswegen wird das automatisiert, ja dann ist es nämlich so. Wenn du jetzt ein Stück Code machst in einer bestimmten zu einer bestimmten Funktion, für die du zuständig bist als Entwickler. Dann kommunizierst du eigentlich nur noch mit denen, die das auch

verstehen können. Also dieses Review findet statt, ja, und aber für beide Parteien, für den Reviewenden und für den, der den Code geändert hat, ist es total essentiell zu sehen, dass irgendwann mal, und das ist jetzt Teil dieser Continuous Integration, der Dev Ops, ein grünes Licht aufleuchtet, dass alle Tests. Nichts mit dir direkt zu tun haben, aber indirekt ne, die werden ja alle automatisch

angestoßen. Ja, dass die Grünen laufen, dann weißt du schon mal, dieser Code wäre technisch erst mal so Releasefähig jedenfalls das, was dir deine Testabdeckung, die du gerade hast sagt ja. Das total wichtig, weil so.

Also wir hatten das in der alten Firma, solange das nicht auf Grün ist, brauchst du gar kein Review anstoßen, ne, weil mit dem roten X, weil weil du irgendwas gemacht hast was irgendeinen anderen Test failen lässt, weil irgendeine Schnittstelle nicht richtig bedient wird, wie sie eigentlich definiert war oder irgend sowas. Ja, kann sagen, das wird halt, das wird sowieso nicht durch, das blockt es auch.

Ja und deswegen und eigentlich willst du nämlich tatsächlich die Kommunikation schon schlank halten, ja, du willst nur mit deinem, mit deinen Leuten, die auch von deinem Code so n bisschen was verstehen Reviews machen, weil das ist ja aufwendig so n so n wenn du n ordentliches Code Review machst, dann muss ja derjenige der Reviewt sich schon auch tief einarbeiten. Wir sprechen hier von Source Code, das ist ja jetzt keine keine laxe Materie, oft ist das.

So und dann, und dann will ich quasi das relativ schmal halten. Ich kommuniziere aber nur mit mit den notwendigen Kollegen, sag ich mal. Ja, also so würd ich es jedenfalls organisieren. Ja, und so ist es glaub ich auch viel organisiert O. K, das heißt, Kommunikation wird tatsächlich Runtergeschraubt. Es ist, es ist so eine. In Technik definierte Schnittstelle dann häufig sogar

schon, wie du gerade sagst. Ja, die Lämpchen gehen auf grün, dann kann ich überhaupt erst weitermachen oder eben nicht, dann muss ich erstmal auch für mich bleiben und und das heißt Kreativität ist in so einem Prozess eigentlich jetzt nicht erlaubt. Sondern beschränkt sich dann auf die auf die einzelnen Schritte. Ja, ich kann in meinem Ticket kreativ werden, ich kann vielleicht beim Operations kreativ werden oder sowas, also kreativ im Sinne von ich.

Ich kann überlegen, wie ich das jetzt löse, ne gewisse Herausforderung ne aber? Den Prozess darf ich eigentlich nicht jetzt anfangen zu verändern. Also ich muss schon konform sein, denn als Entwickler in so einem großen Team und und und kann da nicht aus der Reihe tanzen. Nee, nee, überhaupt nicht. Und dann also man versucht tatsächlich auch das, das liegt an der Physik der Dinge, sag ich mal. Man versucht die Tickets sehr klein zu halten, ne, also ich

mach nie irgendwas großes. Ja im besten Fall habe ich nur sehr kleine gekapselte Dinge die ich tue und bringe die rein, weil je größer das Teil wird und am schlimmsten ist übergreift irgendwelche Schnittstellen und Grenzen dann habe ich ein größeres Teil so dann muss mehr kommuniziert werden, da müssen mehrere Tests angefasst werden, da muss teamübergreifend irgendwas gemacht werden, aber das.

Auch im echten Leben. Ja, auch so habe ich ein komplexes Produkt, Maschine oder irgend sowas und will die ich will was was was maschinenübergreifendes Komplexes ändern. Da müssen wieder viele Sachen angeguckt werden. Ob die danach noch funktionieren. Ne, das macht das, das ist schon ne schwierige, das geht aber trotzdem auch auch dafür hilft dir die Automatisierung ja, aber dann dann dann macht man es quasi nicht in so nen kleinen Check out Brunch, das macht man

quasi. Dann teilt man das Produkt, die Hauptlinie quasi in ne zweite Linie und dann müssen quasi mehrere gleichzeitig ne längere Zeit an einem zweiten entwicklungsbahnschen Feature Branch zum Beispiel wenn das was

Größeres ist. N größeres Feature gibt es ja auch, ja. Müssen sie halt arbeiten, während der Alte noch bedient wird, die die Bugs und so weiter von dem alten müssen noch gefixt werden, sehr teuer für so n. Für so ne Firma, dann teilt quasi das Entwicklungsteam oder die die Leute teilen sich aufmachen n bisschen an dem ganz neuen Krams rum, während der Alte noch am Leben gehalten werden muss, ja. Und genau und und auch dafür brauchst du halt ganz, ganz dringend versionskontrolle und

so weiter du willst halt also das kriegst du im Leben nicht manuell gemanagt so ja und die Versionskontrolle, das Wissen vielleicht auch viel und ich sage hier noch mal, es ist ja so, dass je nachdem du kannst halt sagen, ich will als Softwareentwickler auf einen bestimmten Entwicklungsbranch an einem bestimmten Punkt springen und was passiert ist, werden unter deinem Hintern tatsächlich alle Dateien ausgetauscht und so weiter physikalisch du siehst dann.

Die die so, die den den Sourcecode an dieser Stelle in diesem zu diesem Zeitpunkt auf diesem Branch. Ja, und das ist alles konsistent in sich, ja, also das kriegst du sowieso nie im Leben hinkriegen, wenn du irgendwie da mit irgendwelchen Files selber rumjonglierst und so weiter.

Und das heißt ineinander integriert und deswegen mit den Tests und so weiter die hängen alle davon ab das Versions das Versionssystem ist quasi so n bisschen der Dreh und Angelpunkt die Drehscheibe für diese ganzen Automatismen die dran kommen und. Für für so n. Für diese ganzen Automatismen und diese ganzen Tools und diese ganzen Überlegungen, was den Prozess. Angeht. Wer ist dann am Ende zuständig?

Das ist so ne Art Entwicklungsleiterleiterin also oder gibt es da noch mal wieder ne eigene Rolle sowie was weiß ich Scrum Master beim Development oder so oder. Ich würde sagen, dass der Vorsitzende vom DEV Ops Team so

ja also der DEV ops bleibt, wenn man sich das leisten kann, dann hast du nen in diesen, das sind sehr sehr prominente stellen auch sehr gut bezahlt im Moment glaube ich höher wenn man so guckt als ein Softwareentwicklerstelle. Denn man muss sehr viel wissen und sehr viel Tools kennen.

Es ändert sich auch ständig und man hat sehr viel Verantwortung, weil das mindestens genauso wichtig das Ding irgendwie auf die Straße zu setzen, als es überhaupt zu bauen ne und und derjenige entscheidet das glaube ich, in enger Abstimmung mit Management und so weiter aber der der Leiter des DEV Ops Teams. Ist tatsächlich eher eine Expertenrolle als eine leitende Rolle. Sogar jetzt auf jeden. Fall ist eine Expertenrolle, also einfach eine leitende Angestellter schafft das nicht,

also ein Dev ops. Ein erfahrener Devopsingenieur hat sehr viel Fachwissen. Sehr aktuelles Fachwissen und gibt. Es dann irgendwelche bestimmten. Weißt du das? Gibt es irgendwelche bestimmten kp is? An denen sowas so ein Prozess dann gemessen wird, ob der erfolgreich ist oder nicht. Also. Naja, ich würde sagen, also der eine KPI der alles zählt ist funktioniert.

Diese Automatisierung im besten Falle kannst Du auf ein kannst du sagen und das machst du einfach, du checkst zum Beispiel einen Tag ein, was so viel heißt ich möchte jetzt hier ein Release machen. Und wenn das dann einfach durchrutscht und alle Tests werden Grün und am Ende hat der Endkunde sogar nicht nur nen Delivery sondern so n Deployment und alles ist da und das eine neue Feature ist mit drin, dann hab ich alles richtig gemacht als devopsingenieur.

Und aber ich glaube, das echte Leben ist irgendwo dazwischen, zwischen kompletter Automatisierung und semio Automatisierung. Aber das der Heilige Gral ist das im Prinzip jeder zu jedem Zeitpunkt sagen kann, hier das Review ist gut, das Ding kommt rein, ich drücke auf den Knopf und dann dauert es ein bisschen, je nachdem, es ist ja auch manchmal sehr viel, deswegen kann man es auch gar nicht mehr lokal machen, deswegen brauchen wir auch diese Tools, man

braucht manchmal richtig Materie, richtig Server, das alles kompilieren und nach 2 Stunden das neue Release draußen und ohne dass ich irgendwie Angst haben muss, dass irgendwas kaputt gegangen ist oder ich irgendeine Komponente vergessen habe, oder? Irgendein System nicht hochgekommen ist, denn wir haben ja auch mit echter Hardware zu

tun. Das ist auch nicht vergessen, wenn ich jetzt immer, ich spreche immer wieder, sind auf verschiedenen Servern, manchmal geht ja auch einfach eine Festplatte kaputt oder irgendwas, da kümmern sich meistens die Cloud Anbieter drin, aber im Prinzip gehört das auch dazu, ja, da muss das erkannt werden und quasi auf den nächsten deployed werden und so weiter. Also es ist am. Ende eine Effizienzkennzahl, die dann tatsächlich den Erfolg bemessen könnte.

Ja, und garantiert die halt die Performance vom Team, weil du willst halt die Softwareentwickler komplett freihalten von diesen ganzen Prozessgedöns. Du willst halt das die Coden können effektiv. Von deren Features und Bugs arbeiten und sich nicht kümmern

müssen. Ob der Rest irgendwie läuft ne und es ist natürlich auch ein Langzeitstabilität für dein Produkt, wenn du sowas aufgebaut hast und das kontinuierlich weiterbaust und du jedes neue Feature und jeden Bug und im Test hinterlegst wo du dann automatisiert quasi sehen kannst, läuft es oder läuft es nicht, dann baust du natürlich eine riesen Geschwindigkeit auf und wenn du es nicht machst, verlierst du ganz viel Geschwindigkeit gegenüber einer

Firma, die das zum Beispiel macht, dann brauchst du halt ganz viel Personal mehr wie es halt so ist, ist quasi die Digitalisierung einer Software Firma könnte man sagen die devops. Verschlafen manche Softwarefirmen auch, so wie manche Maschinenbauer das verschlafen? Ich glaube, das wird teuer am Ende des Tages. Apropos. Man braucht ganz viel Personal. Vielleicht machen wir so eine Folge nochmal. Wenn man noch mehr Erfahrung mit größeren Teams gesammelt haben. Das Team wächst.

Bookert wen suchst du gerade? Ah ja, das stimmt ja genau, das Team wächst. Wir suchen gerade einen Frontentwickler für für uns, der Lust hat auf ein Startup, sich da auf verwirklichen kann ja viel Verantwortung übernehmen darf und das ist auch vielleicht eine Last. Das muss man auch rollen, aber man hat natürlich, wir arbeiten am schönen Produkt glaub ich und der auch n bisschen Gefühl für

UX hat n schönes Aussehen und ja Lust auf Start Feeling hat ja jetzt bei uns genau richtig. Ja möge sich bewerben ne oder sie. Und wahrscheinlich javascript. Und der React ist noch n Thema. Genau und javascript richtig. Also wer jemanden kennt oder sogar zuhört, hier als Frontentwickler, darf sich gerne mal melden. Ja, wir sind gerade dabei, ja, die ersten Gespräche zu führen. Und nehmen natürlich gern noch Bewerbungen. Soviel zur Werbung, ja dann wird es passend für mich.

Forgot ja, ich. Hab mehr verstanden. Ich hab das natürlich anfangs n bisschen selber rein gelesen, aber ich hab jetzt n besseres Gefühl, was es eigentlich bedeutet Deff Ops das ist es ist tatsächlich dieses Set an Methoden und so ins Gesamtprozess zu betrachten und nicht es nicht. Es gibt jetzt nicht diese eine Dev aufs. Personen oder sowas, die beides macht, sondern es ist eigentlich n übergreifendes Thema, ne. Ja, ich, ich glaube das, was ich zuletzt gesagt hat, hat mich

selber überzeugt. Also es ist quasi die die Digitalisierung der eigenen, eine Softwareunternehmens, was irgendwie in sich komisch klingt, aber die Digitalisierung der Prozesse ein und Automatisierungsprozesse innerhalb einer eines Software schaffenden Unternehmens, das trifft es, glaube ich ziemlich gut. Perfekt. Dann den Deckel drauf, so ist es. Danke dir wie immer und danke euch fürs Zuhören. Wir hören uns in 2 Wochen wieder, so sieht's aus bei dem Thema.

Schönen Abend, Tschüss aus Hamburg, das hab ich gesagt. Ja ist. Doch gut, dann wünsche ich noch einen schönen Abend heute. Ciao. Flex wird präsentiert und produziert von Highsomware. Wir freuen uns auf deine Fragen und deinfeedbackanpodcast@heisewerk.com vielen Dank fürs Hören dieser Folge bis Dienstag in 2 Wochen und Tschüss aus Hamburg.