i07.md

[INTRO]

10:01 

R1: Was tust du denn so fachlich in deinem Job? Also bist du irgendwie im Microservice-Development drin, Testing oder Team-Manager, DevOps, Consultant oder was?

I7: Also im Moment ist meine Position Teamleiter von einem Entwicklungsteam. Wir entwickeln—also unsere Firma macht Businessprozess-Outsourcing. Das heißt bestimmte Prozesse von, im Moment Energiedienstleiters/Energielieferanten, Strom- und Gaslieferanten, führen wir durch und dazu machen wir eben Softwareentwicklung und ich bin in so einem Team, das APIs und Kundenportale nach außen bereitsstellt. Dafür haben wir eine serviceorientierte Landschaft. Also Schnittstellen nach außen. Wir sind so ein bisschen die Zwischenschicht zwischen dem großen Backendsystem—SAP-System, große Oracle-Systeme—und der Außenwelt. Entweder als Portal oder als API. Und wir gehen auch ein bisschen in Richtung Software-as-a-Service zu verkaufen. Das fängt jetzt so an. Also eher in einer Servicelandschaft. Und als Rolle Teamleiter. Kümmere ich mich—einerseits programmiere ich selber noch ein bisschen, kümmere mich um die Ausarbeitung der Tickets. Ich habe jetzt auch in den letzten drei, vier Jahren mich um das Releasemanagement gekümmert, also eine Art von Konfiguration, sehr viel. Bei uns ist es noch ein bisschen so wer es baut, der soll sich auch darum kümmern, also wir kümmern uns auch um die Fehleranalyse und so weiter und Behandlung, allerdings nicht um den eigentlichen Betrieb, also wenn jetzt mal ein Server Sonntag nachts ausfällt, das macht schon unsere IT-Abteilung. Was kann man noch sagen? Unsere Software ist so multimandantenfähig, also wir haben verschiedene Kunden und wir bieten eben die Services für deren Kunden an und die verschiedenen Kunden haben verschiedene Anforderungen und unsere Software läuft eben für verschiedene Kunden.

R1: Ja, da hast du schon gleich unsere ersten Fragen schon beantwortet. Welchen Anteil hat denn die Programmierung an deiner täglichen Arbeit?

I7: Die Programmierung selbst vielleicht so—Softwareentwicklung im Allgemeinen dann schon 66 %, zwei Drittel so. Ungefähr, vielleicht ein bisschen mehr. Also zu Softwareentwicklung zähle ich jetzt so von Anforderung bewerten bis zum Deployment. Also alles. Also wenn ihr das auch so definiert.

R1: Und Programmierung dann?

I7: Programmierung selbst ist eher weniger. Maximal 10 %.

R1: Wie viele Jahre Erfahrung hast du denn in der Softwareentwicklung?

I7: Mit oder ohne Dissertation? Also richtig in der Wirtschaft sind das jetzt 6,5 Jahre.

R1: Seit wann arbeitest du in der Organisation?

I7: Auch so lange.

R1: Und seit wann bist du in deiner aktuellen Position?

I7: Ungefähr ein Jahr.

R1: Und so die letzte allgemeine Frage: Mit welchen Frameworks und Tools arbeitest du denn so gewöhnlich?

I7: Also unsere Software ist eine java-basierte Software. Wir nutzen das Spring-Framework. Die Webservices basieren entweder auf SOAP- oder REST-Schnittstellen. Wir haben auch noch WildFly als Applikationsserver zum laufen. Wir starten oder haben schon gestartet mit Systemen, wie Kubernetes. Ja, genau Spring Framework, Spring Boot, WildFly, als relationale Datenbanken Oracle. Ja und alles, was dazu gehört: JavaScript-Applikationen als Frontend, HTML-Applikationen als Frontend.

R1: Und in eurem Continuous Integration/Delivery-Stack?

I7: Achso, da haben wir Jenkins Integrationsserver und wir sind dabei Continuous Delivery aufzubauen. Da gibt es erste Ansätze. Und da nutzen wir auch Jenkins Pipelines. Und als Softwareverwaltung haben wir Git, als Versionsverwaltung. Und was haben wir noch? Als Registry für Dockerimages oder für Java-Artefakte haben wir eben so ein Sonatype. Heißt das so? Ja, so ein Nexus von Sonatype. Als Buildtools nehmen wir noch Maven. Also ja, Maven hauptsächlich im Java-Umfeld und Entwicklungsumgebung hauptsächlich IntelliJ. Das war es.

R1: Super. Okay, das sind so die allgemeinen Fragen, jetzt gehen wir mal zur Konfiguration. Was verstehst du denn selber jetzt unter dem Begriff Konfiguration?

I7: Also ich würde zwei unterschiedliche Dinge sehen bei uns. Einerseits, was ich als Releasemanager gemacht habe, eben die ganze Konfiguration der Applikationsserer, alle möglichen Konfiguration, also wenn man Dienste hat—wir haben beispielsweise kein Service-Discovery, sondern wir müssen Abhängigkeiten konfigurieren, wer mit wem spricht und so weiter. Orchestrierung wäre irgendwie sowas. Wir konfigurieren unsere Apaches und so weiter. 17:38 Ich glaube unsere—also auf dieser Ebene der Konfiguration ist unsere Grenze dann die VM. Da übernimmt das unsere IT-Abteilung. Die IT-Abteilung macht die ganze Netzwerkkonfiguration, die ganze VM-Konfiguration, Rechenzentrum und sowas. Das haben wir nicht mehr. Und das wäre ja erst eher so Richtung Deployment und Ablauf konfigurieren wir eben sehr viel und die zweite Art von Konfiguration ist, weil wir eben verschiedene Kunden, verschiedene Mandanten mit unserer Software abdecken, haben wir da eben auch Konfigurationen. Wenn ich jetzt sage, wir konfigurieren Features, also ist das eher so, dass für bestimmte Funktionalitäten haben Mandanten bestimmte, unterschiedliche Eigenschaften. Die konfigurieren wird. Oder bestimmte Funktionalität ist für einen Mandanten da und für andere nicht. Oder was einfacheres: Für bestimmte Prozesse braucht man eben ein paar Parameter, für eine bestimmte Validierung hat eben ein Mandant die Einstellung, das soll validiert werden, ein anderer Mandant soll eben etwas anderes validiert werden. Das muss eben beim Setup oder so konfiguriert werden, würde ich sagen. Das ist für mich—diese zwei Level. Einerseits das technische und das andere würde ich jetzt so eine Art fachlich sagen. Welche Eigenschaften hat welcher Kunde. 19:18 

R1: Prima, wir haben nämlich genau die gleiche Einteilung für den Rest des Interviews: Fachliche und technische Konfiguration. Dass also genau du auch die gleichen Begriffe nennst, ist sehr gut. Vielleicht, wann konfigurierst du denn die Software? Meinetwegen aufgeteilt in fachliche und technische Also zur Compilezeit, Laufzeit oder so?

I7: Meistens, im Moment haben wir das alles, also wir haben verschiedene Sachen. Meistens die fachlichen Sachen zur Compilezeit. Das sind so meistens Properties-Files, manchmal aber auch abgeleitete Klasse, also wenn es richtig hardcodet ist teilweise auch. 20:13 Also, dass man einen Basisvalidator hat und man dann spezifische Funktionen reingebaut hat. Wir haben aber auch die Möglichkeit bestimmte Eigenschaften während der Laufzeit zu ändern. Dass man eben bestimmte Eigenschaften in Konfigurationsdateien oder beziehungsweise in Datenbanken ausgelagert haben und dort kann man eben Sachen einstellen während der Laufzeit. Dann haben wir noch jetzt neu so eine dritte Art von Zeitpunkt der Konfiguration: Während des Deployments. Das ist hauptsächlich Richtung Container und Kubernetes. Da versuchen wir eben, ja Einstellungsdateien aus den eigentlichen Programmierartefakten zu extrahieren und dann praktisch dazu zu packen. Kann man so sagen—dazupacken. Und während des Deployments wird eben eine bestimmte Version der Konfiguration genommen und ja, ist dann da. Also diese drei Sachen haben wir.

R1: In wie weit spielt denn die fachliche und technische Konfiguration in der täglichen Arbeit eine Rolle?

I7: Eine große? Na, einerseits wenn wir Anforderungen von unseren Kundenmandanten umsetzen muss man immer darauf achten, gibt es dieses—Feature ist so ein überladener Begriff—gibt es diese Funktion schon, ist die irgendwie schon für einen Mandanten vorhanden, muss man die anders konfigurieren im idealen Fall oder muss man was dazu programmieren? Also ist das eigentlich schon immer mit dabei bei den Multimandanten-Systemen.22:11 Und die technische Sache, die ist jetzt ein bisschen weniger geworde, weil ich mich nicht mehr so um diese Sachen kümmere, aber spielt immer noch eine große Rolle auf verschiedenen Ebenen.

R1: Gibt es denn nach deiner Erfahrung Interaktionen zwischen fachlicher und technischer Konfiguration?

I7: Ja, bestimmt. Ja. Was könnte mir als Beispiel jetzt einfallen? Bestimmt, wenn man eine Funktion aktiviert, benötigt die häufig bestimmte Komponentenservices beispielsweise und damit ein System einen Service benutzen kann, ist es im Moment so, dass eben das konfiguriert werden muss. Also ja, das wäre so ein Beispiel. Eine Email-Verifikation und dafür gibt es einen Service für das Email-Verifizieren und wenn man diese Funktion aktiviert, muss man eben auch die Konfiguration hinstellen, dass der Service benutzt werden kann. Also häufig in diese Richtung: Wenn eine Funktion aktiviert werden soll, braucht man auch eine technische Konfiguration damit das funktioniert.

R1: Habt ihr auch typischerweise mit der Konfiguration eines monolithischen Systems zu tun?

I7: Naja, wir haben eine serviceorientierte Landschaft. Wir haben verschiedene Services, die natürlich jeder konfiguriert werden kann. Und auch—wir haben so ein bisschen halt Sammelpunkte nach außen, API, beziehungsweise ein Portal. Diese Portale kann man schon ein bisschen als Monolithen bezeichnen, die die ganzen Services benutzen. Also beides. Aber wir haben hauptsächlich Services.

R1: In wie weit müssen denn Tools, Frameworks und Infrastruktur konfiguriert werden bei euch?

I7: Ja, die müssen alle konfiguriert werden. Als angefangen vom Entwicklerrechner, muss ja jeder Entwickler seine Entwicklungsumgebung konfigurieren von den ganzen Tools bis hin zum Proxy teilweise. Dann (?25:07 ) Infrastruktur, Tools, Frameworks. Also was die Umgebung angeht, konfigurieren wir natürlich alle Software oberhalb vom Betriebssystem zum Großteil selbst. Also nicht die Firewalls und sowas, aber Software wie Apache und andere Webserver oder WildFlys. Oder eben wie gesagt das Kubernetes. Das ist ja voller Konfiguration, wie ich gesehen habe. Und jetzt noch dazwischen Frameworks. Was muss man da konfigurieren? Eigentlich ist es da eher weniger Konfiguration, abgesehen von Maven-Dependencys einbinden. Danach eigentlich nichts so.

R1: Okay, aber Spring Framework und so weiter?

I7: Da ist nicht so viel… na innerhalb des—also einerseits ist Framework, sucht man sich eben die Komponenten raus, als Maven-Dependencys, um bestimmte Funktionen, die schon vorhanden sind. Werden über Properties-Dateien teilweise konfiguriert, Richtung Zugriffsschutz oder Datenbank-Verbindungen oder irgendsowas.

R1: Gibt es denn Interaktionen zwischen diesen ganzen Sachen? Ja, also zwischen deinen Frameworks und der Infrastruktur oder sowas irgendwie.

I7: Kommt darauf an, wo man die Infrastruktur anfangen lässt.  Ja, das Framework nutzt eben—einerseits die Konfiguration wird natürlich von der Infrastruktur vorgegeben so ein bisschen. Also Adressen denke ich jetzt mal, sowas. Also Serveradressen, Passwörter und so weiter.

R1: Wie findest du denn den Stellenwert oder die Wichtigkeit von Konfiguration im Software Engineering oder bei der Softwareentwicklung, wie siehst du das denn?

I7: Wird immer gerne vergessen. Ne, wichtig, ja? Dass man das auch ordentlich managet.

R1: „Wird immer gerne vergessen” würden wir dich wahrscheinlich auch gerne zitieren.

I7: Also die fachliche Konfiguration hilft uns, wenn man das also selber baut, schneller für verschiedene Mandanten Funktionen bereitzustellen oder anzupassen. Und die technische Konfiguration kann sehr viel kaputt machen, wenn man die falsch macht und bräuchte noch ein bisschen mehr Stellenwert. Vor allem das Management dazu. Also Einstellungsdateien irgendwo hinpacken irgendwie ist da relativ leicht, aber die dann auch zu managen und Versionen zu halten.

R1: Ah ja, okay. Können wir am Ende des Interviews vielleicht noch mal drüber sprechen, weil wir da auch in der Hinsicht ja forschen. Gibt es denn Unterschiede in verschiedenen Software-Lebensphasen bezüglich des Stellenwerts von Konfiguration?

I7: Da muss ich mal überlegen. Na ich denke schon, dass es Unterschiede gibt. Es ist überall vorhanden, aber die Hauptarbeit ändert sich schon. Also gerade bei neuen Systemen überlegt man sich schon wie es konfigurierbar werden kann, aber man entwickelt ja eher die Funktionalität. Vielleicht versucht man das auch zu überlegen, was könnte mal konfigurierbar sein, was nicht. Oder was macht man jetzt mal—aber das ist mehr so auf konzeptioneller Ebene dann. Während wenn die Software schon da ist und zum Beispiel nur noch einer neuer Kunde hinzugefügt werden muss, da hast du mehr Richtung Konfiguration.

R1: Wurdest du denn während deines Studiums oder Ausbildung denn auf diese Konfiguration vorbereitet?

I7: Wenig.

R1: Okay, sollte es denn im Studium unterrichtet werden oder einen größeren Stellenwert kriegen?

I7: Bin ich mir unsicher. Also eher in so praktischen Arbeiten. Vielleicht—oder, ja einerseits in praktischen Arbeiten sollte man eben schon zeigen, dass es mehr gibt als einfach nur was zu programmieren. Und vielleicht sollte man—ich weiß ja nicht wie das heutzutage im Studium ist, bin ja schon lange weg—es gibt ja auch so Sachen wie Infrastructure as Code oder wie auch immer das heißt. Letztendlich wird die Infrastruktur dann eben so definiert wie normale Software. Also muss getestet werden, man schreibt das, hat Versionsverwaltung. Vielleicht müssten solche Themen auch mal in bestimmten Fächern mit auftauchen. 31:52 

R1: Okay, das waren so allgemein die Fragen zu Konfiguration. 31:55 wie arbeitet man denn mit Konfiguration? Wie werden denn bei euch Konfigurationen verwaltet und dokumentiert?

I7: Okay, also bei uns im Team. Ich spreche jetzt über unser Team. Die anderen Teams haben noch andere Software und auch andere Konfigurationen. Genau, ein Team kümmert sich sehr um ein großes SAP-System, was ganz viel Konfiguration hat. Ganz anders. Okay, wir haben unsere Konfigurationen alle in der Versionsverwaltung. Also alle dateibasierten Konfigurationen haben wir in einem Git-Repository liegen. Und darüber werden die verwaltet und werden dann auf die Server, allerdings im Moment noch per Hand, eingespielt. Zusätzlich haben wir einen Konfigurationsservice, der von anderen Services benutzt wird, wo man Konfigurationen in einer Datenbank einspielen kann. Da gibt es auch eine Art Versionsverwaltung zu. Das wären die beiden. Und die dritte Konfiguration ist im Moment in den Artefakten, in den eigentlichen Programmierartefakten direkt vorhanden. Das heißt, man kann sich das so vorstellen, wir haben verschiedene Stages nennen wir das, also Test, Dev-System, Test-System, Abnahmesystem, Produktivsystem. Und häufig so, dass die Artefakte, dass wir vier Artefakte bereitstellen, jeweils mit einer eigenen Konfiguration drin für jede Stage. Und diese Konfigurationen werden auch per Versionsverwaltung verwaltet. Dokumentation… fachliche Konfiguration häufig haben wir ein Wikisystem, wo wir vieles hinterlegen als Dokumentation oder direkt im Code würde ich sagen. Das sind die beiden Quellen. 34:38

R1: Was ist denn der größte Vorteil von eurer Verwaltung?

I7: Also was ich gut finde ist, dass wir alles in der Versionsverwaltung haben. Also hat man die ganze History, kann sehen wann was geändert wurde. Das sehe ich als unseren besten Punkt an.

R1: Und der größte Nachteil?

I7: Da sehe ich zwei Punkte. Einerseits ist es noch zu viel Handarbeit beim eigentlichen Deployment/Konfigurationsprozess dann. Und zweitens, die Testbarkeit. In dem Sinne, Testbarkeit in dem Sinne, wenn man ein produktives System konfiguriert, ist es schwer zu testen, ob die Konfiguration korrekt ist. Das sieht man dann erst, wenn das produktive System läuft und dann können sehr kleine Fehler auch schon große Auswirkungen haben.

R1: Okay, dazu kommen wir nachher. Gibt es denn spezielle Tools für das Verwalten und Dokumentieren von Konfiguration, die ihr nehmt? Außer jetzt vielleicht Git.

I7: Ich überlege… also bei uns im Team, wir haben da so ein paar kleine Skripte. Also wir haben ein paar kleine Tests geschrieben schon, also ganz grobe und wir haben ein paar Skripte um bestimmte Sachen auf Masse auszutauschen und—

R1: Aber keine externen jetzt irgendwie, die man sich besorgen kann sozusagen irgendwo.

I7: Im Moment nicht, ne. Außer ich vergesse die gerade.

R1: Wie werden denn Konfigurationen im Team kommuniziert?

I7: Oh. Okay, per Flurfunk. Teilweise also nicht besonders aktiv. Also wir haben auf alle Fälle Konventionen für bestimmte Sachen und die kennt jeder, jedes Teammitglied.

R1: Zum Beispiel?

I7: Also wie Einstellungsdateien heißen, in welchem Verzeichnis die liegen, wie man was konfiguriert, wo was liegt. Das ist alles pro—in unserem Team für jeden Dienst an der gleichen Stelle und jeder weiß dann was was bedeutet. Und bei Änderungen sieht man das eben über Versionsverwaltungssystem. Zusätzlich gibt es eben auch wieder in unserem Wikisystem Systembeschreibungen wie was zusammenhängt.

R1: Okay, was ist denn der größte Vorteil von—und auch der größte Nachteil dieser Art der Kommunikation?

I7: Also ich persönlich finde es ganz gut, dass wir Konventionen gemacht haben und dass sich auch alle daran halten, weil häufig ist es eben auch—machen Konventionen Sachen einfacher. Nachteil ist, es geht eben bei bestimmten Änderungen kommt doch nicht bei jedem alles an.

R1: Hast du da ein Beispiel wenn mal was durchrutscht oder so? Vielleicht welche typischen Fälle durchrutschen?

I7: Also wir hatten vor kurzem eine Umstellung—also das wäre so ein bisschen typisch—vor kurzem eine Umstellung von Windows- auf Linux-Systeme und dazu mussten eben die Dateipfade anders dargestellt werden und bei bestimmten Konfigurationen wurde das eben nicht kommuniziert und bei der nächsten Konfiguration wurde eben wieder ein Backslash statt einem Slash geschrieben. Irgendwie sowas in der Art. Das passiert ab und zu mal.

R1: Werden bei euch eigentlich bei Code-Reviews auch Konfigurationsdateien gereviewt?

I7: Ja.

R1: Wie ist da das Prozedere dabei?

I7: Das Prozedere? Eigentlich relativ simpel. Ein Mitarbeiter macht die Aufgabe, ein zweiter schaut sie sich dann im Merge-Request an und überprüft so gut wie er das weiß und kann. Also das ist immer nur ein Mitarbeiter überprüft das. Idealerweise eben bei Konfiguration Mitarbeiter, die im Release zuständig sind, die überprüfen das noch mal. Und wir arbeiten über Pull-Requests und in dem Zuge wird das auch überprüft. 41:14 

R1: Da ihr ja selber auch konfigurierbare Softwaresysteme erstellt: Nach welchen Kriterien und zu welchem Zeitpunkt werden Konfigurationsoptionen denn geplant und implementiert bei euch?

I7: Also, ich überlege gerade wo ich anfange. Normalerweise kommen, also sehr häufig kommen Änderungen oder Anforderungen für Änderungen an unserem System von den Kunden selbst und die setzen wir um. Und dann überlegen wir immer, sollte eigentlich schon in der Konzeptionsphase, nachdem die Anforderungen in den Konzeptionen kommt, überlegt, ist das nur für diesen Kunden notwendig, ist das für andere wichtig, ist das sofort für den einen Kunden, eigentlich für alle Kunden, immer gleich. Also muss man überhaupt etwas konfigurieren und wenn nicht, reicht es einfach die Funktion an- und auszuschalten oder braucht man eben bestimmte Parameter, die man einstellen kann. Da gibt es keinen strukturierten Prozess soweit ich weiß. Man versucht das immer so flexibel wie möglich zu halten, aber eben (?) das zum Teil mit der aktuellen Anforderung ab um nicht zu viel zu machen. Also man hat eine Anforderung für eine bestimmte Sache und wenn man jetzt das jetzt hochkonfigurierbar macht, wird der Aufwand meinetwegen doppelt so hoch. Kann durchaus möglich sein und das muss eben abwägen.

R1: Okay, das ist nämlich auch gerade die Frage. Wie viel Aufwand betreibt ihr denn zur Entwicklungszeit um Konfigurationsoptionen einzubauen?

I7: Das war jetzt nur ein Beispiel. Kommt immer darauf an. Also es ist immer—auf alle Fälle steht immer fest, dass unsere Software für mehrere Mandanten/Kunden konfigurierbar vorhanden sein muss und das wird dann immer mehr oder weniger gemacht. Und ich kann es jetzt nicht in Prozentzahlen ausdrücken, aber wird auf alle Fälle bei der Entwicklung beachtet. Unterschiedlich stark.

R1: Und wie viel Aufwand betreibt ihr denn in der Entwicklungszeit um tatsächlich zu konfigurieren? Also nicht einbauen, sondern zu konfigurieren.

I7: Ja, ist schon ein Teil. Wir sind wohl das Team mit der wenigsten Konfiguration, aber da wir jetzt schon auch schon, keine Ahnung, acht, neun Jahre an dem System arbeiten, ist halt schon ein Großteil auch schon da und wird eben auch bestimmt so 20, 30 % oder irgendsowas konfiguriert.

R1: Wie viel Aufwand betreibt ihr denn für die initial Einrichtung einer Konfiguration für Tools, Frameworks und Infrastruktur? 45:35 

I7: So ein Entwicklerrechner braucht schon glaube ich schon einen Tag bis alles läuft. Für einen neuen Server da nutzen wir, kopieren wir praktisch andere Konfigurationen im Moment. Das geht relativ schnell dann. Muss aber alles noch mal per Hand—weil das alles noch zum Großteil per Hand ist, muss das noch mal getestet werden.

R1: Dann ist es ja nicht—also was wir mit initial vielleicht meinen ist, es gibt noch nichts, wo du kopieren kannst.

I7: Achso. Mal überlegen.

R1: Also ich glaube das, was du in deinem letzten Projekt mit dem Release-Zyklus wahrscheinlich da gemacht hast.

I7: Also im Moment bauen wir immer an. Das heißt, das ist alles (?46:49 ) Standard. Irgendwie, wir konfigurieren, also mal eine neue Route konfigurieren im Proxy oder neue Datenbankverbindung konfigurieren dauert dann mal immer so ein paar Stunden, mit Test vielleicht einen halben Tag. Also ist es nicht per Knopfdruck.

R1: Also du kannst jetzt auch nicht sagen, wenn du jetzt neu deine Continiuous Integration/Delivery-Pipeline definieren würdest, wie lange, wie viel Aufwand—

I7: Achso, da wäre der—das kann ich gar nicht so einschätzen. Wenn ich die klassische Methode sehe, einen Jenkins-Job anlegen dauert halbe Stunde, irgendwie sowas, ganz neues Projekt anlegen wird eben—wir machen ja Maven-Projekte hauptsächlich, wird eben eine initiale Pom-Datei, da haben wir eben auch so ein paar Standards schon vorhanden, angelegt. Ich überlege gerade mal einen ganz neuen Dienst. Was haben wir denn da gemacht? Also Git-Repository anlegen, die Java-Struktur anlegen, das heißt als Pom-Dateien, initiale Schnittstellen, Startdateien, Tests anlegen, Jenkins-Job anlegen, beziehungsweise Jenkins-Files, Integrationstests—also ist schon Aufwand. Ich kann auch mal sagen, wie es mal werden wird. Wir haben jetzt Standard-Pipelines mit Tools als Jenkins-Files definiert und beim neuen Projekt kann man eben darauf zugreifen auf die Bibliotheken und teilweise werden die dann auch automatisch schon erkannt vom Jenkins und können auch halbautomatisch deployt werden. Aber so weit sind wir noch nicht. Also ist noch in der Entwicklungsphase. Ist auch gar nicht so unaufwändig meiner Meinung nach.

R1: Das ist ja praktisch ja das auch, was ich meine, ist ja irgendwie eine Richtung. Also habt ihr noch ein ganzes Projekt, was das ja erarbeitet.

I7: Genau, wir haben schon ein paar Lösungen, aber ist noch kein Standard bei uns, bei neuen Projekten, dass man sofort darauf aufsetzt. Zum Teil.

R1: Wie viel Aufwand betreibt ihr denn im Falle von Versionsänderungen oder anderen konfigurationsabhängigen Änderungen? Also Spring Boot geht von Version 1 auf 2 zum Beispiel oder so.

I7: Ich habe bisher nur zwei Änderungen mitgemacht. Von Java 6 auf 7 und von Java 7 auf 8 und von Spring Framework 3 auf 4, so ist alles schon ein bisschen älter. Das war damals noch riesen große Projekte von drei Monaten mindestens oder länger. Das war die letzten Erfahrungen. Mittlerweile stellen wir jetzt auch auf Spring Boot um Schritt für Schritt und das dauert aber auch länger.

R1: Okay, was ist denn für dich der größte Faktor, der den Konfigurationsaufwand bestimmt?

I7: Unterschiedlich, bei Konfigurationsaufwand. Was meinst du jetzt mit Faktor? Was bei uns jetzt so am längsten dauert oder was ich denke, was der schlimmste ist bei der Konfiguration oder was den Aufwand bestimmt?

R1: Was der Aufwand bestimmt.

I7: Kommt auf die Größe der Konfiguration an. Also gerade wenn du jetzt Versionänderung sagst, da ist natürlich auch Entwicklungsaufwand dabei, aber auch sehr viel Test. Bei den anderen Sachen. Kommt auf die Größe an. Bei so kleineren Sachen ist die ganze Deploymentfrage das zeitbestimmende. Also bei einer sehr kleinen Änderung, wenn die Änderung nicht von außen änderbar ist. Also wenn beim Artefakt direkt die Property/Einstellungsdatei vorhanden ist. Also nicht irgendwie extern vorliegt. Das ist natürlich das ganze Deployment und alles, was Releasearbeit dazu das aufwändigste. Wenn es von außen änderbar ist, bestimmt der Aufwand die Informationsbeschaffung. Also wichtig ist also alles, was—finde ich—alle Konfigurationen, die irgendwie extern gemacht werden können. Also so Einstellungen, also eine Versionsänderung wird wahrscheinlich nicht gehen. Dann ist für mich wichtig, dass die auch außerhalb vom Artefakt gemacht werden kann. Das heißt, dass man nicht neu kompilieren muss, neu durch die Deployment-Pipeline ein neues Artefakt bauen muss und die im Release mit reinpacken muss und alles sowas. Idealerweise während der Laufzeit wäre das tollste wenn das geht. Oder mindestens wenn man nur neu deployen muss, mit einer neuen Konfigurationsdatei. Kleiner Restart würde auch noch gehen. Was du gesagt hast, mit einer neuen Framework-Version, wäre es gut wenn innerhalb eines Teams überall auch die selben, was ich vorhin gesagt habe, die selben Konventionen eingehalten wurden und überall idealerweise auch Tests vorliegen, dann kann man es relativ zentral alle ähnlich auf eine neue Version hochziehen die Services und Systeme. Da würde ich eben solche Sachen als bestimmenden Faktor sehen. Bei der fachlichen Konfiguration bestimmt eben auch alles, die Konfigurationen sind sehr unterschiedlich von der Art.

R1: Benutzt ihr Konfigurierbarkeit auch um nicht-funktionale Eigenschaften wie Performance zu tunen?

I7: Ja, in der Infrastruktur zum Teil. Was weiß ich, Connection Pooling in der Datenbank ist das einfachste. Haben wir mal was anderes gemacht, wo wir Funktionen ausgeschaltet haben um bessere Performance reinzukriegen? Das weiß ich nicht.

R1: Also teilweise dann ja. Gut, dann gehen wir mal zu den Konfigurationsfehlern über, zu dem Topic. Jetzt wird es schön. Stellt denn die Konfiguration von Systemen, Tools und Infrastruktur und so weiter euch vor Probleme?

I7: Zum Teil. Meiner Meinung nach fehlt irgendwie noch, auch bei Codereviews kann man immer noch Sachen übersehen. Also für mich ist das große Problem, dass da—also es gibt zwei große Probleme. Einerseits das manuelle Deployment von Konfiguration, also eine Konfigurationsdatei austauschen auf dem Server. Es gibt zwar da einen Prozess für und das ist auch schon gut geworden, aber noch nicht perfekt. Aber es kann durchaus sein, dass auf dem Server eine andere Version liegt als im Repository. Das ist technisch möglich. Und so lange das technisch möglich ist, kann es auch passieren. Und die zweite Sache, also die Testbarkeit. Produktive Konfiguration, Testbarkeit habe ich schon alle Arten von falscher Konfiguration gesehen, die bei uns möglich waren. 57:07 

R1: Genau, das sind also auch die schwerwiegendsten Probleme? Super. Was sind denn die—was denkst du was die Ursachen für diese Schwierigkeiten sind?

I7: Mehrere Dinge. Hat hauptsächlich was mit Prozessen und der Einrichtung der Infrastruktur und Tools zu tun, würde ich fast sagen. Also (?57:44 ) mit der Software. Einerseits müssten Test- und Produktivsysteme, die sind fast gleich, aber eben nicht ganz gleich. Also die müssten da noch gleicher werden sozusagen. Damit man einfach Konfiguration auf einem Testsystem besser testen kann, schon da. Und ich kann dir ein Beispiel geben, zum Beispiel produktiv heißt der Server Prod-Server1 beispielsweise und auf dem Testsystem heißt der Test-Server1. Mit einem unterschiedlichen Port auch noch und wenn man dann zum Beispiel einmal Port 443 und auf Test 444. Und wenn man dann ausversehen als Entwickler 444 für Prod eingibt, hat man ein Problem. Sieht man auch erst wenn man beim Produktiv das auch ausführt. Wenn man jetzt ein Kubernetes-Cluster angibt, werden solche Abhängigkeiten logisch definiert. Also man sagt da einfach nur Service1 oder Service2, ich habe eine Abhängigkeit zu Service1 und die Infrastruktur sagt dann eben Service1 ist hier, Prod-Server1 und auf dem Testsystem ist Test-Server1. Also solche Unterstützen bei der Konfiguration durch den Entwickler eher logische Sachen macht, dass man das trennt. Infrastruktur und logische Konfiguration. Dann kann man es auch besser testen. Und Toolsupport. Also dass man möglichst Deployments automatisiert. Wenn die automatisiert sind, ist da auch ein Tool und dieses Tool, was das macht, kann man wieder testen. So die Theorie. Praktisch ist das schwierig umzusetzen bei uns.

R1: Schreiben wir mal Ansible rein. Was ist ein für euch denn schwer zu konfigurierendes Tool und warum genau das? 1:00:07 

I7: Da gibt es eigentlich, würde ich—also die Tools und Frameworks, die wir benutzen, sind für uns nicht schwierig zu konfigurieren. Eigentlich ist mehr allgemein, eher so fachliche Neben—falsch, also so allgemein zu konfigurieren, die Tools, die wir benutzen bisher, sind nicht schwer zu konfigurieren. Jetzt, wenn ich meinen Kollegen sehe, der Kubernetes-Cluster baut, da ist doch die Lernkurve sehr steil, da kann man ganz viel machen und das ist ein größeres Projekt, weil da auch noch viel mehr dazu kommt. Aber so, nicht technisch schwierig zu konfigurieren, sondern eigentlich organisatorisch, also dass man immer diese richtigen Werte hat, beispielsweise.

R1: Ist eigentlich die Konfiguration von miteinander interagierenden Tools und Frameworks problematisch?

I7: Teilweise. Also wenn man jetzt, weiß nicht viel Java ihr schon programmiert habt, wenn wir jetzt sagen wir mal, da ist man vielleicht häufiger schon drauf gekommen: Man hat zwei externe Bibliotheken und die nutzen andere Bibliotheken unterschiedlicher Versionen und die können eben kompatibel sein. Da, solche Sachen sind anfänglich schwierig manchmal zu konfigurieren um die richtigen Versionen zusammenzubringen, aber dann ist es bei uns dann so, wenn man einmal damit fertig sind, dann bleibt das erstmal stabil für eine Zeit lang. Also das wäre eine Konfiguration. Ansonsten immer wenn es, komme ich wieder auf die Versionsänderungen, aus verschiedenen Gründen, es braucht natürlich einen größeren Testaufwand. Ein anderes Team hat beispielsweise die Oracle-Version geändert—Zwei Anekdoten jetzt. Also, ein anderes Team hat die Oracle-Version geändert, das heißt, wir haben einen Test gemacht und schon mussten wir die Treiber-Version ändern und der hatte irgendwas anderes gemacht. Ja, da musste man rumkonfigurieren. Oder umgekehrt, wir haben eine Framework-Version geändert und plötzlich war, wurde etwas validiert, was vorher optional und schon gab es dann Fehler im Zusammenspiel mit anderen Teams. Also solche Sachen passieren immer wieder. Also ziemlich locker gekoppelte Systeme zum Teil.

R1: Was sind denn für dich eigentlich Konfigurationsfehler und wie unterscheiden die sich von normalen Bugs?

I7: Wenn ich das—die einfachste Definition ist, alles was in Einstellungsdateien schiefgegangen ist oder ein bisschen allgemeiner: Wenn an dem eigentlichen Artefakt, an dem Quellcode nichts geändert werden muss, sondern nur irgendeine Konfiguration, eine Einstellung geändert werden muss. Und wenn die dann falsch ist, dann ist das für mich ein Konfigurationsfehler. Das wäre die Infrastruktur. Bei den Funktionen, da ist das fließender würde ich sagen. Also bei der fachlichen Konfiguration, da gibt es ja auch unterschiedliche Level. Manchmal ist es da auch nur eine Einstellungsdatei, also Parameter A oder Parameter B und Wert A und B und manchmal ist es aber wirklich, man muss da irgendwelche Klassen ableiten oder Funktionen in eine if-Anweisung—teilweise selbst mit einer if-Anweisung oder aus einer Properties-Datei irgendwie, liest man irgendeinen Parameter aus und von da aus gibt es im Code verschiedenste if-Alternativen. Und da ist es dann fließend, was Konfiguration ist oder Code-Bug.

R1: Welche Auswirkungen von Konfigurationsfehlern sind denn häufig bei euch?

I7: Ja, bestimmte Prozesse gehen nicht. Also vollständig nicht. Keine Ahnung, das Kundenportal funktioniert nicht vollständig. Die API nach außen funktioniert nicht vollständig. Das heißt darauf aufbauende Apps oder Portale haben Ausfälle. Bestimmte Prozesse werden nicht angestoßen oder—Daten gehen jetzt verloren klingt jetzt zu hart, das passiert eigentlich nicht, aber es sind schon schwierige Ausfälle. Sehr akut und sehr leicht zu lösen dann zwar, aber haben dann auch gleich eine große Auswirkung.

R1: Okay, auch Performance auch Auswirkungen oder ist das für euch eher nicht…

I7: Performance? Selten. Da hatten wir bisher—vielleicht ist unsere Last zu wenig. Ne, hatte auch Performance-Auswirkungen, ja, teilweise. Wenn zu wenig Speicher an so einen Java-Prozess vergeben oder sowas.

R1: Gibt es einen Unterschied zwischen falscher und schlechter Konfiguration?

I7: Ja. Schlecht würde ich jetzt so definieren, dass es immer noch geht, aber entweder die Performance nicht gut ist oder zu viele Ressourcen verbraucht werden oder zu komplex ist. Das wäre die schlechte Konfiguration. Und die falsche ist, es funktioniert gar nicht. So würde ich das definieren.

R1: Also du hast ja schon Konfigurationsfehler erlebt. Kannst du denn vielleicht noch einen besonders schwierigen Fall rekapitulieren? Schwerwiegenden, also.

I7: Schwerwiegenden? Wir hatten mal eine Schema-Validierung eingeschaltet—das ist jetzt ein Zwischending zwischen Bug und Konfiguration—bei unseren Diensten haben wir eine Schema-Validierung eingeschaltet. Die Schema-Validierung war sehr inperformant programmiert. Das heißt bei jedem Request wurde so eine sehr teure Operation ausgeführt, in dem Fall wurde eine WLSD-Datei oder XSD vollständig neu geparst jedes Mal und bei sehr vielen Requests pro Minute, pro Sekunde, stört das erstmal einen Dienst. Da unser System aber auch ein bisschen sensibel auf Störung eines Dienstes reagiert, ist immer alles dann kaputt gegangen. Also wirklich, waren die Portale nach kurzer Zeit bei etwas größerer Last dann nicht mehr erreichbar. Teilweise waren andere Dienste in Mitleidenschaft gezogen, die dann wieder vom Backendsystem benutzt wurden. Das heißt die Prozesse liefen dann auch nicht mehr korrekt. Und dieser Fehler war auch schlimm, weil der nicht sofort akut war, sondern das wurde immer schlimmer mit den Performance-Problemen, also hat man mehr die Kiwi(?)-Methode andewendet, also mehr Power reingestellt in die VMs, aber irgendwann war es dann überhaupt nicht mehr lösbar und nur über ein Profiling haben wir es dann sofort gesehen. Also es war wirklich in der Konfiguration der Schema-Validierung und die Validierung selbst war inperformant und deswegen—

R1: Das heißt der schwierigste Fehler war bei euch eine schlechte Konfiguration und keine falsche?

I7: Ja, ne das war die interessanteste. Ich weiß nicht, ob das schwer—ja, wir hatten lange damit zu tun bis wir die Wurzel des Übels gefunden haben, Root Cause.

R1: Wie lange habt ihr da eigentlich so gebraucht dafür um das…?

I7: Na das ganze Problem zog sich über sagen wir mal drei, vier Monate hin. Das war ja nicht sofort akut. Man hat nur gesehen, dass wir sehr viel mehr CPU-Ressourcen verbraucht haben. Und dann hat man gesagt, okay geht noch. Und bei unserem Geschäft ist es so, dass es am Jahresende sehr viel mehr Last vorhanden ist und da hat es dann gar nicht mehr funktioniert. Wir haben auch vorher schon überlegt woran es liegt und wir haben, also ich war es sogar, ich habe dann sowas so gesagt „Ja, daran kann es doch nicht liegen.”, aber lag daran. Wir haben es nicht getestet. Andere Fälle sind einfach mal—wir hatten noch einen anderen Fall, das war ein automatischer Email-Prozess, da war die Empfänger- und die Sender-Email falsch konfiguriert. Das heißt weder sind die Emails angekommen, noch hat man Informationen bekommen, dass die Emails nicht angekommen sind. Das heißt man hatte nicht mal eine Chance zu sehen, dass da was falsch war.

R1: Ja, wie häufig treten denn Konfigurationsfehler bei der Projektarbeit auf? Also jeden Tag, jede Woche oder jeden Monat?

I7: Für unseren Geschmack zu häufig, deswegen wollen wir uns ja verbessern auch. Ja, es passiert dann schon im Monat sage ich mal. Einmal im Monat.

R1: Also einmal im Monat, der in die Produktion geht, oder?

I7: Testsystem vielleicht häufiger mal, aber da ist es nicht so wichtig. Aber produktiv kommen Produktionsfehler dann schon mal wirklich vor. Vielleicht ein bisschen weniger. Aber so viel, dass es uns aufgefallen ist.

R1: Wenn man so die Projekthistorie sieht, wann treten dann typischerweise Konfigurationsfehler auf? Am Anfang, beim initialen Aufsetzen oder bei Upgrades von Komponenten oder bei geänderter Infrastruktur oder sowas.

I7: Beim Aufsetzen. Ansonsten bei Änderungen jeglicher Art. Gleichverteilt. Aber bei neuen Funktionen glaube ich noch ein bisschen häufiger als bei Änderungen.

R1: Gibt es generell Unterschiede bei Konfigurationsfehlern zwischen fachlicher und technischer Konfiguration?

I7: Technische Konfigurationen kommen häufiger vor. Fachlich, bei der fachlichen Konfiguration entstanden die meisten Fehler eher aus dem Konzept oder aus der Anforderung, also dass es schon falsch angefordert wurde. Während technisch eher bei uns eher Schusselfehler sind.

R1: Wie geht ihr denn typischerweise vor um Konfigurationsfehler zu finden und zu beheben?

I7: Also was ich mal gemacht habe, ich habe einen Test geschrieben, zum Beispiel für abhängige Dienste, die über eine Web-URL definiert sind. Also wir geben die HTTP-URL an von dem Dienst. Haben wir beispielsweise einen Test geschrieben, dass in produktiven Properties-Dateien keine Testservernamen vorhanden sind. Was war das? Beheben oder verhindern?

R1: Vorzubeugen ist die nächste Frage. Eher zu finden und zu beheben.

I7: Also verhindern: Tests und Code-Review und teilweise automatisierte Tools. 1:16:03 Ja, ein paar Konfigurationen sind automatisiert. Automatisiert heißt es ist entweder alles falsch oder alles richtig. Und beheben besteht aus meiner Sicht aus zwei Sachen: Also erstmal den Fehler finden, woran es liegt und unsere Monitoring-Tools und Logfile-Zentralisierung und -Suche und -Analyse. Und das zweite ist beheben. Das ist meistens ein neues Deployment.

R1: Okay, StackOverflow oder so, googeln?

I7: Ach so eine Konfiguration. Ja. Also in dieser Hinsicht. Ja, genau. Google. Bei dem schlimmen Fall mit der Schema-Validierung haben wir auch eine externe Firma auch mal beauftragt, dass sie uns die Wildfly-Konfiguration optimiert, aber letztendlich lag es daran gar nicht, sondernan diesem kleinen Modul. Das heißt, Google zum Finden von Performanceproblemen, Profiler, Logfiles für Monitoring um fehlerhafte Konfigurationen zu finden, sieht man dann schon sowas wie einen 404 oder ähnliches, NotFound-Exceptions… und um die richtige Konfiguration zu finden, hauptsächlich Selbststudium. Und wenig externe Consultants und Hilfen.

R1: Was für Verbesserungsbedarf siehst du, was würdest du dir wünschen um vielleicht Konfigurationsfehler zu beheben oder besser zu identifizieren?

I7: Was ich schon gesagt habe: Testbarkeit und automatische Tools, automatisches Deployment. Was ich von anderen mal gehört habe, dass sie Compliance-Regeln für bestimmte Sachen eben auch zentral aufgestellt haben und dagegen automatisch testen. Also ich bin ein Fan von automatisch testen und automatischen Tools und—genau, bei der reinen technischen Konfiguration, also sowas. Und bei der fachlichen Konfiguration, alle Sachen, die man extern ablegen kann, irgendwo extern halten. Extra halten. Vom Code. Dass eben Konfiguration und Code schön sauber getrennt ist und, dass man das flexibel behandeln kann.