Folge 17: DevOps Toolparade (Teil 1)

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Mit Sandra Parsick spreche ich über den Toolseinsatz im Rahmen von modernen Techniken aus Continuous Integration (CI) und Continuous Delivery (CD). Insbesondere unterstützt Continuous Delivery wichtige Architekturziele wie Stabilität und Reaktionsfähigkeit. Sandra hat einen sehr informativen „Spickzettel“ zum Thema Continuous Delivery erarbeitet, den wir zum Anlass nehmen, über die Perlenkette der Tools zu sprechen. Und wir hatten so viel zu besprechen, dass wir gleich noch eine weitere Folge angehängt haben, siehe dazu Teil 2.

In dieser Folge des DevOps-Podcasts wird eine tiefgreifende Diskussion über verschiedene DevOps-Tools und deren Einsatz in der Softwareentwicklung und im Betrieb geführt. Sandra Parsick, eine erfahrene Beraterin, und der Gastgeber Dierk Söllner erörtern die Bedeutung der Tools für die Automatisierung und Optimierung der Entwicklungsprozesse. Themen wie Continuous Delivery, Continuous Testing, Version Control Systems, und die Herausforderungen der Integration von Entwicklung und Betrieb werden ausführlich behandelt. Dabei wird auch auf die kulturellen Aspekte von DevOps und die Notwendigkeit der Anpassung von Arbeitsweisen und Unternehmenskulturen eingegangen.

Inhalt

  • Einleitung und Vorstellung von Sandra Pasig
  • Definition und kulturelle Aspekte von DevOps
  • Bedeutung von Version Control Systems in DevOps
  • Diskussion über Continuous Delivery und Testing
  • Bedeutung von Continuous Inspection und statische Code-Analyse
  • Datenbankintegration und Herausforderungen
  • Konfigurationsmanagement in der Praxis
  • Automatisierte Verteilung und Controlling von Software
  • Rolle von Monitoring und Feedback-Systemen
  • Diskussion über Organisationsstrukturen und Arbeitskulturen
  • Verschiedene Arten der Versionsverwaltung

Shownotes

Die Basis unseres Gesprächs, der Architektur-Spicker

Webseite von Sandra Parsick

Transkript (automatisiert, daher keine Gewähr 🙂 )

DevOps. Auf die Ohren und ins Hirn. Ein Podcast rund um DevOps. Von Dirk Söll.
Hallo und herzlich willkommen zu einer neuen Folge DevOps Podcast auf die Ohren und ins Hirn. Das
heutige Thema ist die DevOps Toolparade. Wir hatten ja schon mal in einer Folge das
Periodensystem von den DevOps Tools mal so auf einer allgemeinen Ebene besprochen. Heute gehen
wir ein bisschen tiefer und ich freue mich auch auf den Gast, den ich dort habe. Sandra Pasig ist
erfahrene Beraterin und kennt sich mit den Tools aus in dem DevOps Umfeld. Also heute reden wir
über Technik, reden viel über Tools und ich würde sagen, Sandra, am besten stellst du dich einfach
mal vor. Ja, hallo Dirk. Danke für deine Einladung, dass ich hier dabei sein kann. Ja, wie du sagst,
Sandra Pasig mein Name. Ich bin freiberuflich als Softwareentwickler unterwegs, hauptsächlich im
Java Enterprise Umfeld. Gerne nach agilen Methoden und Software-Craftmanship-Prinzipien. Ich werde
aber auch gerne eingesetzt, deswegen hast du mich auch wahrscheinlich auch eingeladen, weil ich,
um die Entwicklungsprozesse zu automatisieren. Und das sind ja so Schlagwörter wie DevOps oder
Continuous Delivery, Integration. Ja, und dann geht es halt darum, halt Tools einzusetzen, um dann
zu automatisieren. Sehr schön. Ja, also wir sind genau drin und im Vorgespräch haben wir schon
herausgefunden, dass wir beide auf das Thema DevOps, auf den Begriff DevOps, unsere eigene,
aber eben gleiche Sicht haben. Und ich starte ja in meinem Podcast auch immer mit der Frage an meine
Gäste, wie sie DevOps beschreiben würden, wie sie DevOps definieren würden. Also insofern, Sandra,
wie würdest du DevOps definieren? Also für mich ist DevOps eigentlich ein Kulturbegriff,
hat eigentlich weniger mit Technik.
zu tun, sondern es geht eigentlich eher aus meiner Sicht darum, wie kriege ich diese Silos zwischen
Entwicklung und Operation oder Betrieb halt, also die Mauern halt abgerissen und wie kriege ich halt
die zwei Welten, die eigentlich in klassischer Sichtweise halt unterschiedliche Ziele haben,
irgendwie zusammen, sodass am Ende die Software besser oder schneller halt ausgeliefert werden
kann oder auch besser halt auch betrieben werden kann. Von daher so Sachen wie mit DevOps Engineer,
kann ich dann immer wenig anfangen, obwohl ich ja auch mich auf Projekte halt dann bewerbe,
wo DevOps Engineer drin ist, weil man muss dann meistens immer hinterfragen beim Kunden,
was die genau damit meinen. Aber was eigentlich, was für mich DevOps ist, ist eigentlich,
wie kriege ich zwei Welten zusammengeschmeidt, um dann besseres Software zu entwickeln und zu betreiben.
Ja, okay. Also auch du, selbst wo du aus der Technik kommst, aus meiner BWL-Sicht an der Stelle, sagst auch du, es ist eine Kultursicht und ja,
es geht um das Zusammenführen. Das ist natürlich richtig und insofern könnte es ja sein,
dass ich mit Tools ja auch eine Zusammenarbeit unterstütze.
Ja, natürlich. Also ich meine, das fängt ja schon bei den einfachsten Sachen an, wie zum Beispiel,
dass ich meinen Source-Code oder meine Konfigurationen ja versionieren sollte.
Also, dass diese Sachen nicht irgendwo auf Netzwerklaufwerke umschwirren oder lokal auf dem Rechner von einem Entwickler
oder Konfigurationsbeschreibungen, wenn es gut läuft, in einem Wiki oder wenn es schlecht läuft,
halt ein E-Mail-System oder in Word-Dokumenten, sondern dass ich zum Beispiel sowas in einem Visionskontrollsystem halt ablege.
Also das fängt ja schon damit ja an. Also ich meine, durch dieses Kulturelle, durch die Zusammenarbeit,
da wird auch erstmal auch der Bedarf ja geweckt, dass man anfängt halt Tools zu entwickeln.
Also es ist ja nicht so, dass jemand aus Spaß die Dinger entwickelt hat, sondern es sind ja auch irgendwelche Bedürfnisse entstanden.
Wenn wir den Begriff jetzt mal so nehmen, Continuous Delivery, du hast so einen wunderschönen Architekt,
du hast so einen Architekturspicker gebaut und den werde ich auch in die Shownotes verlinken.
Der ist sehr, sehr schön dargestellt und an dem werden wir auch uns entlanghangeln.
Und dieser Architekturspicker, der fängt so schön an mit dem Thema, worum geht es überhaupt?
Also welche Herausforderungen gibt es, wenn wir über das Thema reden, Continuous Delivery und welche Ziele verfolgen wir damit überhaupt?
Ja genau, das ging halt hauptsächlich einmal so, wie wir halt Risiken minimieren.
Das heißt,
da merkt man schon, wo dieser Gap ist zwischen Entwicklung und Betrieb.
Entwickler wollen halt, dass ihre Features, die sie entwickelt haben, so schnell wie möglich halt rausgehen.
Und der Betrieb hat aber eigentlich Angst, hier das mal neue Software rauszuhauen, weil das ist immer,
ja, da ist immer eine, man weiß halt nicht, wie die Software dann halt sich dann verhält in der Produktion.
Und da will man halt unter anderem durch Tool-Unterstützung oder durch, wie man sich zusammenrauft, halt dieses Risiko minimieren.
Also trotzdem schnell.
Ausliefern können, aber auf der anderen Seite das Risiko minimieren, dass die Entwickler, dass der Betrieb, Entschuldigung, an der Stelle die Angst abgenommen wird, dass das alles instabil wird.
Und dann ist es halt auch so, wir haben halt in der Softwareentwicklung öfter mal Aufgaben, die sind monoton, immer wiederkehren.
Und das, was der Mensch nicht kann, ist monotone, wiederholbare Tätigkeit mit derselben Qualität abzuliefern.
Und da ist die Frage, wie kriegen wir das?
Durch Tool-Unterstützung solche Aufgaben halt gelöst, sodass man nicht das Risiko hat, dass durch monotone Tätigkeit irgendwann mal Fehler halt sich reinschleichen.
Und dann will man auch gucken, okay, welche Auswirkungen haben eigentlich Änderungen in meinem Quellcode?
Oder wenn ich andere Technologien einsetze oder Konfigurationen ändere, dann möchte man das auch relativ früh im Entwicklungsprozess erkennen und nicht erst beim Gründen.
Wenn die Strafe beim Kunden halt läuft.
Und das sind so die Hauptpunkte, wo man sagen möchte, okay, das sind die Motivationen, worum ich denke, Tools oder worum ich automatisieren möchte.
Ja, also es geht im Prinzip dann, wenn ich es mal mit meinen Worten kurz zusammenfasse, es geht um Risikominimierung.
Ja, genau, BWLer, genau, Risikominimierung.
Und das zieht auch bei Controllern, die dann weiter Ausgaben bewilligen müssen, weil Tools kosten ja auch Geld.
Am besten muss ich ja noch Begriffe reindringen, wie Kostenminimierung.
Und Business Case, Business Case hilft auch nochmal.
Genau, dann Return of Invest war das auch noch so ein Begriff auf meiner BWL-Verlegung.
Ja, okay, wobei natürlich Risikominimierung finde ich schon, also es wäre für mich auch als Techniker, glaube ich, wäre das für mich ein Punkt.
Du hast ja gesagt, die Entwickler wollen, dass ihre Funktionen schnell in Produktion gehen.
Und ich würde mal hoffen und erwarten, dass die Entwickler auch wollen, dass sie eben,
vernünftig in die Produktion gehen, dass sie eben keinen Platz ausliefern.
Genau, natürlich. Also man will natürlich die Angst minimieren.
Also ich weiß jetzt noch, wo Continuous Delivery noch nicht so ein Begriff war oder so schnell auf Produktion gehen,
dann hast du ja solche Release-Zyklen gehabt von drei, viermal im Jahr.
Und das war immer mit Angstschweiß verbunden, weil so keiner so recht wusste, ob das Ding ja wirklich live gehen möchte.
Und damit sie, und ich meine, jeder Entwickler möchte, oder jeder Arbeitnehmer,
möchte eigentlich ein gelassenes Wochenende haben und nicht am Wochenende angeschweißt in der Firma sitzen und dann so eine Software halt ausliefern.
Und das heißt, da ist ja auch eine Eigenmotivation darin, okay, ich brauche halt ein Sicherheitsnetz,
wo ich dann getrost halt so eine Auslieferung machen kann, ohne dass ich da Sorge habe, dass dann mein ganzes Wochenende dabei drauf geht.
Also natürlich, die Entwickler haben natürlich da auch Interesse dran, nicht nur der Betrieb.
Wenn der Betriebschein nicht weiter weiß, wen rufen sie an, den Entwickler ja.
Richtig. Und im schlimmsten Fall ist das Wochenende,
die Ohren geschlagen und bis am Montag kommst du dann halbwegs unausgeschlafen zur Arbeit
und dann hast du dann die hunderte von Bugs, die dir dann nochmal…
Ja, genau.
Und im schlimmsten Fall, da muss zurückgedreht werden.
Ja, wenn das auch noch geht, dann ist das dann der Test, ob das Backup-System überhaupt funktioniert.
Stimmt, da kann man ja mal ausprobieren. Nein, Spaß beiseite.
Einen wichtigen Punkt finde ich dabei immer noch, wenn ich komme, ja, du hast ja schon gesagt, BWLer,
für mich ist halt auch das Thema Organisation und Prozesse ist wichtig.
Und was ich eben auch interessant finde, ist, dass über die Architektur auch Organisationsfragen quasi angesprochen
oder angetriggert werden, nämlich, wenn ich von autonomen Teams rede, wenn ich sie haben möchte,
müssen sie auch von der Architektur unterstützt werden.
Das heißt, ein weiterer Grund ist eben auch, denke ich, dass ich mit so einer CI, CD-Pipeline
und Microservices das Ding auch viel besser in den Griff kriege.
Ja, aber obwohl ja mittlerweile mit den Microservices ja auch so ein Trend geht,
die ersten haben…
Und der Hype geht wieder runter mit Microservices, die ersten haben die ersten großen Schmerzen
und merken halt, okay, vielleicht haben wir zu kleine Microservices.
Und die Frage ist ja, weil du das Organisatorische oder die Struktur der Organisationen angesprochen hast,
es gibt ja auch Organisationen, die haben pro Team drei, vier Microservices.
Die Frage ist halt, ob das dann mal nicht daraus das Team nochmal aufteilen sollte
oder einen anderen Weg geht und sagt, okay, ich fasse die drei, vier Microservices zum einen der Anwendung halt zusammen.
Ja.
Okay.
Und was ich auch mal auch interessant fand, mal einen Ansatz zu sagen,
okay, welche Architektur wollen wir haben?
Und danach ist die Organisationsstruktur an dieser Softwarearchitektur aufzubauen,
genau wegen diesem Convey Law, ja.
Weil normalerweise sieht man die Auswirkungen, okay, ich habe eine Organisationsstruktur,
die ist halt gesetzt und dann entwickelt sich das in Unterbewusstheit,
was in der Softwarearchitektur, bildet sich das wieder.
Und ein interessanter Ansatz wäre halt, das mal genau andersherum zu machen.
Ja.
Also ich finde, ich finde das auch ist was…
Das Interessante ist, ich kriege es in den Organisationen, die ich begleite oder betreue,
quasi nur so mit, dass ich Teams eben sehe, die sich nach und nach als Team formieren.
Das heißt, da sind die Unternehmen…
Also ich habe noch kein Unternehmen persönlich direkt erlebt,
was quasi die gesamte Organisation verändert hat.
Die meisten, die ich erlebe, machen das schrittweise.
Die machen einzelne Teams, die sich unterschiedlich schnell entwickeln,
die vielleicht auch in einem großen Projekt arbeiten, also auch ruhig mehrere Teams.
Aber dass ich eben eine Organisation komplett neu aufstelle,
also wirklich eine Änderung…
habe ich noch nicht erlebt und insofern, ja, bin ich mal gespannt,
wann ich das erste Mal bei so etwas mit dabei sein werde.
Ich kann mir gut vorstellen, dass es vielleicht in kleiner Unternehmen
eher funktioniert als so in großen Unternehmen.
Und dann ist die Frage halt, muss ich das ganze Unternehmen jetzt auch umbauen
oder würde es reichen, wenn ich jetzt meine IT nach dem ausrichte?
Ich meine, dass sich die IT eben entsprechend anders aufstellt im Rahmen einer Organisation.
Das ist natürlich klar, dass der Kunde sich dann daran ausrichten muss, ist auch klar.
Aber also wie gesagt, ich hatte eben…
Meinst du die IT-Organisation?
Ah, okay, gut, dann sorry, da habe ich dich nicht mehr so gut verstanden.
Ja, ja.
Jetzt haben wir die Überschrift Toolparade.
Jetzt haben wir nur über Kultur geredet.
Also insofern sollten wir jetzt mal auf die Toolparade eingehen.
Und ich habe ja auf deinen Architekturspeaker schon verwiesen.
Und der hat so eine wunderschöne Reihenfolge.
Also insofern würde ich sagen, stell doch mal ganz kurz,
oder auch ein bisschen ausführlicher, die Continuous Delivery Perlenkette da,
die du dort eben aufgeführt hast.
Ja, also wir haben uns da gedacht,
ja, wie kriegen wir das Thema oder auch die Tools am besten aufgereiht?
Und dann stellt es sich heraus,
dass das ganze Thema eigentlich in mehreren Unterthemen aufgeteilt ist.
Wie zum Beispiel, das fängt eigentlich an mit der Grundlage wie Visionskontrollsystem.
Und da geht es dazu, dass man eigentlich eine Code-Versionierung haben möchte.
Das heißt also Code im Sinne von Java-Code, PHP-Code, SQL-Code,
aber auch Konfration oder wenn man halt Richtung Automatisierung der Infrastruktur kommt,
guckt auch Code, mit dem man halt die Infrastruktur beschreibt.
Ja, und da, um das kulturelle vielleicht ein bisschen einzufangen,
das soll ja auch helfen, die Zusammenarbeit zwischen den Teams oder innerhalb des Teams zu verbessern
und auch das Nachvollziehen zu machen.
Was haben die Entwickler über die Wochen, Monate gemacht?
Nicht als Kontrollmechanismus, sondern also wie so ein Geschichtsbuch halt.
Okay, wie hat sich die Software halt in den letzten Monaten entwickelt?
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Das kann man am besten am Code selber sehen.
Dann sieht man auch die Historie, wie sich so ein Feature halt entwickelt.
Am Anfang dachte man, man nimmt den roten Weg.
Und dieser Weg wurde mit der Zeit halt grün.
Und dann kann man das wunderbar in so einer Visionskontrollhistorie halt ablesen.
Und da gibt es halt mehrere Ansätze.
Also Visionskontrollsystem wird ja zentral gehalten oder dezentral.
Das würden wir ja gleich im nächsten Schritt nochmal angehen.
Ja, können wir ja machen.
Machen wir ein bisschen detaillierter.
Das heißt, quasi Bild 1 oder auf dem Bildpunkt 1 ist, man braucht einfach ein Versionskontrollsystem.
Genau.
Also das ist auch das, was ich halt, also ich habe das zum Glück noch nicht erlebt, in
ein Team zu kommen, die kein Versionskontrollsystem benutzen.
Also wenn sie was, es kann sein, dass sie nicht den ganz modernen Tool an der Stimmung,
aber irgendein Versionskontrollsystem ist immer.
Aber ich kenne zwei andere Kollegen her, die in Projekten kommen und dann stellt sich heraus,
dass die Entwickler…
…die Sourcecodes mit USB-Sticks untereinander verteilen.
Und ja, und ich denke, also meiner Sicht ist, wenn ich das nicht im Griff habe,
dann muss ich über Continuous Delivery jetzt gar nicht nachdenken.
Ja, okay.
Das heißt, bei dieser Perlenkette, der Schritte 2 wäre dann der, der darauf dann folgt.
Genau.
Der zweite Schritt wäre dann, also wenn ich das im Griff habe, mit meinen Artefakten,
also wenn ich meinen Sourcecode halt visioniere, dass ich dann den nächsten Schritt gehe und sage,
okay, ich möchte…
…meine Auslieferungsartefakte, wo später halt die Software halt, also die Diplomate-Artefakte,
dass ich die automatisiert erstelle.
Und was viel wichtiger ist, dass sie reproduzierbar erstellt.
Also ich möchte ja nicht Fakte haben, dass ich heute ein anderes Artefakt zusammenbaue als morgen.
Und der einzige Unterschied ist, weil morgen Dienstag ist und heute Montag.
Das möchte ich nicht.
Und ich möchte auch nicht, dass bei meinen Kollegen halt ein anderes Diplomate-Artefakt rauskommt als bei mir.
Nur weil wir unterschiedliche Rechner haben.
Deswegen…
Und dann gibt es halt auch Tooling-Unterstützung.
Die mich da unterstützen, dass sie die Abhängigkeiten für mich zusammensammeln
und da auch helfen, reproduzierbare Diplomate-Artefakte zu erstellen.
Okay. Continuous Build und dann kommt Continuous Testing.
Ja, beim Testing ist das so, dann kommen wir erst in Richtung Qualität.
Und das, was auch den TPO-Vermeisten interessiert, ob die Software auch das tut, was es soll.
Und da möchte ich halt auch einmal…
Risikominimierung machen, aber auch wiederkehrende Aufgaben, Motone-Aufgabe halt wegautomatisieren von Tests.
Das heißt, ich habe dann mehrere Arten von Tests, Entwicklertests, dann Funktionaletests oder fachliche Tests.
Das, was nicht jedes Mal jemand bei Hand machen muss, sondern dass die einmal geschrieben werden und dann wiederholbar sind.
Und am besten auch so, dass das während, bevor ich mein Deployment-Artefakt halt zusammenbaue,
dass dann nochmal vorher die Tests abgelaufen werden, um so sicherzustellen, hey, das Ding, was ihr da gebaut habt, funktioniert.
Auch so, wie sich die Fachmännlichkeit das vorstellt.
Okay, das heißt, wenn ich auf diese Perlenkette gucke, das war ja der Punkt 3, Continuous Testing.
Und dann kommt der Punkt 4, den ihr gar nicht so mit Punkt 4 benannt habt, weil der wahrscheinlich so umfangreich ist,
dass man für einen eigenen Spicker schreiben musste, Continuous Inspection.
Genau, da gehen wir jetzt im Spicker nicht drauf ein, aber das gehört trotzdem noch zu der Kette.
Es geht da darum, halt statische Krutanalyse zu machen.
Ja, hört sich jetzt technisch an, es geht halt darum, man muss sich vorstellen,
wir machen halt Code-Reviews, das heißt, wenn ich meinen Source-Code geschrieben habe,
dann gebe ich es einem Kollegen und er soll so mal drüber schauen, ob der unter anderem lesbar ist.
Aber damit er sich auf, oder ob ich auf die Architektur-Prinzipien, die ich mit dem Team halt vereinbart habe, auch eingehalten habe.
Und damit er sich auf solche Sachen konzentrieren kann und nicht, ob ich jetzt den Source-Code nach bestimmten Formatierungsregeln eingehalten habe,
dass er sich damit nicht aufhalten muss, lassen wir statische Krutanalyse-Tools drüber laufen,
die mich dann schon darauf aufmerksam machen, hey, hier.
Also, hast du, verstehst du ein paar Prinzipien, was du mit deinen Kollegen aufgemacht hast?
Oder da gibt es auch Tooling, die schon potenzielle Bugs, die man, wo wir halt wissen,
dass wenn wir gewisse Sachen so schreiben, die könnten halt so potenzielle Fehler dahinter stecken,
dass dann, dass so ein Tool uns an der Stelle da schon Sachen halt abnehmen kann.
Und der Code-Review-Partner halt sich dann auf richtig wichtigere Aspekte konzentrieren kann,
wie habe ich Architektur-Prinzipien eingehalten, ist der Code lesbar, verständlich,
und solche Sachen.
Denn die Verständlichkeit kann halt keine Maschine halt analysieren, da muss jemand.
Das stimmt, aber die Maschine kann ja auch das abnehmen, was du auch eingangs ja gesagt hast,
nämlich monotone Aufgaben und einfach nur zu gucken, ob irgendwelche banalen Regeln eingehalten sind.
Das kann Maschinen sicherlich sehr gut.
Genau, und dafür setzt man das hauptsächlich ein.
Oder halt Bugs, so wie es Null-Pointer-Exception, dann gibt es halt Pattern,
die man anhand der Code-Analyse halt sehen kann, dass es Potenzial dafür gibt.
Und das kann natürlich auch eine Maschine schneller herausfinden, als mein Kollege an der Stelle.
Ja, lass uns mal bei den Tools weitergehen.
Ich habe schon ein paar andere Fragen jetzt schon so, die in Richtung Menschen gehen und wie ticken so die Entwickler.
Aber ich glaube, wir sollten erstmal die Perlenkette einmal zu Ende durchgehen.
Also wir hatten jetzt eben Continuous Inspection, das ist wie gesagt ein eigener Punkt.
Das ist der vierte und auf der Perlenkette die Nummer vier ist der fünfte Schritt,
Continuous Database Integration.
Genau, und da geht es halt darum, dass wir mit so älteren,
Werkzeugen zu tun haben, wie oder Datenbanken, wie Relational-Datenbanken.
Und da ist es halt so, dass sich die Struktur dieser Datenbanken mit Tabellen ja mit der Zeit sich auch anpassen sollten.
Tun sie aber nicht, weil sich viele halt damit schwer tun, diese gewachsene Systeme halt anzufassen.
Weil man muss dann Migrationsskripte dann schreiben und die auch dann auch verteilen.
Und dann haben sich dann solche Datenbanken sich so ein bisschen entwickelt, wie diese NoSQL-Datenbanken,
also Key-Value, also wo ich dann keine Tabellen mache.
Keine, keine, nicht unbedingt, keine feste Struktur der Daten, die ein bisschen flexibler ist.
Und da hat man sich gedacht, ja eigentlich möchte ich diese Flexibilität auch in meiner Relationalen Datenbank haben.
Und da hat sich dann halt Tooling sich entwickelt, die einen dabei unterstützen, automatisiert diese Migration zu machen,
sodass am Ende die Datenbank zu der Struktur in der Software halt passt.
Boah, ich hoffe, das war jetzt nicht so…
Ja, ich wollte gerade sagen, das klingt auch für einen BWLer so nachvollziehbar.
Also, wobei ich muss ja gestehen, dass ich auch schon ein bisschen was mit,
mit Relationalität habe.
Ja, ich wollte gerade sagen, das klingt auch für einen BWLer so nachvollziehbar.
Ja, dass ich meine Datenbank selber gemacht habe, ist schon ein paar Jährchen her,
aber zumindest sagt mir SQL was, aber okay.
Ja, okay. Ich glaube, die BWLer haben gerne Microsoft Access benutzt, ne?
Ja, da erinnere ich mich immer an die Diskussion, ob Microsoft Access eine Datenbank ist.
Ja, ich weiß.
Ich finde die nur köstlich, weil da waren so bei mir, wie gesagt, ganz zu Beginn meiner Berufszeit
saßen dann Notes-Datenbankentwickler und Access-Datenbankentwickler mit Oracle-Datenbankenentwickler
beim Mittagessen zusammen.
Und ich konnte in Ruhe essen, weil die haben sich über Datenbanken unterhalten und gestritten,
ob denn nun das jeweils Datenbanken sind.
Und das ging aber über mehrere Jahre.
Also, sie sind nie zu einer Lösung gekommen.
Und jetzt verrate ich ein Geheimnis.
Meine Relational-Datenbank-Vorlesung 1 in der Uni begann mit Microsoft Access.
Also, von daher, also wir durften in den ersten Übungen noch nicht an Oracle ran, weil der,
ich weiß nicht, ob der Übungsleiter oder der Professor gesagt hat, für die ersten Übungen,
die wir machen, da reicht Microsoft Access vollkommen aus.
Also, so viel zum Thema.
Aber Access gibt es noch, gibt es noch.
Ja, das glaube ich wohl.
Also, ich glaube auch, oder ich bin mir sicher, dass in den Unternehmen an vielen Stellen
Access noch im Einsatz ist.
Und ich sehe es jetzt gerade in zwei Projekten, wo es darum geht, Microsoft Office zu migrieren
in die Cloud.
Und jetzt fangen sie an, die ganzen Access-Datenbanken, die teilweise wichtige Geschäftsprozesse
unterstützen, dass sie die so langsam einsammeln oder einfach mal in den Überblick bekommen,
also, ich glaube, da lauert noch viel unnütze Arbeit, also unnütze Arbeit im Sinne von,
das gibt kein Business mehr wert, diese Access-Datenbanken also abzulösen, wie auch immer sie abgelöst
werden.
Also, da schlummert noch viel, viel Arbeit.
Ja, auch wenn wir jetzt ein bisschen abschweifen, aber Microsoft Access, das ist einer der Vorreiter
der Daten-IT.
Also, wenn man keine Unterstützung aus der Entwicklung kriegt, warum auch immer, es gibt
tausend Kunden, die aber eine Lösung brauchen, dann ist Microsoft Access gepaart mit Microsoft
auf Excel die Lösung für die Fachlichkeit, ihre Prozesse halt da zu automatisieren.
Ja, das ist vollkommen richtig, ja.
Gut, aber dann schweifen wir wieder zurück auf unsere, oder auf deine Perlenkette.
Der nächste Punkt ist Konfigurationsmanagement.
Ja, genau.
Da geht es schon mehr Richtung Operation, Betrieb.
Und zwar geht es darum, wie kriege ich die Infrastruktur in so einem Server schnell in
die Benutzung und am besten automatisiert.
Also, ich weiß nicht, jeder hat, glaube ich, irgendwann mal Windows.
Bei sich zu Hause selber installiert und der weiß halt, dass das sowas sehr, sehr langwierig
ist und sowas möchte man auch nicht manuell machen.
Man muss sich vorstellen, so auf dem Server ist das halt so ähnlich.
Und also gibt es da schon ein bisschen mehr und mehr Hilfen, aber also am liebsten ist,
wenn man halt auch reproduzierbare Server haben möchte, dass man das halt auch wieder
wegautomatisiert, weil die Abläufe da relativ gleich sind.
Und die Erfahrung hat gezeigt, wenn man das halt nicht wegautomatisiert, dann, man hat
zwar eine Checkliste, versucht sie auch zu pflegen, aber trotzdem sieht die der Server
im Satz ein wenig anders aus in den Annoncen und dann, ja, dann wundert man sich, dass
es auf dem einen Server funktioniert und auf dem anderen nicht.
Und auch da in dieser Stelle wieder Risikominimierung und Schnelligkeit, also eigentlich zwei Aspekte
Risikominimierung und ich will meinen Server halt schnell zur Führung stellen, deswegen
damit beschäftigt sich halt Konfigurationsmensch nicht.
Ja, da sind wir eben schon abgeschwiffen oder abgeschweift und ich muss dann immer, also
was du jetzt gerade so erzählst.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
viel Schwierigkeiten, die er aber selber dann auch
wieder lösen kann. Wie sind denn da so deine
Erfahrungen? Es ist unterschiedlich.
Also ich habe zum Beispiel mit dem Thema
angefangen, weil mich genau das angekotzt
hat. Ich wollte nicht der Held sein, denn
die Helden sterben immer am Ende der Geschichte.
Also wenn man sich so
Sagen andurchliest.
Die Helden sterben immer am Ende.
Außer bei Gene Kim.
Jawohl, der wird
dabei, ich glaube, du redest vom
Project Phoenix, ne? Ja, richtig.
Der wurde auch am Ende, also der wurde
ja am Ende mehr und mehr kaltgestellt.
Da war jetzt noch eine Stelle, wo der
Projektleiter sagte, ich glaube, Billy hieß der,
wo er sagte, ich will einen
anderen Ingenieur neben dem siebten haben,
der aufschreibt alles, was er da macht.
Nur herauszufinden,
herauszufinden, was er da macht. Ich meine, am Ende, und das ist
für mich so ein bisschen kaltstellen. Also der Held wird
da an der Stelle ja auch ein bisschen kaltgestellt.
Er wird ja auch als Problem halt angesehen. Ja, das stimmt.
Und da fing ich halt an,
meine Sachen, die ich mache,
zu automatisieren, sodass ich dann irgendwann
einen anderen Kollegen gesagt habe und sagen konnte,
hey, wenn ihr wissen wollt, wie das funktioniert,
hier ist die Dokumentation und die Dokumentation
ist halt ein Skript. Ihr seid alles
Entwickler. Das müsst ihr schon verstehen.
Okay. Also,
aber ich kenne auch in anderen Unternehmen,
dass sie auf diese Helden auch aufbauen
und die Leute fühlen sich auch erst mal
auch wohl. Ich meine, das ist total menschlich,
dass manche Leute sich gerne im Mittelpunkt
stehen und auch eine Krankheit
bekommen. Und ich meine,
so funktionieren
Sportveranstaltungen, ja? Also,
da haben wir auch einen Sieger, ja?
Einen Helden.
Der Nation. Oder manchmal elf Helden
der Nation.
Und ja, und deswegen,
das ist, und also, ich kenne beide Seiten.
Ich habe Kollegen
erlebt, die wollten dieses Heldentum
nicht und auch aktiv dagegen
gekämpft haben. Aber es gab auch
Kollegen, die das genossen haben,
dass es so ein Heldentum ist, auch wenn es denn nicht
das Wochenende über die, aber sie
konnten dann mit erhobener Brust nach Hause
gehen und sagen, zu Hause 10, ich habe
heute wieder die Welt gerettet. Also,
ich kenne beide Typen.
Also, ich glaube, das ist einfach eine Tüftel.
Und dann ist es eine kulturelle
Geschichte. Da muss das Unternehmen
für sich halt entscheiden, welche
Unternehmenskultur möchte ich hier haben? Was möchte
ich für Menschen haben, die bei mir arbeiten?
Und dann müssen sie halt Maßnahmen machen.
Vollkommen richtig. Und meine, es ist ja so,
diese Helden, die sich
selbst reflektieren, die kommen dann wahrscheinlich zu
dem Punkt, dass sie sagen, sie brauchen das nicht
mehr. Ihnen reicht ein gutes Gefühl, aber
eben nicht die andauernde Bestätigung
oder permanente Bestätigung.
Aber insofern,
das finde ich richtig. Ja gut,
lass uns mal bei der Perlenkette bleiben.
Sonst bleiben wir noch mal ab hier.
Vielleicht können wir mal einen Podcast noch über Heldentumme
machen. Ja, dann würde ich auch ein paar
Helden einladen. Nur denen würde ich vorhin nicht sagen, dass
sie als Helden eingeladen sind, denn dann würden sie
vielleicht nicht daran teilnehmen. Ja, okay.
Nächster Punkt ist die automatisierte
Verteilung deiner Perlenkette.
Auch wieder, natürlich ist die
Automatisierung wieder im Fokus.
Und da geht es halt darum, so ähnlich
gelagert wie die Bereitstellung der Infrastruktur.
Ich muss ja irgendwann meine Software irgendwann mal auf den
Server installieren.
Das heißt, im Java-Umfeld ist es halt
meistens so, oder oft ein
JAR oder ein WAR-File, ein Tomcat
oder ein Location-Server.
Mittlerweile wird ja Container-Technologie gehypt.
Beziehungsweise Hype ist ja schon wieder ein bisschen
abgeflacht, dass ich auch meine Docker-Container irgendwo
wie auf die Server verteilt bekomme.
Ja, und das will ich ja auch nicht händisch machen.
Sondern dann schreibe ich mir auch Skripte,
wo ich dann sage, hey,
auf den Server oder
irgendwo im Cluster, wenn man halt, um
die Passwort zu bedienen, Kubernetes.
Das habe ich doch gesagt. Ich wollte es mir
eigentlich vor dem Licht rüberlegen.
Reingefallen, ne?
Ja, reingefallen.
Also, lass uns mal da was vornehmen.
Das, dass ich halt meine
Software halt in Cluster verteilen möchte.
Und das will ich ja auch nicht händisch machen.
Und ja, dann schreibe ich mir Skripte, die dann
sagen, hey, verteilen wir mit den Containern bitte
auf folgenden Cluster. Beziehungsweise
macht das ja dann mein Cluster
Verwaltungs-Software, dessen Namen
wir nicht kennen wollen.
Auch wenn wir von einer Tool-Parade reden heute hier, ne?
Ja, weil ich so Leute,
die mich kennen,
ich bin bei Werkzeugen, die so gehypt werden
und Goldene Hammer für alle unsere
Probleme dargestellt werden. Ich habe da so eine,
das triggert mich immer so gleich
in so einer Anti-Hype.
Alles klar.
Gut. Letzter?
Das wäre wieder Heldentum, ne?
Auf der Tool-Seite, jawohl. Okay, ja.
Letzter Punkt ist
Continuous Controlling, Continuous Observation.
Ja, das geht dann darum,
dass ich gerne meine Software auch
überwachen möchte. Also, ich möchte ja frühzeitig erkennen,
ob meine
Software, die ich da draußen in Betrieb habe,
Blödsinn macht. Und nicht erst,
wenn das Kind schon im Brunnen gefallen ist.
Also, da gibt es das sehr klassische Monitoring.
Aber es gibt mittlerweile auch
Tools, wo ich dann so eine Vorhersage
machen kann oder schon so Anzeichen
sehen kann, hey, da könnte
irgendwas schieflaufen. Wie zum Beispiel
ein Fall war gewesen, dass zum Beispiel
wir haben ein System, der eigentlich
jeden Tag irgendwie 50.000
Anfragen bearbeitet. Und von heute auf morgen
gab es keine 50.000 Anfragen,
obwohl die Systeme alle
technische Metriken in Ordnung waren.
Und das kann man als Metrik nehmen, um zu gucken,
okay, vielleicht
ist da irgendwas falsch an der Stelle.
Vielleicht müssen wir mal gucken, was
im Umfeld des Systems irgendwas nicht
stimmt. Dass auf einmal keine 50.000
Anfragen kommen an das System, obwohl man
weiß aus der Vergangenheit,
da sollte was sein. Und eine andere Geschichte
ist auch, die Fachlichkeit
möchte, dass wir Features, Features, Features
implementieren. Und die wissen halt
nicht, ob diese Features
überhaupt benutzt werden. Und wenn sie
eine Frage ist, ja, wie finden wir es heraus,
ob der Endkunde die Sachen, die wir uns
ausdenken, überhaupt benutzt. Und dann kann ich
entsprechend, also Sensoren einbauen in der Software,
die halt Fachlichkeit misst.
Wird dieses Feature überhaupt benutzt? Wenn nicht,
dann kann man halt
dieses Feature wieder löschen, denn
ein Source-Code, was nicht existiert,
kann auch keinen Ärger machen. Und dann gibt es
auch noch Sachen, wie zum Beispiel Robustheit
abzutesten, um zu gucken,
okay, ich schmeiß mal ein paar
Sachen, also ein paar Instanzen mal
weg und funktioniert dann meine Software dann immer noch.
Also ist dann zum Beispiel
meine Software robust. Aber wie du merkst,
das ist halt nochmal ein Riesenschalt.
Deswegen haben wir das auch im Spicker
und sind wir dann auch nicht näher drauf eingegangen.
Ja, okay. Ja, wir sind jetzt eben bei der Perlenkette
am Ende. Also sind ja, wie gesagt,
sind ja acht Schritte. Ihr habt sechs auch in dem
Spicker selber noch ein bisschen
detaillierter beschrieben. Und
das ist jetzt ja, wie ich finde, eine sehr
logische Reihenfolge. Die Frage
wäre, die sich mir dann eben aufdrängt,
das, was ihr als Reihenfolge gewählt habt,
kann man das als eine Art Standard sehen?
Oder gibt es andere Standards, die ich sonst so
kenne, wie Plan, Build, Run und solche Themen?
Also gibt es quasi eine
Standardfolge, die sich etabliert hat?
Oder gibt es da verschiedene? Und
sprich, wie passt eure dann auch da rein?
Also das ist jetzt so Erfahrungswerte,
die ich halt aus den Projekten mitgenommen habe.
Das, ich brauche nicht mit,
z.B. mit automatisierten Tests anfangen,
wenn ich meinen Trostgurt nicht mehr automatisiert
gebaut kriege. Wenn ich aber mir Literatur
zu dem Thema anschaue, die gehen immer schon
in diese Richtung. Also die würden das jetzt nicht so
in der Perlenkette nicht aufzeichnen wie wir, aber
das,
die gehen schon in die Richtung, wenn ich mir
so Standardwerke anschaue, wie Continuous
Integration oder Continuous Delivery,
die fangen alle mit so einem Versionskontrollsystem
an an der Stelle. Vielleicht
einen Announcen halt, weil
nachdem, was für ein Versionskontrollsystem
oder was für ein
Pattern man innerhalb Arbeitsweise
mit dem Versionskontrollsystem, also da ändert sich,
da gibt es ja schon Unterschiede,
aber so von der Grundstruktur
würde ich sagen, das ist schon so ein
Rahmen, wo ich sage, okay, das zieht
sich eigentlich durch an der
Stelle.
Also mir wäre zumindest jetzt
nichts bekannt. Also wenn jemand draußen
was anderes kennt, das würde
mich interessieren, mal
ein anderes Facebook an der Stelle.
Ja, der wird sich bestimmt melden, aber wahrscheinlich werden
die, die was anderes kennen, diesen Podcast nicht
hören, weil sie ja schon die Experten sind.
Ja, genau. Aber manchmal
hören ja Experten
auch mal Line zu.
Ja, das stimmt. Und vielleicht machen
wir auch, weil wir das so nett rüberbringen,
vielleicht auch. Ja, genau. Also ich höre auch
mal Sachen bei Sachen, Podcastsachen, wo ich denke,
das kennst du schon und dann
kommt trotzdem immer noch eine Sache. Ach, so
habe ich das doch auch noch nicht gesehen. Also von daher.
Ja, das stimmt. Das war jetzt die
Zusammenfassung der Perlenkette. Wir sind
ja teilweise schon ein bisschen in die
Details eingestiegen
und haben wir eben auch nochmal so
uns überlegt, gibt es da
ein allgemeines Vorgehen
und ja, wie ich rausgehört
habe, ist das schon ein Standard-Vorgehen
und vor allen Dingen, was ich ganz interessant
finde, ist, dass eben auch bei dir oder bei euch
bei diesem Bild hier das Versionskontrollsystem
oder Versionskontrolle zu Anfang
steht. Ich weiß nicht,
ob das der Ausgabe 17
oder 16 war, der
State of DevOps Report, da kommt ja auch
ganz klar raus, dass erfolgreiche
IT-Organisationen eben
ein Versionskontrollsystem haben.
Insofern quasi gibt es ja auch die Bestätigung
für deine Erfahrungen aus der Praxis.
Man muss aber auch sagen, es gibt
Unternehmen, die haben ein Gesundheitskontrollsystem
und trotzdem scheitern. Okay.
Dann fehlt noch was anderes.
Ja, genau.
Wie sagen die Mathematiker?
Es ist eine ausreichende,
aber keine hinreichende
Bindung, aber nicht zwingend oder so.
Ja, genau.
Also es ist,
ja, man braucht das, aber
das ist jetzt kein Erfolgsgarantie.
Ja, okay.
Aber dann lass uns bei dem Thema
Versionskontrollsystem einfach noch mal ein bisschen ins Detail
einstrengen. Also das ist der Einstieg, hast du ja gesagt,
der Beginn ist die Basis.
Was muss ich mir dann, wenn man ein bisschen
ins Detail einsteigt unter einem Versionskontrollsystem?
Versionskontrollsystem vorstellen?
Also man muss sich das so vorstellen,
dass ich, also das ist ein Verwaltungstool,
also ich habe es für Leiden ausgesprochen,
das Verwaltungstool für Textdateien
und ich, bei jeder Änderung,
die ich an diesen Textdateien mache,
habe ich die Möglichkeit,
eine Beschreibung zu hinterlegen.
Und das heißt, ich fasse halt einen Satz von
Änderungen an verschiedenen Dateien halt
in einem Arbeitspaket zusammen und das lege ich dann ab.
Und dann habe ich halt so eine Art
Grafen, wo ich dann durch meinen Grafen
dann navigieren kann und sehen,
zu welchem Zeitpunkt welche Änderung
an diesen Dateien halt gemacht worden ist.
Und diese Textdateien, die sind halt
einmal die Grundlage für die Software,
die am Ende gebaut wird.
Aber diese Textdateien können sogar
Bildskripte sein, also Skripte,
mit denen ich meine Software halt dann baue
oder Konfigurationen von meiner
Software oder Skripte,
um die Software halt später auf die Server
zu verteilen. Datenbankskripte,
die Migration, da habe ich ja auch
im Überblick halt das erwähnt.
Und ja,
wo auch der Trend auch jetzt hingeht, dass ich auch
immer mehr auch meine Dokumentation
halt in solchen Textdateien halt
ablege, auch in so ein Visionskontrollsystem
ablege, in der Nähe meines Sourcecodes und
daraus dann halt schöne Word-Dokumente
oder PDF-Dokumente herausgeneriert.
Das würde dann Documentation
as Code halt sein.
Das klingt gut. Ja, und da gibt’s halt
ja,
also ich meine, jeder
hat sein anderes Format als Vorliebe.
Ich weiß auch halt aus anderen Projekten halt,
das ist immer die Diskussion, ja, in was schreiben
wir unsere Dokumentation? Die POs wollen,
dass wir es in Word-Dokumenten sagen,
wir machen kein Word-Dokument und
wir wollen aber irgendwas Text-laftiges
und das finden die aber nicht so schön und
die wollen gerne, oder PDF wollen die halt
haben, dann
kann man sich vielleicht ein Wiki auf sich ein Wiki eignen,
aber auch wenn es da draußen ist, keiner
hören möchte, aber Confluence ist,
seit es vom Management entdeckt worden
ist, ist es nicht mehr
schön zu benutzen. Zustimmung,
volle Zustimmung.
Also, ich weiß jetzt auch, aber
Confluence bis Vision 3
war einfach ein cooles Tool. Ich konnte da
so ähnlich schnell, musste mich
nicht um Formatierung kümmern, so, konnte einfach
runterschreiben, wie ich das damals an der Uni
mit Latex gewohnt war.
Da gab es ein paar Kurze, die ich mir merken musste,
wo ich dann, wo dann ja Wiki
oder das Confluence hat die Wiki-Seite
eine Überschrift gelegt und jetzt bin ich wie
bei Word, bin ich am Kämpfen,
dann will er diese
Eindrückung nicht so machen, wie ich möchte.
Dann kann ich auch gar nicht in Word benutzen.
Aber da wir ja selbstorganisierte Teams haben,
die ihre Tools selber auswählen dürfen.
Ja, ja, genau.
Genau, das steht in den Büchern.
Aber
wir haben ja selbstorganisierte Teams
und sind ja agil, weil wir
Jira und Confluence… Ja, das ist doch die Grundvoraussetzung.
Ich glaube, wir müssen
nachher noch bei der Veröffentlichung so einen Ironie-Modus
immer einblenden.
Okay.
Also, ich hoffe, das kann jetzt als Ironie…
Ich habe ja, es ist bei mir
genauso, dass ich diese Ironie dann, wenn man
sich gegenübersteht, dann kann man das ja sehen,
sehen oder zeigen. Also, insofern,
ich glaube aber, unsere Zuhörer werden das auch
raushören. Okay, es ist nur für
das Protokoll, das war jetzt Ironie mit den
Agilen. Also, jetzt kommt Ironie Ende,
jetzt kommt wieder Fachlichkeit. Genau, jetzt wird Fachlichkeit.
Ja, und dann
ist die Motivation, also aus BWLer
Sicht kann man jetzt fragen, was ist der
Business Value dahinter von so einem
Versionskontrollsystem? Naja, also
der Business Value ist, ich will halt die
Kosten minimieren, um
meinen Kaufkreuz an den Entwickler zu verzeihen.
Man will ja nicht das einen Entwicklern
Kaufkreuz arbeitet, sondern mehrere
Entwickler. Am liebsten im Tarn, aber
manchmal auch getrennt voreinander.
Ja, das ist dann halt die effiziente Art und Weise,
wie ich den Kaufkreuz unter meiner
Entwicklerhand beteiligt bekomme. Ja,
das bedeutet aber schon natürlich, dass
ich höre jetzt ganz klar raus, dass es
eine wichtige Voraussetzung ist, also
wird für mich jetzt auch nachvollziehbar,
bedeutet aber auch, dass bei den Teams
sich manchmal ein paar Dinge ändern müssen,
in der Art der Zusammenarbeit. Ja, auf jeden Fall.
Also, ich möchte ja zum Beispiel
schnell Feedback kriegen, wie es mein Zustand
meiner Software, die ich vielleicht später zum Kunden
rausschicken will. Das heißt, ich muss
ja auch dann, also als Entwickler muss ich
meine Änderungen, die ich mache, so schnell wie möglich halt auch
in dieses Visionskontrollsystem auch einchecken
oder auch veröffentlichen,
damit halt die nachgehenden
nachlagerte Prozesse,
also dieser Versammenbauen
halt dann auch angetriggert werden können.
Ich meine, das nützt mir nicht, dass ich zwar ein tolles
Visionskontrollsystem habe, aber alle Entwickler
checken erst so zwei Tage vor
Produktionsgang alles ein, ja. Dann
habe ich eine Zwei-Tage-Zeit, alles so
treffbar. Da habe ich den Vorteil an der ganzen Stelle
halt auch nicht. Und deswegen geht es
halt darum, auch so schnell wie möglich
seine Änderungen, lauffähige, natürlich lauffähige
Änderungen halt einzuchecken, dass
die anderen auch die Möglichkeit haben, von diesen Änderungen
halt mitzubekommen und das eventuell
auch darauf zu reagieren.
Und somit, dass
man nicht zwei Tage vor
oder Endtage vor Produktionsgang
in so einen klassischen
jetzt müssen wir alles mal integrieren
Modus. Ja, ja, klar. Also ich habe das
auf dem Spicker, da hast du ja oder habt ihr
geschrieben, Entwickler checken Code häufig ein
und letzten Endes, was
ich daraus für mich gemacht habe,
auch wenn ich in Trainings anspreche,
eigentlich täglich. Also wenn wir
die kleinen Scheibchen haben wollen, warum
soll er nicht täglich einchecken? Ja, also
das ist sogar schon, also Fanatiker
gehen sogar so weit und sagen
stündlich. Okay.
Weil du lauffähig bist,
weg von der Platte
und ab in
das Kontrollsystem. Also weg von der Platte
ist jetzt, also wirklich,
also ich habe mir
vorhin mal
gesagt, die Entwickler
haben nichts auf der Platte.
Ja, okay. Ich habe mir gerade
den Entwicklern mit der Platte vorgestellt,
wenn wir jetzt bei den Bildern schon sind, aber die
haben ja meistens lange Haare.
Gut,
jetzt ist der Ironie-Modus wieder aus,
wir schweifen schon wieder ab, aber
insofern, also häufig einen, häufig
durch die tolle Umschreibung für
täglich, halbstündlich,
halbtäglich, wie auch immer, aber wirklich häufig.
Um es dann auch wirklich
aus dem Kopf quasi raus
zu bekommen, um dann auch sich
zu fokussieren auf das, was als nächstes
ansteht. Genau.
Jetzt habt ihr auch so schön stehen, jedes Team ist für seinen
Quelltext gemeinsam verantwortlich.
Collective Ownership.
Da hätte ich jetzt auch gesagt. Ja, aber auch da hätte ich
gesagt, Menschenskinners, die Helden,
die muss ich einfangen.
Genau. Und das ist auch noch ein anderer Aspekt.
Ich meine, wir haben ja
Enterprise-Architekten und Software-Architekten
so einen klassischen,
äh, Unternehmen, ähm, IT-Unternehmen
mit eigenen Rollen, die basteln
halt eine super Architektur
und das wissen wir alles nicht, wenn, ähm,
Entwickler halt Klassen
oder, oder, oder Stellen mit
Southcode für sich beanspruchen. Keiner darf
was dran ändern und nur ändern mit deren
Absprache, dann kann ich die ganze
Architektur die Tonne drücken, weil
dann wird’s halt angefangen, weil die Leute dann gar
keine Lust haben, mit diesen Helden
oder den Owner von diesen Stellen halt zu kommunizieren.
Dann wird halt drumherum gebaut. Also man merkt,
also man kann wunderbar am Southcode,
analysieren,
auch anhand der Git-Historie,
äh, wie sich so, ähm,
Kommunikationsstrukturen halt zwischen
Entwicklern halt entstehen.
Also, ähm, das ist manchmal sehr interessant.
Das finde ich interessant, ja. Darum sage ich, also
ein Bedienungs-Kontrollsystem ist, ähm,
ist manchmal sehr
aufschlussreich, wie, ähm,
wie man halt die Kommunikation oder die
Zusammenarbeit im Team halt… Das finde ich super.
Also, sollten wir mal irgendwo über den Weg
laufen in einem Projekt, dann musst du mir das mal
zeigen, weil das würde mich auch interessieren,
wie man quasi einfach nur an Buchstaben
und an solchen Einträgen sowas erkennen
kann, ne? Ähm, da kann ich dir gleich
nochmal sagen, es geht nämlich
Tooling, was, wo man du, damit
du, ähm, Git-Historien
analysieren kann. Und
zwar, wenn ich jetzt
das auf die Schnelle hinkriege,
ach,
dann, aber es gibt ein cooles Tooling
mit, ähm, der nämlich
auf Grafen-Datenbanken aufbaut, wo
du halt die Historie halt in die Grafen-Datenbank
reinlesen kannst, einlesen kannst,
und dann dir, ähm,
mit Abfragen anschauen kannst,
nach bestimmten Pattern
angucken kannst. Aber wie das nun mal so ist,
wenn man das schnell braucht…
Du, Sandra, das ist, das ist überhaupt kein Problem.
Ich hab grad mal auf die Uhr geguckt. Wir sind jetzt schon
47 Minuten bei der Aufnahme.
Also, wir werden
es nicht mehr in der Zeit schaffen, weil da sind
ungefähr 45 Minuten. Wir haben noch so
viel vor uns. Wollen wir eine zweite,
einen zweiten Termin machen? Wollen wir eine Folge
zwei machen? Ja, können wir, können wir
machen. Gut.
Können wir auf jeden Fall machen. Und wir
haben jetzt grad das Tooling angefangen, nämlich
ähm, der Q-Assistent.
Da gibt’s, ähm, jetzt kann man, es gibt auch Vorträge
von Dirk Mahler, der sich
dann auch einen ganzen Vortrag darüber zeigt,
wie man Git-Historien halt an der Stelle
halt… Ja, super. Dann können wir das ja auch noch in die
in die Shownotes mit aufnehmen. Also,
dann stoppen wir jetzt erstmal.
Wir machen nochmal einen zweiten
Termin. Wir machen Folge zwei. Das ist
zum ersten Mal passiert, aber ich finde das super.
Und das Ziel ist ja auch wirklich, authentische
Podcasts zu machen und jetzt keine,
weiß ich nicht, keine, ähm,
vorgefertigten und marketingmäßig
aufbereiteten Podcasts.
Ähm, insofern werden wir beim nächsten Mal dann
starten oder weitermachen. Also,
starten mit dem Thema, ähm, welche
Arten der Versionsverwaltung gibt’s denn? Es gibt ja
zentrale und verteilte. Damit können
wir beim nächsten Mal sehr gut starten.
Insofern sind wir noch mittendrin in dem ersten Punkt
der Perlenkette, Versionskontrollsystem.
Ich würde sagen, für heute
sag ich jetzt erstmal vielen Dank für das
nette und aufschlussreiche Gespräch
und auf bald.
Auf jeden Fall, auf bald.