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.