Deployment-Know-how: Ein Muss für Entwickler_innen?

In Gesprächen mit technischen Leitern und CTOs habe ich oft eine Sache gehört: Sie erwarten, dass jede_r Entwickler_in im Team weiß, wie die zu entwickelnde Software deployed wird. Wenn ich nach dem “Warum” frage, ist die Antwort: Entwickler_innen werden dadurch zu besseren Entwicklern_innen.

In diesem Blogbeitrag möchte ich einen kritischen Blick auf auf diese Argumentation werfen. Verbessern Kenntnisse über das Deployment die Arbeitsweisen von Entwickler_innen? Macht es Entwickler_innen “besser”? Wenn ja, wie? Und wie lernen Entwickler_innen am besten etwas über das Deploymen-Thema?

Zu diesem Thema habe ich auch ein Video aufgenommen:

https://www.youtube.com/watch?v=ZaEFX5DS25g

Warum wissen eigentlich die meisten Entwickler_innen über das Deployment bescheid?

Die meisten Entwickler_innen führen die Software, an der sie arbeiten, lokal in Ihrer Entwicklungsumgebung aus. Aus diesem Grund wissen Entwickler_innen vieles über das Deployment ihrer Software: Weil sie dies regelmäßig tun, um ihre Codeänderungen in lokalen Deployments zu validieren.

Die traurige Wahrheit ist aber, dass Deployments oft sehr kompliziert sind und Entwickler_innen viel Zeit und Nerven darauf verwenden, lokale Deployments zum Laufen zu bringen.

Glücklicherweise gibt es eine Alternative. Cloud Development Environments (CDEs) ermöglichen es Entwickler_innen, private “Spielwiesen” zu haben, in denen sie ihre Codeänderungen validieren können, bevor diese an ein gemeinsames Repository commited werden. CDEs entsprechen funktionell einem lokalen Deployment. Der Unterschied ist, dass sie vollständig automatisiert sind und Entwickler_innen remote zur Verfügung stehen. Mit CDEs können Entwickler_innen ihren Code in ihrer eigenen privaten Umgebung – in der CDE – schnell builden, testen und deployen- und das, ohne etwas über das Deployment wissen zu müssen und ohne die Gefahr, die Arbeit anderer Entwickler_innen zu stören.

Deshalb ist es sinnvoll zu fragen, ob Entwickler_innen über das Deployment der Software Kenntnis haben müssen. Vor CDEs gab es eigentlich keine andere Möglichkeit. Da es jetzt eine Alternative gibt, sollten wir den Umfang dessen, was Entwickler_innen tun und wissen müssen, neu überdenken.

Was sind die Vorteile, wenn man über das Deployment Bescheid weiß?

Wenn Entwickler_innen wissen, wie sie ihre Software einsetzen, können sie beim Coden bessere Entscheidungen treffen, insbesondere in Bezug auf:

Konfiguration ihrer Software
Kernarchitektur ihrer Software

#1 Konfiguration

Wenn Entwickler_innen die Software selbst einsetzen, wissen sie normalerweise genau, wie diese Software konfiguriert werden muss. Da Entwickler_innen auch diejenigen sind, die entscheiden, wie die Konfiguration für ihre Software spezifiziert werden kann, ist es wahrscheinlich, dass sie bei der Entwicklung von Features die User Experience der Benutzer_innen berücksichtigen. Dies ist wahrscheinlich der größte Vorteil, wenn Entwickler_innen gezwungen werden, ihre Software selbst zu deployen. Entscheidungen über die Konfigurationsmöglichkeiten einer Software sind im Backend häufig zu treffen.

#2 Architektur

Die Kernarchitektur einer Software hat einen großen Einfluss darauf, wie einfach oder komplex das Deployment ist. Das Deployment muss daher bei der Entscheidung über die Kernarchitektur berücksichtigt werden. Da Architekturentscheidungen aber in der Regel zu einem frühen Zeitpunkt in der Entwicklung einer Software getroffen werden, müssen die Entwickler_innen oder CTOs wissen, wie sie ihre Software einsetzen wollen. Für die Mehrheit der Softwareentwickler_innen ist das aber irrelevant.

Bleibt also nur noch die Konfiguration. Es ist zweifellos richtig, dass Entwickler_innen, stärker motiviert sind, eine Software leicht konfigurierbar zu machen, wenn diese schwer nur konfigurierbar ist. Aber sich darauf zu verlassen, um eine gut durchdachte Konfiguration für eine Software sicherzustellen, ist eine schlechte Idee. Wie jeder Aspekt, der einen großen Einfluss auf die Benutzer_innenerfahrung hat (in diesem Fall die Erfahrung des Deployments- und Operations-Teams), sollte er von Spezialisten_innen entworfen werden. Idealerweise wird sofort eine Anleitung für die Konfiguration einer Software erstellt, an die sich andere Entwickler_innen orientieren müssen. So funktioniert Feature-Design. Ansonsten wird jede_r Entwickler_in selbst entscheiden, was für eine „gute und einfache Konfiguration“ gehalten wird. Das ist für jede_n Entwickler_in anders und führt wahrscheinlich zu einer schlechten Erfahrung mit der Konfiguration.

Was sind die Nachteile, wenn man über das Deployment Bescheid weiß?

Es gibt zwei Nachteile, wenn Entwickler_innen wissen müssen, wie sie ihre Software deployen können:

Es frisst Zeit und Nerven.
Nur wenige Menschen haben die Fähigkeit und die Neigung, sowohl im Programmieren als auch im Deployment gut zu sein.

#1 Zeitverlust

Es ist ein Unterschied, ob man über das Deployment Bescheid weiß oder ob man seine Software im Rahmen der täglichen Arbeit regelmäßig auf dem eigenen Laptop deployen muss. Letzteres ist leider die traurige Realität für viele Entwickler_innen und es wird mit der „Notwendigkeit, über das Deployment informiert zu sein“ begründet. Ich habe bereits beschrieben, dass das Wissen über das Deployment einer Software für Entwickler_innen nur einen geringen Nutzen hat. Hinzu kommt der zweite Irrglaube, dass lokale Deployments als Teil der Arbeit von Entwickler_innen ein guter Weg sind, um ihnen die Dinge beizubringen, die sie über Deployments wissen sollten. Das ist nicht der Fall.

Wenn Sie möchten, dass Ihre Entwickler_innen den Aufwand des Deployments kennenlernen, lassen Sie sie die Software im Rahmen ihres Onboardings oder als regelmäßige Übung von Zeit zu Zeit manuell deployen. Wenn Sie wirklich glauben, dass das Wissen über das Deployment für Ihre Entwickler_innen wertvoll ist, dann ist dies eine gute Möglichkeit, es ihnen beizubringen. Und wenn das Deployment mühsam ist, werden sie sich sehr gut daran erinnern.

Wenn Entwickler_innen täglich lokale Deployments vornehmen, gewöhnen sie sich an viele der damit verbundenen Schwierigkeiten und verlieren das Bewusstsein dafür. Damit entfällt sogar der geringe Nutzen des Wissens über Deployments: Sie versuchen vielleicht nicht einmal mehr, es besser zu machen.

Das Schlimmste aber ist, dass es Entwicklern_innen täglich Zeit und Kopfzerbrechen bereitet. Viele Unternehmen sind sich über diesen Kostenfaktor gar nicht bewusst, da die Zeit, die für die Fehlerbehebung bei lokalen Deployments aufgewendet wird, in der Regel nicht separat erfasst wird. Stattdessen wird sie zu jeder Aufgabe hinzugezählt. Die für das lokale Deployment aufgewendete Zeit kann aber bis zu 25 % der Zeit (in extremen Fällen) in Anspruch nehmen und liegt in der Regel zwischen 5 und 10 % der Zeit, wenn alles einigermaßen gut funktioniert.

Das ist eine MENGE an Zeit!

#2 Der Mythos: Full-Stack-Entwickler_innen

Der Umfang dessen, was ein_e Entwickler_in wissen sollte, ist scheinbar endlos. Auch, wenn es viele spezifische Berufsbezeichnungen für gibt, deren primärer Fokus auf dem Deployment und dem Betrieb von Software liegt (Operations, Devops, Site Reliability Engineer (SRE), …), wird von Entwicklern_innen oft erwartet, dass sie diese Funktionen zusätzlich zu ihrer primären Aufgabe erfüllen. Oft kommen auch Testing, User Experience, Architektur, Backend- und Frontend-Entwicklung dazu, was zu dem umfassenden Berufsbild “Full-Stack-Entwickler_in” geführt hat.

Es gibt Menschen, die mit vielen Aspekten der Softwareentwicklung bestens vertraut sind und die mit Fug und Recht behaupten können, Full-Stack-Entwickler_in zu sein. Aber bei den meisten Entwickler_innen wird die Arbeit als Full-Stack-Dev zu Produkten wie diesem führen:

Die Wahrheit ist, dass von einer Spezialisierung enorm profitiert wird. Man viel schneller ein höheres Maß an Produktivität und Fachwissen.

Dies gilt insbesondere für komplexe Software. Moderne Unternehmenssoftware besteht heutzutage oft aus vielen Komponenten und einer hochkomplexen Deploymentlogik. Solange das Deployment mit einem einfachen „npm run build“ ausgedrückt werden kann, ist jede_r Entwickler_in in der Lage, damit umzugehen. Aber das ist kaum noch der Fall. Viele Entwickler_innen verbringen 10 % oder mehr ihrer Zeit nur mit der Verwaltung lokaler Deployments. Den größten Teil dieser Zeit verbringen sie mit der Fehlersuche. Für die Fehlersuche bei lokalen Deployments müssen Entwickler_innen aber nicht nur Zeit aufwenden, sondern auch viel über Tools wie Docker oder Minikube oder andere Tools wissen, die speziell für das Deployment ihrer Software geeignet sind.

Das heißt: Wenn man von Entwicklern_innen ein sehr breites Kompetenzspektrum erwartet, wird die Mehrheit eine solche Rolle nicht erfolgreich ausfüllen können. Selbst die wenigen Full-Stack-Entwickler_innen die es gibt, werden Spezialgebiete und Bereiche haben, in denen sie weniger gut sind. Leute zu finden, die in einem Bereich gut sind, ist viel einfacher und führt zu viel besseren Ergebnissen für alle.

Take the productivity of your IT team to the next level. With Remote Development Environments

In this whitepaper you will learn how RDEs can improve your team’s productivity and the quality of software development in your organisation.

Download now

Fazit

Das Deployment ist ein wichtiger Aspekt einer Software. Es ist wahrscheinlich für die meisten Entwickler_innen eine gute Idee, zumindest ein wenig über das Deployment ihrer Software zu wissen. Ähnlich wie es für jede_n Entwickler_in eine gute Idee ist, zu wissen, wie die Software, an der gearbeitet wird, verwendet wird. Damit sind bessere Entscheidungen hinsichtlich der Benutzerfreundlichkeit möglich.

Es ist aber nicht üblich, dass Entwickler_innen selbst Entscheidungen über die Benutzerfreundlichkeit treffen (oder ihnen dies anvertraut wird), selbst wenn sie die Software sehr gut kennen. Es gibt nicht ohne Grund User Experience Designer_innen. Hier handelt es sich um ein komplexes Fachgebiet, das Kenntnisse erfordert, die sich nicht unbedingt mit denen von Entwicklern_innen überschneiden.

Genauso verhält es sich mit dem Deployment. Es gibt nicht ohne Grund Deployment-Experten_innen. Es ist ein komplexes Fachgebiet, das nicht jede_r Entwickler_in zusätzlich beherrschen sollte. Von Entwicklern_innen sollte verlangt werden, dass sie Best Practices oder unternehmensinterne Richtlinien befolgen, wenn sie Entscheidungen treffen, die das Deployment beeinflussen. Aber sie sollten sich nicht jeden Tag stundenlang mit lokalen Deployments herumschlagen müssen.

Meine Schlussfolgerung: CTOs und technische Leiter erwarten von ihren Entwicklern_innen, dass sie sich um das Deployment kümmern, denn:

Das war schon immer so und es ist vielleicht noch nicht erkannt worden, dass das nicht mehr nötig ist.
Das Wissen um Deployments dient als Indikator für die allgemeinen Fähigkeiten und Kenntnisse von Entwickler_innen. (Ich könnte es auch noch unverblümter ausdrücken: Es propagiert den wenig hilfreichen Stereotyp der_s allwissenden Full-Stack-Entwicklers_in als ideale_n Entwickler_in.)

Keiner der beiden Gründe hält einer genaueren Prüfung stand.

Es ist teuer und hat wenig Vorteile

Zusammengefasst: Nur wenige Entwickler_innen haben die Neigung, die Erfahrung und die Fähigkeiten, um das Klischee des_r Full-Stack-Entwicklers_in zu erfüllen. Das Wissen über das Deployment einer Software hat bestenfalls marginale Vorteile, erfordert aber viel Zeit und Energie, um es zu lernen und zu managen.

Folglich ist es eine große Zeitverschwendung, Entwickler_innen zu zwingen, sich mit Docker, Minikube, Netzwerkkonfigurationen und einer ganzen Reihe anderer Dinge und Tools zu beschäftigen, die sie nur für das lokale Deployment benötigen. Entwickler_innen tun dies oft auch nicht einmal gerne. Es wirkt sich sowohl auf die Produktivität, als auch auf die Zufriedenheit aus.

Das ist eine gute Nachricht! Es bedeutet, dass sich Entwickler_innen sehr viel Zeit und Nerven sparen können, wenn sie nicht mehr viel Zeit in das lokale Deployment investieren müssen. Es gibt hier eine riesige Chance, Entwickler_innen glücklicher und produktiver zu machen.

Und glücklicherweise ist es einfach möglich, Entwicklern_innen die Mühen des lokalen Deployments zu ersparen. CDEs sind Tools, die speziell für diesen Zweck entwickelt wurden. Sie ermöglichen es Entwicklern_innen, vollen Fokus aufs Coding legen zu können, ohne sich um das Deployment kümmern zu müssen.

Mehr über CDEs: