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. WIr setzen unser interessantes Gespräch aus dem ersten Teil fort.
In dieser Folge der „DevOps Toolparade“ diskutieren Dierk Söllner und Sandra Parsick über eine Vielzahl von Tools im Bereich der DevOps, angefangen bei Versionskontrollsystemen, über Continuous Build und Test-Automatisierung, bis hin zu Themen wie Transparency Inspection und Continuous Controlling. Sie gehen auf die Bedeutung der einzelnen Tools für den Entwicklungsprozess ein, diskutieren deren Einsatzmöglichkeiten und Vorteile und betrachten auch die Herausforderungen, die mit der Implementierung einhergehen. Besonders hervorgehoben werden Tools wie Git, Maven, Gradle, sowie Testing-Tools wie jUnit und Selenium.
Inhalt
- Versionskontrollsysteme
- Bedeutung von Git und anderen Systemen
- Continuous Build
- Tools wie Maven und Gradle
- Test-Automatisierung
- Einsatz von jUnit, Selenium
- Transparency Inspection
- Bedeutung und Anwendungsbereiche
- Datenbanken in DevOps
- Anpassung und Automatisierung
- Konfigurationsmanagement
- Tools wie Ansible, Puppet
- Automatisierung und Verteilung
- Einsatz von Docker und Kubernetes
- Continuous Controlling und Observation
- Überwachung und Monitoring in der Produktion
Shownotes
Die Basis unseres Gesprächs, der Architektur-Spicker
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 der Fortsetzung DevOps Toolparade. Wir hatten ja beim letzten Mal mit Sandra Pasik gesprochen über das Thema,
welche Tools gibt es im DevOps-Umfeld. Ja, und da wir so nett geplaudert hatten und so viel zu erzählen hatten, sind wir mit der Zeit insofern nicht hingekommen,
als dass wir gefühlt wirklich erstmal mittendrin stehen geblieben sind. Und wir hatten uns da ganz kurzfristig verabredet, eine zweite Folge zu machen,
einen zweiten Termin zu machen. Insofern, hier kommt jetzt der zweite Teil, die DevOps-Toolparade. Und ich würde sagen, Sandra, die Vorstellung können wir uns dann ersparen.
Und auch die Definition von DevOps. Mein Vorschlag ist, dass wir einfach ganz kurz nochmal einsteigen in den groben Überblick der DevOps-Perlenkette,
die du ja in einem Dokument sehr schön beschrieben hast, was wir ja eben auch, wie gesagt, bei den Shownotes verlinken werden.
Und dass wir dann einfach einsteigen in die einzelnen Schritte. Also insofern wäre es schön, wenn du nochmal ganz kurz einen Überblick gibst und dann vielleicht gleich einsteigst in das Thema Versionskontrollsystem.
Ja, erstmal hallo. Schön, dass wir uns wieder zusammengefunden haben. Ja, die Perlenkette besteht eigentlich aus acht Perlen.
Da sind als erste Perle zu nennen die Versionskontrollsysteme. Dann als zweites geht es dann um Continuous Build, also um Build-Automatisierung im Allgemeinen.
Dann gehen wir Richtung Test-Automatisierung. Also wie kriege ich meine Tests halt toolgestützt automatisiert.
Dann geht es Richtung Continuous Build.
Dann geht es Richtung Transparency Inspection, was jetzt im AT2-Speaker jetzt nicht genau eingegangen wird, weil dazu gab es für mich einen eigenen Speaker.
Dann geht es Richtung, eher so ein bisschen Oldschool, halt 2-3 Datenbanken. Wie kriege ich das DevOps-mäßig oder Continuous Build-Automatisiert?
Dann eher mehr OPS-lastig als Dev-lastig ist dann halt Konfrontationsmanagement.
Da geht es dann darum, wie ich das automatisiert zur Infrastruktur bereitstellen kann.
Dann geht es Richtung Automatisierung.
Dann geht es Richtung Verteilung. Also wie kriege ich stressfrei meine Software-Artifakte auf der Infrastruktur installiert.
Und dann zum Schluss Continuous Controlling, Observation. Das geht halt darum, wie kriege ich in der Produktion ein Monitoring hin und wie kriege ich die Produktion überwacht, ob ich mit meiner Software meine Produktziele oder Qualitätsziele damit auch erreiche.
Ja, und dann sind wir beim letzten Mal eingestiegen in die Versionskontrollsysteme.
Da geht es halt darum, dass ich halt meinen Code visionieren möchte.
Ja, und dann sind wir beim letzten Mal eingestiegen in die Versionskontrollsysteme. Da geht es halt darum, dass ich halt meinen Code visionieren möchte.
Janine Youtube
Potenzial
Und dann haben wir glaube ich schon ein bisschen darüber geredet, warum ich das tun sollte.
Janine Youtube
Potenzial
Da gibt es halt mehrere Möglichkeiten was zu tun, der geile heiße Scheiß, obwohl das schon ein paar Jahre alt ist.
었습니다
Und da gibt es halt mehrere Möglichkeiten was zu tun, der geile heiße Scheiß, obwohl das schon ein paar Jahre alt ist.
Janine Youtube
Potenzial
Es ist halt parenthis, also eher so eine verteilte Bildungsverwaltung und daraus resultieren sich dann ganz neue Möglichkeiten wie ich die Entwickler miteinander halt Arbeit lassen kann.
Es ist halt parenthis, also eher so eine verteilte Bildungsverwaltung und daraus resultieren sich dann ganz neue Möglichkeiten wie ich die Entwickler miteinander halt Arbeit lassen kann.
Und daraus resultieren sich dann ganz neue Möglichkeiten, wie ich die Entwickler miteinander halt arbeiten lassen kann. Da werden ja solche Sachen gerne genannt wie Feature-Branch-Unterstützte-Entwicklung oder die Teams sollen mit Pool-Requests halt arbeiten.
Und ja, das sind halt so Möglichkeiten, die damals mit Subversion oder mit dem zentralen Versicherungsverwaltungssystem eher schwer zu realisieren waren. Das heißt, das Tool gibt halt in dem Sinne ganz neue Möglichkeiten auf, wie man die Zusammenarbeit zwischen den Entwicklern halt vorantreiben kann.
Vorantreiben im Sinne von zentraler Verwaltung und verteilter Verwaltung, richtig?
Genau, genau. Also der Vorteil war, also was ich persönlich als Vorteil sehe, den Wechsel von den zentralen Versicherungssystemen.
Also Versicherungsverwaltung, ich habe halt bei der zentralen Versicherungsverwaltung habe ich immer nur einen Aufschnitt auf meiner Platte.
Das heißt, wenn ich zum Beispiel die Historie sehen möchte, was da für Änderungen gelaufen sind, dann muss ich immer mich mit dem Server halt verbinden.
Das ist jetzt bei mir immer meistens ein Problem, weil ich jetzt als Berater unterwegs bin, das heißt, ich arbeite gerne auch aus dem Zug heraus.
Naja, und ich will jetzt kein Bahn-Bashing machen oder deutsche Infrastruktur-Bashing machen, aber manchmal kommen wir halt da keine Internetverbindung an.
Ja, okay.
Naja, dann ist es halt ein bisschen blöd, wenn man jetzt vielleicht eine andere Vision braucht vom Code, dass man da keinen Zugriff hat.
Und das habe ich mit Git halt nicht oder mit anderen verteilten Versicherungsverwaltungen, weil ich mir immer an die komplette Kopie des Repositories auf meiner Platte halt ziehe.
Das heißt, wenn ich mal auch im Tunnel bin, im Zug, also die Historie habe ich immer bei mir auf der Platte.
Das ist so einer der Vorteile, was ich halt so sehe.
Aber ich habe mir auch sagen lassen, das ist ein Berater-Problem.
Das muss ich unbedingt jetzt auf allen Entwickler zu treffen.
Von daher, ja, aber gut, vielleicht kann man es als ein Berater-Problem halt ansehen.
Ja, okay.
Wobei, Berater-Problem oder eben überhaupt das Problem von, auch vielleicht bei einer eher schwachen Infrastruktur, wenn man vielleicht in Teilen der Welt arbeitet, die auch in einem Büro nicht gut angebunden sind.
Ich glaube, das ist wahrscheinlich in der IT-Welt wahrscheinlich eher selten, aber könnte ja theoretisch auch sein, wenn man mal absieht von deinem persönlich.
Ich glaube, das ist wahrscheinlich ein Berater-Problem mit der deutschen Infrastruktur, dass man so ein bisschen globaler sieht.
Also insofern die Frage fällt an der Stelle, wenn man Teams hat, die vielleicht an einem Ort zusammenarbeiten, also wirklich räumlich beieinander oder nah beieinander sind, gibt es da Unterschiede?
Also aus der technischen Sicht zwischen der zentralen und der verteilten Versionsverwaltung?
Ja, also es gibt das schon, denn wenn ich halt bei der zentralen Versionsverwaltung, also bei der, oder fangen wir anders an,
bei der zentralen Versionsverwaltung habe ich den Vorteil, ich habe so einen, ich sage mal, für Laien gesprochen, so einen Zwei-Phasen-Commit.
Das heißt, ich visioniere meine Änderungen, die ich mache, halt erstmal bei mir lokal und davon bekommen erstmal meine Kollegen halt nicht mit.
Aber ich habe für mich persönlich dann nochmal so einen Sicherheits-Snap von wegen, okay, wenn ich jetzt experimentieren möchte oder was ausprobieren möchte,
ich kann immer wieder auf einen funktionierenden Stand zurückgehen.
Und wenn ich dann sicher bin, dass die anderen von meiner Änderung was mitbekommen sollen, dann, das nennt sich das bei Gips,
dann pushe ich meine Änderungen.
Dann habe ich die Änderungen halt in das Remote-Repository, wo alle halt drauf zugegriffen haben.
Wenn ich das jetzt mit Subversion machen möchte, das geht erstmal mit Hausmitteln von Subversion nicht,
denn da ist ein Commit jedes Mal, ich pushe das wirklich ins Repository, wo alle anderen halt, ins Remote-Repository, wo alle anderen halt die Änderungen gleich mitbekommen.
Das heißt, da habe ich den Nachteil, also kann man auch vielleicht sagen, okay, das ist vielleicht wieder so ein persönlicher Entwickler-Ding,
wie man halt arbeitet, aber ich habe da nicht die Möglichkeit, dass ich fein Granulare halt,
arbeiten kann, dass ich halt kleinere Schritte machen kann in meiner Historie, sondern ich habe da immer so solche Big Bang-Commits.
Und da ist leider, würde man sagen, okay, wo ist das Problem?
Das Problem ist halt, wenn ich Fehler suche und mache.
Das ist halt einfacher, kleine Änderungsunterschiede zu analysieren, als wenn ich halt große Änderungsschritte mir analysieren muss.
Und das wäre zum Beispiel jetzt auch so ein Vorteil, wo ich sage, okay, so ein verteiltes Versionsverwaltungssystem,
könnte man auch einsetzen, auch wenn man halt vielleicht lokal zusammensitzt mit den Entwicklern vor Ort.
Ja, gut. Wobei natürlich dann letzten Endes es ja immer in der Entscheidung des Teams liegt, wie sie arbeiten.
Genau.
Und insofern, würdest du sagen, dass eine der beiden Versionen oder der eine der Arten, mit Versionsverwaltung zu arbeiten,
einen höheren Reifegrad des Teams erfordert oder ist das eigentlich egal?
Also ich habe die Erfahrung gemacht, das ist eigentlich egal.
Also das ist eigentlich…
Also wenn ein neues Versionsgetreu-System irgendwo eingesetzt wird, dann empfehle ich halt immer das verteilte Versionsverwaltung,
weil ich kann die Konzepte einer zentralen Versionsverwaltung auch mit einem verteilten Versionsverwaltungssystem halt simulieren.
Ich habe aber zusätzlich halt die Möglichkeit, zukünftig, wenn ich meinen Workflow halt ändern möchte,
dass ich dann mehr Spielraum an der Stelle habe.
Und dann ist halt auch diese, dass ich halt diese Persönlichkeiten, wie jemand arbeitet, halt unterstützen kann,
wo ich sagen kann, okay, wenn du Feingranen…
Wenn du Feingranen oder arbeiten möchtest, dann kannst du es damit tun.
Wenn jemand aber große Komiz machen möchte, warum auch immer,
also das kann man sich sogar streiten, ob da irgendwelche Vorteile gibt,
der hätte das mit einem verteilten Versionsverwaltungssystem auch noch die Möglichkeit.
Also ich sehe, also gerade bei neuen Projekten, also wenn es die überhaupt gibt,
sehe ich da keine große Vorteile, so ein zentrales Versionsverwaltungssystem halt einzuführen.
Ja, okay.
Wenn ich jetzt mal so kurz zusammenfasse, der Punkt 1 war ja Versionskontrollen.
Versionskontrollsystem.
Insofern ist es natürlich wichtig, überhaupt erstmal ein solches Versionskontrollsystem einzuführen.
Ja, natürlich.
Das war dann die wichtigste oder die Basisentscheidung.
Also ich bin dann ein bisschen radikal und sage,
also wenn jemand ein Softwareentwicklungsprojekt starten möchte ohne Versionskontrollsystem,
dann soll er es direkt lassen.
Ja, okay.
Also ich bin auch, ich habe das auch beim letzten Mal auch schon gesagt,
ich habe das selbst bei kleinen Teams erlebt.
Nun bin ich ja kein Entwickler.
Aber selbst bei ganz, ganz kleinen Teams,
sofern ich bei den Entwicklern einen gewissen Reifegrad, einen gewissen Anspruch festgestellt habe,
haben selbst die mit zwei, drei Entwicklern genauso gearbeitet.
Also Versionskontrollsystem und haben für sich, für ihre Arbeit einfach den Vorteil gesehen,
das, was du ja auch alles entsprechend schon dargestellt hast.
Also ich glaube, das hängt dann wirklich von dem Reifegrad, von dem Anspruch der Entwickler ab.
Ja, also ich meine, wenn ich Privatheitswachen mache,
also ich gucke die Milchhäuser wieder.
Das ist ja auch sehr, sehr praktikal, weil ich halt wahrscheinlich Techie bin.
Aber wenn ich zum Beispiel halt einen Artikel schreibe, ich mache das halt nicht in Word,
sondern halt in so, also wir leiden gesprochen, in so einer Textdatei.
Und dann bin ich die Sachen auch in einen lokalen Git-Ribs-Tutorials am Ablegen.
Das, wenn ich halt mal zu einem zusätzlichen Stand zurückspringen möchte,
dass ich dann, wie ich das von meinem Source Code halt gewohnt bin,
dass ich da auch in meinen Artikeln halt nochmal in Visionen zurückspringen kann.
Mhm, ja.
Also das ist halt…
Mhm, ja.
Also das kann man jetzt sagen, okay, sie macht das, weil sie halt Entwicklerin ist
und das bestehende Tooling halt benutzen möchte.
Aber das wäre halt auch an der Stelle eine Möglichkeit, das zu tun.
Also, oder wenn man alleine an einem Softwareprojekt arbeitet.
Mhm.
Also das ist das Erste, was ich halt mache, auch wenn das kein Remote-Ribs-Tutorial ist
oder auf GitHub ist, aber ich habe zumindest immer ein lokales Ribs-Tutorial,
wo ich dann eine Visionierung auf dem Laptop mache.
Ja, okay.
Also für diesen Punkt Versionskontrollsystem, denke ich, sind ein paar Punkte wichtig,
wichtig ist, dass die Entwickler eben entsprechend den Code häufig einchecken,
regelmäßig einchecken und regelmäßig heißt nicht einmal im Jahr,
sondern in einem sehr viel kürzeren Zeitraum,
dass sich die Entwickler oder die Teams für ein entsprechendes Tooling
und für einen entsprechenden Workflow entscheiden und eben ihre Arbeitsweise daran anpassen.
Denn je nachdem, ob ich nun verteilt oder zentral arbeite,
muss ich ja auch als Entwickler meine Arbeitsweise darauf abstimmen.
Und ich denke, der dritte Punkt ist,
der dritte Punkt, den du auch in deinem Spicker so beschrieben hast,
ist, dass das Team für den Quelltext gemeinsam verantwortlich ist,
also das Thema, was du hast es genannt, Collective Ownership.
Das, denke ich, sind so die drei wichtigen Punkte für dieses Thema.
Doch, ja. Und genau.
Und das ist halt Basis, wenn wir jetzt zum zweiten Punkt rüberkommen,
dann ist es halt eine Basis, um halt zum Beispiel den Bildlauf zu automatisieren.
Also mit Bildlauf ist halt gemeint, okay, jetzt habe ich meinen Softcode,
aber der Softcode alleine macht noch keine lauffähige,
halt, Software, sondern die muss halt erstmal übersetzt werden,
dass so eine Maschine überhaupt versteht, was sie da tun soll.
Und das möchte ich halt nicht manuell machen,
sondern dann habe ich halt auch Skripte, die das entsprechend automatisiert tun.
Das heißt, dann gehe ich halt einen Schritt weiter und sage, okay,
dann kann ich ja das Bild weiterführen und sagen, okay,
ich kann ja in meinem Visionskontrollsystem ja drauf räuchen.
Hat sich da was geändert an dem Stand des, des Hostcodes?
Und wenn ja, dann habe ich irgendetwas, das hat ja meistens so eine continuous integration,
CI-Maschine oder CI-Server genommen und der dann sagt,
aha, da hat sich was geändert, dann kompiliere ich das alles mal durch,
also übersetze das alles mal in lauffähige Software und gucke,
ob da irgendwelche Kompilierungsfehler, also Sonntagsfehler zum Beispiel, vorhanden sind.
Und somit habe ich ein schnelles Feedback auch Richtung Entwicklung
und vor allem, wenn ich, wenn da mehrere Entwickler haben,
miteinander arbeiten und zu gucken, wenn ich die Sachen zusammenführe,
ob das Ganze überhaupt noch baubar oder kompilierfähig halt an einer Stelle ist.
Ja, und das können die Entwickler ja auf ihrem Rechner dann auch machen.
Ja, und das können die Entwickler auf ihrem Rechner dann auch machen.
Ja, und das können die Entwickler ja auf ihrem Rechner dann auch machen.
Ja, genau, also das ist auch das Ziel.
Also das, was ich auf so einem zentralen Server ablaufen lasse,
das muss auch bei mir lokal halt funktionieren.
Und da gibt es halt gängige Tools, also das muss man dann nicht mit Skripten,
das heißt nicht, dass ich jetzt irgendwelche Tools selber schreiben muss,
sondern dann nämlich bewertete Tools.
Also ich persönlich komme jetzt aus der Java-Ecke
und dann so was ist dann so wie Maven, Gradle,
sind dann so die gängigen Tools, die man dann einsetzt,
um sowas halt automatisch zu machen.
Es gibt natürlich dann auch weitere Möglichkeiten, das zu erweitern,
aber das können wir im nächsten Punkt nochmal tiefer eingehen.
Naja, auf jeden Fall, die Idee ist halt, dass, ich sag immer,
die Wahrheit liegt im Bild-Tool.
Also wir haben manchmal so Quellen, also wir haben ja,
wir arbeiten ja nicht mit so Text-Editoren,
sondern mit ein bisschen ausgereiften EDEs,
also Integrated Developer Environments.
Das heißt, da ist halt auch ein Compiler im Hintergrund,
der guckt, ob das halt alles läuft.
Manchmal haben wir aber die Effekte,
dass die einen halt gerne halt vom Hersteller A nehmen,
die anderen gerne vom Hersteller B
und da gibt es unterschiedliche Auswirkungen,
wie sie auf den Source-Code reagieren, die man schreibt.
Und dann sagt man aber, okay, ist mir egal,
was für eine Idee oder Text-Editor du nimmst,
die Wahrheit liegt halt in diesem Bild-Tool.
Das heißt, wenn das Bild-Tool sagt, hey, das ist kompilierbar,
daraus kann ich halt ein Software-Artefakt bauen,
dann ist das die einzige Stelle der Wahrheit,
ob die Software überhaupt kompilierfähig ist oder nicht.
Also ich weiß nicht, wie oft ich schon in Meetings gesessen habe
und dann hieß es, ja, bei mir in Eclipse funktioniert das sehr schön,
aber Maven meckert und wenn Maven meckert,
dann meckert halt auch das auf dem zentralen Server
und dann kann ich das halt nicht ausliefern.
Das heißt, jeder kann sein persönliches Werkzeug nehmen,
also für mich ist ein Text-Editor halt ein Werkzeug
und man muss sich halt nur auf das Bild-Tool einigen
und das ist dann die Quelle der Wahrheit,
ob die Software baubar ist oder nicht.
So für mich als Nicht-Techie, wie viele Tools gibt es denn in dem Umfeld,
die relativ gleich sind von der Funktionalität?
Also sprechen wir davon, dass ich vielleicht nur ein, zwei Tools habe
oder habe ich auch wirklich eine Auswahl von, weiß ich nicht,
neun oder zehn Tools, die wirklich eigentlich relativ nah beieinander liegen,
was die Funktionalität angeht?
Im Umfeld sind mir also drei, vier.
Also wenn ich auch die X-Routen nehme,
sind mir bis zu zehn Tools bekannt.
Ich glaube, namentlich würde ich fünf oder sechs aufzählen können.
Also dann gibt es halt, dann habe ich ja nicht so Java,
sondern halt noch andere Sprachen, die auf der Java-Plattform aufbauen.
Die bringen dann manchmal auch eigene Bild-Tools mit.
Also dann haben wir schon wieder, das muss mal 20 sein.
Und wenn ich dann sage, okay, ich möchte nicht Java benutzen
oder aus der JDK-Welt rausgehe, sondern C-Shrat nehme,
gibt es wieder eigene Bild-Tools.
Wenn ich halt Web-Frontend machen möchte,
dann arbeite ich meistens mit JavaScript.
Dann halt das nicht Bild-Tool, sondern Task-Run,
aber vom Prinzip her haben sie so eine ähnliche Aufgabe,
nur dass ich bei JavaScript das nicht kompilieren muss,
sondern halt in andere Checks halt laufen lassen möchte.
Ja, und dann gibt es halt gerade im JavaScript-Umfeld gefühlt,
tauchen da jede Woche zwei neue Tools auf in jedem Bereich.
Also da, also ich glaube, da kann man sich wochenlang darüber unterhalten.
Also das ist halt…
Okay.
Dann bleiben wir bei unseren 45 Minuten hier.
Okay, gut.
Sandra, die Frage ist ja bei den Teams immer Selbstorganisation.
Wenn ich mich richtig eben verstanden habe, hast du gesagt,
Continuous Build ist wirklich eine Stelle, wo ich eigentlich die Basis schon lege
für ein vernünftiges Continuous Delivery.
Wie stark können denn die Teams sich hier selbst organisieren?
Das heißt, wie stark oder wie weit kann ich ihnen Autonomie zugestehen
bei der Auswahl ihrer Tools?
Also wenn man jetzt den neuen Klassiker, also Microservice nimmt,
dann haben die Teams, ist es davon abhängig,
ein bisschen wie Technologie-Stack aussehen.
Das heißt, wenn ich Teams habe und sage, okay, die dürfen die Technologie-Stack selber aussuchen,
dann bin ich auch gezwungen, denen die Freiheit zu geben,
dass sie sich auch das Build-Tool auswählen.
Das Build-Tool muss halt so zum Technologie-Stack halt passen.
Das heißt, in meinen Augen macht das wenig Sinn, Maven einzusetzen,
nur weil das irgendwo zentral mal festgelegt ist.
Und die Jungs und Mädels programmieren in Python oder in JavaScript.
Vielleicht wird das sogar technisch, in dem Fall bei Python weiß ich es sogar nicht,
aber bei JavaScript würde es sogar bis zu einem gewissen Grad gehen.
Aber ich würde mich ja trotzdem beschneiden, weil die Welt da draußen,
die JavaScript oder Python benutzen, die nutzen halt ein anderes Build-Tooling
oder ein Task-Run in dem Sinne.
Das heißt, an der Stelle würde das aus meiner Sicht wenig Sinn machen.
Die andere Überlegung ist,
wenn aber die Teams ähnliche Technologie-Stacks nehmen,
also zum Beispiel die Teams nutzen alle Java,
dann macht das schon aus meiner Sicht schon Sinn zu sagen,
okay, dann lass uns ein einheitliches Build-Tool an der Stelle nehmen.
Oder man muss wirklich Argumentationen finden,
warum man dann an der Stelle halt abweichen sollte.
Und das ist jetzt nicht, weil man die Farbe des Logos vom Build-Tool halt schöner findet
oder die blieb der Argumentation.
Das wird gerade auf Konferenzen gehypt.
Deswegen…
Deswegen muss man das jetzt machen.
Ja, okay.
Also im Prinzip schon, dass die Teams es selber entscheiden sollten oder müssten,
aber es hängt auch stark von der Technologie ab.
Ja, genau.
Und dann ist es halt auch ein Maß.
Da muss man halt gucken, welche Vorteile bringt das für den Team,
sollen sie halt beim selben Technologien abweichen.
Und wenn das halt, was ja auch mal vorkommt,
dass die Entwickler hier Spieltrieb halt da irgendwie ausleben wollen,
dann sage ich, okay, dann sagt man vielleicht Zeit für sogenannte Teams,
für sogenannte Pet-Projekte,
den Entwickler einräumen,
dass sie sich da ihre Spieltriebe ausleben können
und das natürlich in Produktionsquotient ausprobieren.
Wenn ich so die Teams anschaue, die ich sehe,
wie gesagt, bin ja kein Entwickler,
bin ja eher der Betriebswirt.
Was ich aber als Riesenvorteil sehe, ist,
du hast ja auch gerade den Spieltrieb angesprochen von den Entwicklern,
das wollen wir nicht auf die Entwickler immer so draufschlagen,
aber was ich eben als Vorteil sehe, ist,
dass wir wirklich eine zentrale Quelle haben, wo es funktioniert.
Und eben nicht jeder sagt ja, bei mir auf meiner Maschine funktioniert es,
sondern dass ich durch dieses Continuous Build einkomme,
dass ich wirklich eine zentrale Stelle habe,
wo es dann schon sehr früh funktioniert
oder sehr früh überprüft wird, ob es funktioniert
und nicht auf den einzelnen getunten Maschinen der Entwickler.
Ja, genau.
Also das ist halt der Vorteil, warum man das einführen möchte
und warum man auch da investieren sollte.
Also ich hatte mal einen Kunden gehabt, der meinte,
der sah die Auslieferung so aus,
dass sie sich halt eine Woche vor geplantem Auslieferungstermin
einen Rechner gesucht haben, bei dem in Eclipse
die Software halt gebaut wurden konnte.
Und ja, und da kam ich dann mit so einem Build-Tool daher,
habe das mal automatisiert
und dann hat man Release-Zeiten von einer Woche reduziert,
halt erst mal auf den Tag her.
Also dass man nicht mehr gezwungen war,
also eine Maschine zu suchen,
wo alles halt kompilier- und baubar war, ja.
Also das ist jetzt nicht nur in der Theorie,
sondern in der Praxis habe ich das selber so erlebt.
Okay, gut.
Wenn wir diesen Punkt jetzt so langsam zum Abschluss bringen,
vielleicht eine Frage noch.
Was sollte man denn beachten,
wenn ich das Thema Build automatisieren möchte?
Gibt es ein paar Punkte, die man da beachten sollte aus deiner Sicht?
Ja, also wenn ich mich auf ein Build-Tool einige,
dann soll ich nicht versuchen, gegen Best Practices mich zu wehren.
Und nur weil ich halt, ja,
denke, dass eine bestimmte Struktur oder Anwendungsfälle
oder Lifecycle mir besser gefallen,
aber das Build-Tool unterstützt das nicht,
weil die eigentlich ein ganz anderes Konzept dahinter stellen.
Dann sollte ich nicht gegen dieses Build-Tool halt ankämpfen
und das so biegen, wie das für mich passt.
Denn die Erfahrung zeigt, das bringt nur Schmerzen.
Ich kann wenig Support von der Community bekommen,
sondern dass ich mich dann auf die Idee
und auf das Konzept des Build-Tools mich dann auch aufstütze.
Okay.
Das sind schon solche einfache Geschichten,
wie zum Beispiel die Ordnerstruktur für meines Projektes aussehen soll.
Also zum Beispiel bei Maven ist das so,
dass das halt eine bestimmte Ordnerstruktur halt vorgibt.
Die Erfahrung zeigt halt, wenn ich mich halt bestimmte Konventionen halt halte,
habe ich dann in meiner täglichen Arbeit halt weniger Schmerzen.
Das heißt, ich kann mich dann wirklich auf Feature-Entwicklungen konzentrieren
und dann nicht wieder mit, mich tagelang mit dem Build-Tool beschäftigen.
Ich finde das interessant, weil wenn ich das übertrage auf das Thema Business,
da haben wir eigentlich das Gleiche,
dass eben ja viele, wenn ich jetzt mal in ganz große Parallele ziehe,
SAP oder überhaupt ERP-Projekte,
dass die auch dann ihre Schwierigkeiten haben,
wenn sich die Personen, die mit den Tools arbeiten sollen,
eben nicht umstellen wollen.
Wenn ich also anfange, die Standard-Tools zu verbiegeln,
um individuelle Abläufe zu ermöglichen.
Und das klingt hier ja für mich genauso.
Genau, ich fand deswegen…
Standardisierung.
Genau, genau.
Aber da ist halt beim Business,
da kann man natürlich auch hinterfragen,
ist es sinnvoll, dass ich meinen Geschäftsprozess halt an die Software,
nur weil da das SAP draufsteht, anpasse?
Dann wird daraus für mich eher auch ein Schuh, wo ich sage,
okay, ist es nicht sinnvoll, dass ich mir vielleicht eine Software bauen lasse,
die genau auf meinen Prozess halt abwählt?
Ich meine, da gibt es genügend Startups, die das halt dann machen.
Die kaufen kein SAP-System, sondern die haben halt eine Idee
und bauen halt die Software, die zu ihren Geschäftsprozessen halt passt.
Aber diese Idee lässt sich jetzt…
Also bevor jemand sagt, man soll sich eigene Build-Tools schreiben.
Nein, also das kann man nicht zurückführen auf den Bildverlauf,
denn wenn ich eine Java-Webanwendung bauen muss,
das läuft immer eigentlich nach dem selben Muster ab.
Also da muss man jetzt nicht unbedingt zwingend sein eigenes Bild holen.
Also ich weiß, Google und Facebook machen das.
Die bauen ihre eigenen Tools.
Aber dann kommt dieser Standard-Beraterspruch halt.
Nicht jeder ist halt Google, oder?
Google oder Facebook an der Stelle.
Wobei wir auch jetzt die Diskussion ausführen könnten,
wenn wir mehr Zeit hätten,
ob auch nicht ein Auftragsabwicklungsprozess im Business überall gleich aussehen könnte.
Es gibt vielleicht einzelne Ausstiege, die ein bisschen unterschiedlich sind,
aber das würde uns wahrscheinlich wieder vom Thema abführen
und dann müssen wir uns auf die dritte Folge einfach verabreden.
Also insofern, ich würde, wenn du jetzt nicht ganz Wichtiges noch hast,
Thema Continuous Build verlassen und die nächste Perle zupfen.
Die nächste Perle Continuous Test.
Die nächste Perle Continuous Testing.
Ja.
Ja, das ist leider immer noch ein leidiges Thema bei uns in der Softwareentwicklung, das Testen.
Man fängt ja irgendwie mit manuellen Tests halt an,
aber das wird bei kleinen Projekten, da ist der Aufwand relativ noch überschaubar.
Je größer das Projekt wird, desto größer sind dann die manuellen Tests.
Und dann merkt man halt auch, wenn man die Sachen immer wieder dasselbe tut,
der Mensch ist einfach nicht dafür geschaffen,
wiederholbare Abläufe in derselben Qualität abzuliefern.
Das kann halt eine Maschine halt eindeutig besser.
Und da ist halt die Idee entstanden, okay, wieso kann ich meine Testabläufe,
wenn das immer wiederkehrend ist, auch nicht automatisieren.
Und ich meine, das kann man halt auch mit Sourcecode abwickeln.
Also ich schreibe meine Tests in derselben Sprache, wie ich auch mein Produktionscode halt abteste.
Und dann fange ich halt auf verschiedenen Ebenen halt an.
Also bei Entwicklertest, das heißt, das sind Tests, was die Entwickler selber schreiben.
Und da kommen auch dann verschiedene Methoden mit rein, wie man das macht.
Also ich persönlich bevorzuge Test-Driven-Development.
Das heißt, bevor ich mit meinem Produktionscode anfange zu schreiben, schreibe ich erstmal den Test dazu
und gucke dann, okay, passt der Produktionscode zum Test?
Und das hat für mich dann als Entwickler so ein Sicherheitsnetz.
Das heißt, wenn ich dann auch mal Änderungen mache, weiß ich immer,
im Hintergrund laufen irgendwelche Tests ab, die gucken, ob das, was ich tue,
ob das keine Auswirkungen hat auf das Gesamtverhalten vom System.
Ja, und da gibt es halt verschiedene Stufen.
Also ich habe ja vorhin den Entwicklertest genannt.
Dann teste ich vielleicht die Interaktion zwischen den Systemen.
Das kann ich auch automatisiert tun.
Der Tester an sich, der fängt auch mit automatisierten Tests.
Ich kann UI-Tests auch automatisieren, obwohl sie recht teuer sind in der Ausführung.
Das heißt, dann muss man auch ein bisschen gucken, ob ich wirklich alles damit abtesten möchte
oder ob ich das nicht vielleicht für den nicht so kostspieligeren, also eher Richtung Entwicklertest,
das dann runterskaliere.
Und dann trotzdem bleiben immer noch manuelle Tests.
Meiner Ansicht nach haben sie Sinn, wenn das solche explorativen Tests sein sollen.
Das heißt, wenn ich einfach mal ausprobieren möchte, wie die Software sich verhält,
wenn der User etwas macht, was man nicht erwartet.
Also wenn er die Software benutzt, nicht so, wie es im Handbuch steht.
Also beziehungsweise kommt eher das dazu.
Ich meine, wer liest heutzutage Handbücher?
Wenn es sie noch gibt.
Ja, genau.
Wenn es sie überhaupt noch gibt, ja.
Und im Endeffekt ist das ja so, man macht die Software auf und klickt erstmal mit drauf rum,
gucken, wie die darauf reagiert, ja.
Und da erwartet man trotzdem, dass die Software halt robust läuft.
Und das sind für mich so Tests, die man am besten halt manuell mal durchlässt,
um zu gucken, wie reagiert die Software, wenn man etwas Unerwartetes tut.
Ja, wenn ich jetzt den Bogen mal spanne vom Continuous Build zum Continuous Testing,
in beiden Fällen habe ich ja den Fall,
dass die Entwickler eben auf ihren lokalen Rechnern das durchführen.
Das heißt, die machen sowohl das Build, das hatten wir ja besprochen, wie auch das Testen.
Und damit kriege ich ja auch noch mehr Qualität in den gesamten Erstellungs- und Auslieferungsprozess.
Genau.
Also ich habe dann mehr Feedback-Information.
Das heißt, ich weiß dann auf der einen Seite, okay, ich habe ein Source Code,
was auf jeden Fall sonntags fehlerfrei ist, weil es kompilierfähig ist.
Und mit den Tests habe ich die ersten Indizien dafür auch, dass die Software auch das tut,
was man von ihr erwartet.
Und gerade die Entwickler-Tests werden auch in diesen Build-Tools halt mit eingebunden.
Und das heißt, wenn ich dann mein Build starte, dann laufen zumindest auch noch Entwickler-Tests mit.
Und wenn diese Entwickler-Tests erfolgreich sind, dann wird daraus auch ein fertiges Software-Artifakt gestellt,
die ich dann später halt zum Beispiel meinen Testern, damit sie zum Beispiel UI-Tests
oder Explorationstests halt machen können, dann zur Verfügung stelle.
Also da unterstützt ihr mich.
Also dann kann ich die Tests, den Testlauf schon überprüfen.
Dann kann ich die Tests, den Testlauf schon in meinem Build mit rein integrieren.
Wenn ich mal überlege, wenn ich dahin komme, dass die Entwickler alle Tests wirklich codieren,
also alle Tests entwickeln und automatisieren, dann habe ich damit ja auch den Vorteil,
dass ich eben diese Verschwendung von ich mache es immer wieder manuell vermeide.
Im Sinne von Lean und von Kanban, dass ich eben einfach wirklich Dinge nur einmal durchführe
und danach werden sie eben automatisiert und ich muss es eben nicht immer manuell tun.
Genau.
Es gibt ja auch Stimmen, die sagen halt, ja, warum soll ich jetzt teure Entwicklerstunden
dafür investieren, dass ich Tests schreibe?
Dafür habe ich ja meine Tester.
Also ich habe auch schon mal Kunden erlebt, die gesagt haben, die Entwickler-Tests dürfen
in Entwickler geschrieben werden, die werden nachgelagert von unseren Testern geschrieben.
Naja, und das Problem, also ich finde halt, dass da immer, also Sala sagt nicht, dass die Tester,
die haben auch immer ihre Daseinsbefugnis, aber die sollten halt andere Sachen testen.
Als was ich als Entwickler, also die trivialen Geschichten kriege ich auch als Entwickler selber hin,
beziehungsweise ich weiß, ich sehe ja, kriege dann direkt beim Wickeln auch das Feedback von wegen,
das, was ich mir ausdenke, funktioniert das überhaupt?
Und wenn ich diese Tests nicht schreiben dürfte, wie würde ich das sonst machen?
Ich würde dann vielleicht trotzdem auf der Kommando-Line irgendwie starten und mal mich selber durchklicken,
um zu gucken, ja, tut es überhaupt das, was es tun soll?
Und dann kann ich die Zeit auch nutzen, um halt diesen Tester zu schreiben.
Also jetzt für Lioness versucht zu erklären.
Ja, ja.
Oder ich verliere natürlich die Geschwindigkeit, wenn ich also dann als Entwickler gar nicht teste,
weil das die Tester nachher machen, dann kriege ich ja die Rückmeldung, das Feedback, wo du immer mehr darauf hinweist,
eben sehr viel später oder zu spät.
Also natürlich kann ich das durchrechnen und sagen, so eine Entwicklerstunde ist teurer als eine Testerstunde.
Das ist aber, wie ich finde, dann auch eine relativ kurzfristige Betrachtungsweise.
Also was ich sehr cool fand in meinem Projekt, das habe ich dann vom QA-Team auch direkt als Feedback bekommen,
die haben mir gesagt, also sie wissen, wenn sie ein Feature von der Sandra bekommen,
dann die Happy Cases, die werden auf jeden Fall laufen, die können sich dann halt auf andere Sachen spezialisieren, gucken,
weil sie wussten halt, dass ich halt einen Entwicklertest schreibe.
Bei anderen Entwicklern, die das vielleicht dann selber in meine Oberfläche durchgeklickert haben,
da haben sie immer wieder Sachen gefunden, also auf dem Papier scheint das trivial in Geschichten dann zu sein.
Und das heißt, sie mussten das wieder zurückmelden.
An den Entwicklern, der Entwickler musste sich dann wieder einarbeiten und so weiter.
Also Feedback-Schleifen waren halt unheimlich lang.
Also ich fand das eine tolle Feedback-Form, das hat mich dann auch bestätigt,
meine Arbeitsweise da, auch wenn das Management ein bisschen am Rummieren war.
Also Papier brauchte ich natürlich länger als andere Entwickler, bevor ich das zum QA-Team übergeben hatte.
Aber ich habe das dann wieder rausgekriegt, weil die Zeit,
wo es Richtung Produktion ging, halt geringer war als bei den anderen Entwicklern.
Also wenn man das für mich vergleicht, dann sind das auch immer philosophische Diskussionen.
Weil das, was du vielleicht teurer warst, habt ihr an anderer Stelle eingespart.
Aber das kann ja niemand wirklich nachrechnen oder errechnen, wo der Vorteil ist an der Stelle.
Sondern das ist einfach eine philosophische Betrachtungsweise, wie ich finde,
zu sagen, liefere ich gute Qualität ab und dann brauchst du vielleicht länger und du bist vielleicht auch teurer.
Aber dadurch hat man andere Vorteile, die man eben so gar nicht bewerten kann.
Ja genau, man muss halt abstrakte Rechnungen machen.
Also man weiß zum Beispiel, dass wenn ich meine Arbeit unterbrechen muss,
dass ich, bis ich wieder im Kontext drin bin, dann gibt es ja solche Größen, wo man sagt,
man braucht durchschnittlich 10 bis 15 Minuten, bis man wieder im Kontext ist.
Und der Entwickler, der ständig einen Anruf von QA-Abteilung kriegt,
der wird ja natürlich dann schon im nächsten Feature schon sitzen.
Das heißt, das muss er abbrechen, dann muss er sich wieder reindenken beim alten Feature, wie wäre das nochmal.
Also man kann dann nur eine abstrakte Rechnung machen.
Vollkommen richtig. Und die Anrufe nimmt er vielleicht irgendwann gar nicht mehr entgegen, weil die immer wieder nerven.
Ja genau.
Dann lasst uns mal auf den nächsten Punkt gehen, der in dem Spicker nicht beschrieben ist,
aber wir sollten ihn aufgrund der Durchgängigkeit schon kurz ansprechen.
Das ist das Thema Continuous Inspection. Was verstehst du da drunter?
Ja und das geht halt darum, irgendwann hat man ja festgestellt, ich krieg die Qualität schon, also unsere innere Qualität,
also das innere Qualität, das sagen wir im Entwickler dazu, ob der Source Code halt lesbar ist.
Meine Lieblingsanalogie für LINE ist halt, wenn ich einen Text lese und der besteht aus Bandwürmern,
der ist unheimlich schwer zu lesen und ich brauch drei, vier Anleufe, bis ich eigentlich den Sinn dieses Textes verstanden habe.
Und wenn ich dann diesen Text nochmal umschreibe in kürzere Sätze, dann ist er meistens dann viel lesbarer für die,
auch für Leute, die nicht in der Thematik drin sind.
Und so ähnlich ist es gelagert auch mit dem Source Code, also ich kann einen Source Code schreiben,
der für die Maschine wunderbar ausführbar ist.
Aber für meinen Entwicklerkollegen, der vielleicht da einen Bug fixen muss,
dann kann ich das sehr relativ schwer, den Source Code so schreiben, dass es schwer zu verstehen ist.
Das heißt, ich soll meinen Source Code so schreiben, dass er auch für jemanden anders,
der jetzt nicht in der Thematik drin ist, leicht lesbar ist, damit er sich leichter einarbeiten kann.
Und dann hat man gesagt, okay, dann lass Code Reviews machen.
Das heißt, dass, indem ich meine Arbeit abgeschlossen habe,
dass ich mir einen Kollegen nehme, der nochmal drüber schaut und guckt, ob es einen Feedback dazu gibt.
Und da stellt sich heraus, dass es mit der Zeit immer so gewisse Best Practices, also Muster gibt,
die immer wieder kehren sind, wo dann man sagt, okay, eigentlich könnte ich auch eine Maschine drüberlaufen lassen,
die mir dann sagt, hey, an der Stelle ist ein potenzieller Bug drin, aufgrund der, wie du das geschrieben hast.
Oder hey, du hast hier eine, wir sagen dann halt so Bedingungskomplexität,
das heißt, wenn wir viele Fallunterscheidungen haben,
Fallunterscheidungen haben im Code und auch gerne auch verschachtelt.
Das ist, dann kann man sich vielleicht vorstellen, okay, wenn ich ganz oben in Source Code eine Bedingung habe,
die muss ich mir aber im Kopf behalten, weil sie 100 Zeilen später Auswirkungen auf eine andere Bedingung hat,
kann man sich vielleicht vorstellen, dass es vielleicht schwierig ist.
Man muss da sehr hoch konzentriert sein.
Und dann gibt es halt Tooling, die mir dann sagen kann, hey, deine Komplexität an der Stelle ist hier relativ hoch.
Meinst du nicht, dass wir das nochmal überarbeiten?
Das heißt aber nicht, dass jetzt diese Code Reviews überflüssig werden, sondern das ist nur eine Unterstützung.
Dass man sich auf so, Anführungsstrichen, Trivialitäten schon Feedback von der Maschine holt.
Und wenn das schon mal gut durchgelaufen ist, dass ich dann mit meinen Kollegen nochmal drüber gehe
und dann vielleicht über das Design sich unterhalten kann, wenn ich vielleicht andere Designpattern an der Stelle
oder ob ich dann vielleicht eine Architekturverletzung drin habe und mich unterhalten kann.
Ja, okay.
Und dann gibt es noch andere Trivialitäten, wie zum Beispiel, also wie blieb es der Kampf unter den Weglern ist,
ob ich für eine Rückung jetzt Tabs benutze oder Leere.
Ja, okay.
Oder Leerzeichen.
Das ist, ehrlich gesagt, für den Laien schwer zu erklären, warum man darüber diskutieren muss.
Ich handhabe das so, dass ich mich einfach, also ich komme meistens von den laufenden Projekten,
ich frage einfach nach, was habt ihr, Tabs oder Spaces.
Und dann kann ich halt auch so eine Maschine drüber laufen lassen und dann so, um zu gucken,
ob die Leute sich solche Trivialitäten überhaupt einhalten.
Dann muss ich das nämlich auch nicht mit einem Code Review umschlagen.
Aber ich kann dich beruhigen.
Diese Problematik kenne ich genauso, wenn es um das Thema geht, wie baue ich Folien auf.
Also selbst bei PowerPoint-Folien gibt es die Frage.
Oder bei Word-Texten arbeite ich mit Tabs, mache ich dafür einen neuen, mache ich einen Zeilenumbruch.
Also diese Banalitäten, wie du sie nennst, gibt es wahrscheinlich auch dann in allen Ecken und Enden.
Ja, super.
Jetzt heißt unser Podcast oder diese Folge ja Tool-Parade.
Wir haben eben vergessen, beim Continuous Testing über ein paar Tools zu sprechen.
Ich würde die nur der Vollständigkeit halber nochmal erwähnen.
Wie gesagt, in den Notes gibt es ja auch deinen Spicker dazu.
Also beim Continuous Testing reden wir über Tools wie xUnit, jUnit.
xUnit, jBehave, Selenium, Jasmin, alles ganz schöne Namen.
Beim Continuous Inspection, hast du da mal so zwei, drei Tools, die man besprechen sollte?
Also wenn es zum Beispiel nur darum geht, abzutesten, ob die Einrückungen richtig sind.
Da wird gerne im Java-Umfeld CheckStyle benutzt.
Wenn ich zum Beispiel im JavaScript-Umfeld unterwegs bin, um zu gucken, ob man sich so am Best-Practice hält,
um potenziellen Bugs aus dem Weg zu gehen, da gibt es diesen JS-Lint.
Dann…
Ich kann diese Tooling auch dazu benutzen, um zu gucken, wie meine Testabdeckung ist.
Das heißt, ob die Tests auch alle möglichen Stellen meines Codes durchlaufen.
Da gibt es im Java-Umfeld zum Beispiel das Yakoko.
Der misst dann halt, wie hoch meine Testabdeckung ist.
Und dann das Mega-Tool im Java-Umfeld, wo man mal denkt, wenn ich das Tool einsetze,
dann werde ich alle meine Code-Analyse-Probleme aus dem Wind schaffen, ist SonarCube.
Aber man darf sich da jetzt auch nicht blenden lassen.
Man muss da ja auch wieder Zeit und Energie einsetzen.
Die Leute müssen ihre Arbeitsweisen anpassen, wenn ich dann solche Tooling einsetze.
Also ich fahre meistens mit einem Minimal-Set.
Was ich auf jeden Fall mache, ist halt, dass ich Yakoko und CheckStyle und für potenziellen Bugs
halt vielleicht noch SpotBugs einsetze.
Und das kann ich auch wieder in meinen Bildlauf mit einbauen.
Das heißt, wenn da irgendwelche Regelverletzungen gibt, dass das Bild auch bricht
und auch keine Software-Artefakte angebaut werden.
Und wenn das nicht ausreicht und der Kunde mehr möchte und auch bereit ist,
seine Arbeitsweise umzusetzen, dann kann ich das auch einsetzen.
Und wenn das nicht ausreicht und der Kunde mehr möchte und bereit ist,
seine Arbeitsweise umzusetzen, dann kann ich das auch einsetzen.
Dann nehme ich solche Plopper wie SonarCube an der Stelle.
Okay.
Für das Management ist das halt fancy.
So ein SonarCube hat eine fancy Web-Oberfläche.
Da kann man ganz tolle Zahlen daraus generieren.
Einiges Verkaufsargument wahrscheinlich.
Ja, genau.
Und bei SpotBug, CheckStyle oder Yakoko, da merkt man halt,
das ist halt eine andere Zielgruppe.
Da bekomme ich halt so Kommando-Lines-Ausgaben.
Vielleicht kann ich noch HTML-Reports ausgenerieren,
aber die sehen halt nicht so fancy aus.
Ja, okay.
Gut, dann gucken wir mal zum nächsten Punkt
auf deiner Perlenkette.
Und der ist auch in dem Sticker wieder beschrieben.
Continuous Database Integration.
Was muss ich mir darunter vorstellen?
Ja, also das ist Persistenz an der Stelle.
Und das ist halt,
also ich habe jetzt keine Zahlen, aber in den Projekten,
wo ich eigentlich bisher zu 90 Prozent,
also das ist eine persönliche Wahrnehmung,
zu 90 Prozent wird halt Persistenz
gerne an eine relationale
Datenbank eingesetzt.
Es gibt dann auch andere Daten,
so NoSQL, das sind so dokumentenbasierte,
oder Key-Value-Datenbanken,
aber was ich halt
meistens sehe ist, da werden halt
gerne relationale Datenbanken.
Naja, die relationalen Datenbanken haben halt,
was heißt Problem, also
das ist halt eine Eigenschaft von relationalen Datenbanken,
dass ich halt da die Tabellenstruktur
halt beschreiben muss. Das heißt,
ich muss sagen, hey, leg mir bitte
folgende Tabellen an, die haben
folgende Spalten, in diesen Spalten
dürfen nur bestimmte Datentypen
eingespeichert werden. Und dann ist die Herausforderung
ja, meine Software und meine Anforderungen,
die ändert sich halt mit der Zeit. Am liebsten,
das tun aber auch nicht alle,
müsste eigentlich auch meine Datenbankstruktur
mit der Zeit sich auch verändern. Und das wird
eine Zeit lang wurde sehr wenig gemacht,
weil man Angst hatte,
da was zu ändern, das könnte ja was kaputt gehen,
oder Daten verloren gehen.
Das heißt, man hat dann angefangen,
in den bestehenden Strukturen
irgendwas reinzuflanschen. Das läuft
vielleicht paar Mal, paar Jahre gut, aber irgendwann
ist dann diese ganze Datenbankstruktur
so unübersichtlich, dass man
das relativ dann schon wegen der Datenbankstruktur
sagt, okay, eigentlich müssen wir das nochmal neu schreiben.
Ist aber eigentlich keine Lösung darin.
Naja, und dann
hat man gedacht, okay, irgendwie möchte ich ja
meine Datenbanken auch
irgendwie automatisiert, also die Änderungen
an der Datenbankstruktur irgendwie auch
automatisiert testen. Und dann fängt man halt
an auch Skripte zu schreiben, die halt
meine Datenbank verändert. Und dass man die
halt mit abtestet, so wie
meinen normalen Source-Code. Und das ist eigentlich auch das Verwunderliche
an der ganzen Geschichte, also
das ist mir noch vor wenigen Jahren
rübergekommen, also dass man so Java-Code,
oder JavaScript-Code in ein
Visionskontrollsystem ablegen muss.
Das war für die Leute schon klar
und hat Mama fleißig gemacht.
Aber die Skripte für die Datenbankstruktur,
was eigentlich auch
Bestandteil der Software sein sollte, die flogen
dann irgendwelchen Tickets, Handbüchern,
E-Mails herum. Und dann
die arme Sau, die am Wochenende dann
diese neuen Rollout machen musste,
der musste dann halt sich die Sachen vorher irgendwie
zusammensuchen und hoffen, dass das halt dann
irgendwann funktioniert übers Wochenende.
Also im Java-Umfeld
sind mir nur zwei geläufig,
Flyway und Liquibase, und
die unterstützen mich darin, einmal,
dass diese Skripte automatisiert mit
ablaufen, das heißt, wenn ich eine neue Release-Version
meiner Software habe, dass sie dafür Sorge tragen,
dass auch die Datenbank, die unterliegende Datenbank
damit abgedatet wird.
Die kann ich dann auch fürs Testen halt dann auch benutzen,
um zu gucken, hey, wie funktionieren sie überhaupt. Und das Schöne
ist auch, sie schreiben auch in der Datenbank
so eine Änderungshistorie. Das heißt, ich kann,
wenn es zu Problemen kommt, genau nachvollziehen,
welche Skripte auf
welcher Datenbankinstanz, wann
liefen, und so habe ich dann
einen Überblick von wegen, okay, das ist
der Zustand dieser Datenbank, weil
folgende Skripte gelaufen sind.
Hat aber auch wieder Auswirkungen auf den Entwickler,
das heißt, den Helden spielen
und mal schnell auf Produktion
die Datenbankstruktur ändern
oder Daten löschen, ist da halt nicht mehr.
Weil dann wird das ganze System wieder ad absurdum geführt.
Und wenn ich mal schaue, über welche
Tools reden wir dann da?
Ja, da kommen wir eigentlich schon mehr Richtung
Operation. Das geht halt darum, dass ich
also
für den Laien gesprochen, wenn ich so einen Laptop bestelle,
das ist meistens, wenn ich Glück habe, vielleicht nur
ein Windows drauf, oder manchmal ist es auch blank.
Und dann setze ich mich am Wochenende hin
und bin mir Windows am installieren oder
ein anderes System
und meine ganze Software drauf am spielen.
Und
sowas muss man sich vorstellen, das gibt es auch im Serverbereich.
Nur im Serverbereich ist es ja nicht so, dass ich
alle paar Jahre mal einen Server neu installiere,
sondern da muss ja kontinuierlich
Updates aufgespielt werden,
neuer Bedarf ist da, das heißt, neue
Server müssen bestellt werden, dann möchte ich gerne, dass jeder
Server gleich aufgesetzt wird und nicht unterschiedlich,
sodass
ich weiß, okay, wenn das auf diesem Server läuft, dann wird
das auf dem nächsten Server auch laufen. Ja, und dann
automatisiere ich da an der Stelle.
Das heißt, ich schreibe mir auch solche
sogenannte Provisionierungsskripte,
das ist auch wieder Code,
das heißt, das gehört auch wieder in
mein Provisionierungskontrollsystem
und das hat auch,
das heißt, wenn ich einen neuen Server habe oder
Änderungen fahren möchte, dann rufe ich halt
diese Skripte auf, die den Server
dann genau so anpassen, wie ich es in meinem
System steht. Hat auch hier wieder
Auswirkungen auf den Entwickler.
Ich darf nicht
irgendwas manuell auf den Kisten machen,
sondern alles muss über Skripte
verteilt werden.
Und
ja,
ein paar Toolings zu nennen,
also die Platzhörscher
an der Stelle sind halt
Ansible, Puppet,
vielleicht Chef, gibt auch
Tooling, die nicht so verbreitet sind,
wie Salt,
so, wenn jemand sich wundert, warum ich
jetzt Docker nicht genannt habe, ja, weil Docker
kein Konfigurationsmanagement-Tooling ist,
das ist halt eine Containertechnologie, das heißt,
ich benutze mal ein Konfigurationsmanagement-Tool
wie Ansible und Puppet,
um halt meinen Docker-Demon
auf meinen Server zu installieren.
Mhm, okay.
Welche Vorteile habe ich
von einem automatisierten
Konfigurationsmanagement? Kannst du das mal
vielleicht ganz kurz nochmal aufzählen?
Der Vorteil ist halt, ich
weiß, ich habe
einen Server, und die sehen
alle gleich aus, weil sie mit den gleichen Skripten halt
installiert worden sind.
Und da habe ich
nicht die Effekte, dass zum Beispiel auf meinem
Testsystem die Software läuft, aber auf Produktion nicht,
weil die
unterschiedliche
vielleicht Softwarestände draufinstalliert haben vom
Betriebssystem oder sowas. Das kommt ja auch schon manchmal vor.
Und damit kann ich halt sicherstellen,
wenn ich die
Provisionsskripte von meinem Produktionsserver nehme
und damit einen Testserver aufsetze,
dass ich das Risiko halt da an der Stelle
minimiere, dass ich dann Richtung Produktionsgang
dann nochmal irgendwelche Überraschungen kriege.
Ja, okay, gut.
Dann der nächste Schritt, automatisierte
Verteilung.
Da
geht es halt darum, dass
ich jetzt hier meinen,
mit meinen Entwicklern halt die Software
gebaut habe,
zusammengeschnitten in so ein Softwareartifakt,
und dann geht es halt darum, dass ich dieses
Softwareartifakt
halt auf den Server draufkriege.
Und das ist nicht nur, dass ich
dieses Artifakt rüber kopieren muss,
sondern ich muss
Konfigurationen
mit ausspielen, und dann ist es halt so, wenn ich
dann mehrere Umgebungen habe, wie Tests, Produktionen
und verschiedene
Staging,
dann ist natürlich die Konfiguration
ist dann, sieht immer anders aus,
weil ich dann andere Datenbankverbindungen brauche,
andere User,
vielleicht andere Timeouts,
also gibt es verschiedene Spielarten.
Und die Idee dahinter ist halt,
dass ich ein Softwareartifakt habe,
für alle Umgebungen,
und dieses Artifakt halt
weiß, wie er sich in Umgebungen
zu verhalten hat, anhand der Konfiguration.
Da gibt es halt verschiedene Möglichkeiten,
das halt zu machen. Ich kann dann sagen, okay,
ich spiele das Softwareartifakt,
und der guckt dann lokal
auf den Server, wo er drauf ist,
hey, wie soll ich mich konfigurieren?
Oder er fragt halt einen Konfigurationsserver ab,
hey, ich bin auf der Kiste
XYZ,
wie sehen die Konfigurationen dafür halt aus?
Oder ganz klassisch,
ich schiebe mit dem
Softwareartifakt
meine Konfigurationsdateien
mit auf der Kiste.
Und was für mich
ganz wichtig ist an der Stelle, ist immer,
ich muss diesen
Bildvorgang, also wie ich mein Softwareartifakt baue,
und meinen Deploymentvorgang
immer trennen. Das heißt, wenn
der Bild fehlgeschlagen ist,
darf das keine Auswirkungen auf den
Deploymentvorgang haben, das heißt, wenn ich dann mal ein neues Deployment
mache, dann geht das immer mit dem letzten
funktionierenden Stand raus.
Und das heißt, wenn ich auch meine,
beim Test dann zum Beispiel meinen
Server halt kaputt getestet habe,
dass er
ein fertiges Softwareartifakt immer wieder neu
draufspielen kann, ohne dass er den
vorgelagerten Bild
Vorgang nochmal antriggern muss.
Antriggern muss, jawohl, okay.
Wenn wir hier über Tools sprechen, du hast ja
eben bei dem Konfigurationsmanagement
schon über ein paar Tools gesprochen,
und soweit ich das weiß, gibt’s ein paar Tools,
die quasi in den beiden Bereichen tätig sind.
Genau. Wie zum Beispiel Ansible.
Genau. Also ich persönlich
nutze dann meistens recht Ansible.
Es können
aber auch Shell-Skripte sein.
Oder was eigenes geschriebenes.
Das muss jetzt nicht, also ich habe auch schon mal
gesehen, dass man ganz einfache Shell-Skripte
schreibt.
Das wäre zum Beispiel
ein gangbarer Weg, wenn man zum Beispiel als
Softwareartifakt, also das Format her zum Beispiel
so ein Docker-Container ist,
dann reicht zum Beispiel auch vollkommen aus zu sagen,
okay, ich schreibe ein Shell-Skript, der diese Container
auf die Maschinen halt verteilt.
Oder wenn ich halt in größeren Umgebungen bin,
also vor allem in der Containerwelt, dann
sind ja solche Sachen wie
Kubernetes oder Docker Swarm
dann halt gehypt, und die helfen einem auch dabei,
die Sachen halt zu verteilen und sogar
automatisiert zu verteilen. Die haben aber
natürlich noch andere Aufgaben, aber das sind dann spezielle
Containereigenschaften,
die sie dann vermitteln.
Gut.
Dann, soweit ich
deinen Spicker verstanden habe, hier wären wir
jetzt durch, was so das ganze Thema
Tooling angeht. Habe ich das richtig
verstanden oder richtig interpretiert?
Jawohl. Weil wir haben jetzt auf deinem
Spicker noch ein paar Themen,
wo ich sagen würde, Mensch, da könnte man vielleicht nochmal
einen separaten Podcast für machen, eine separate
Aufnahme, weil das ja eben
nicht mehr die Tools an sich sind.
Also, wenn du einverstanden bist, würde ich
sagen, beenden wir jetzt die Toolparade.
Ja, gerne.
Okay, gut. Also,
beenden heißt Toolparade, aber
wie gesagt, der Spicker bietet noch Chancen, ein paar
andere Sachen zu machen. Ja, vielleicht
machen wir später nochmal
eine weitere Aufnahme und greifen
dann nochmal drauf zurück.
Gibt es irgendwo einen Punkt, den du nochmal so
beim Rückblick auf diese beiden Folgen nochmal
ergänzen wollen würdest, oder
war das für dich jetzt eine runde Sache?
Ja,
vielleicht ein abschließendes Wort, also
Tools gibt es halt reichlich,
aber im Endeffekt,
ich hoffe, das kam rüber, denn
das Sprichwort
noch seine Berechtigung hat,
Tool für Tool ist der
Tool. Das heißt, eigentlich
nützt es nicht, irgendwelche
Tooling einzuführen, sondern ich muss wirklich halt
Richtung
Organisationsstrukturen gehen und sagen, hey,
das Tool kann mich unterstützen,
aber auch nur, wenn ich mich
gewisse Arbeitsweisen halt dann
aneigne an der Stelle.
Das vielleicht so als Fazit von der ganzen
Geschichte. Also, aus meiner Sicht,
das habe ich dabei auch rausgehört, natürlich
kann ich über Tools reden, und
wenn ich jemandem die Freiheit lasse,
sich seine Tools auszusuchen, dann wird er natürlich
auch die Tools aussuchen, die ihm
genehm sind an der Stelle.
Und was ich eben rausgehört habe,
ist, dass man über das Thema
Tools schon sehr viel auch steuern kann,
und dass eben von der
Auswahl des Tools, oder dass die Auswahl
eines Tools und die effektive Nutzung,
dass das schon auch davon abhängt, welchen
Qualitätsanspruch haben die Entwickler
an der Stelle. Und das
denke ich, das wäre so aus meiner Sicht das, was du
gesagt hast mit dem Tool
und dem Fool an der Stelle.
Ja, genau. Gut, ja,
also dann bedanke ich mich
recht herzlich für die Unterstützung,
für diese beiden Folgen an der Stelle,
für das Verteilen, für das Teilen
deines Wissens an der Stelle,
und ich freue mich auf die nächste
Folge, die wir sicherlich nochmal machen,
zu dem Thema Continuous Controlling, Continuous
Observation, aber wie gesagt,
hier zum Thema Toolparade sind wir durch.
Vielen Dank, liebe Sandra. Vielen Dank.
Sehr gerne.
Vielen Dank.