DevOps ist kein Feature und kostet nur Geld

DevOps und DevSecOps sind zentrale Elemente in jedem modernen Entwicklungsprozess. Diese Praktiken bringen Sicherheit, Stabilität und reduzieren die Kosten in der Softwareentwicklung.

DevOps und DevSecOps werden oft als unnötige Kosten betrachtet. Wozu benötige ich das? Es funktioniert doch! So denken leider immer noch viele Unternehmen, die die Qualität und die Sicherheit ihrer Produkte händisch sicherstellen wollen. Es ist enttäuschend, dass ich immer noch zu oft auf diese Sichtweise stoße. Daher möchte ich kurz ein paar bekannte Aussagen bezüglich DevOps andiskutieren.

Ein Beispiel als Ausgangssituation: Warum DevOps? Warum DevSecOps?

Wenn ein Unternehmen sich eine QA als Fachabteilung leistet, dann liegt natürlich die inhaltliche Frage nahe: Was bringt mir das Investment in die Dev(Sec)Ops Landschaft?

Oft höre ich eine der folgenden Aussagen gegen DevOps:

  • Läuft doch: “Der Prozess ist gut dokumentiert sowie standardisiert und ein hochqualifiziertes Team überprüft und protokolliert Qualität sowie Sicherheit jeder Release!”
  • Zu kompliziert: „Das hört sich super an! Bei uns funktioniert das aber nicht. Unser Entwicklungsprozess und Freigabeprozess ist viel zu kompliziert!“
  • Kein Feature„DevOps kostet nur Geld und bringt uns keine neuen Features, die wir verkaufen können. Der Kunde verlangt Features und keine DevOps-Infrastruktur!”

Leider folgt auf diese Aussagen noch eine Ausrede: “Never change a running system!” → die Ausrede killt jeden Verbesserungsprozess!

Okay, lassen wir die Aussagen stehen und stellen ein paar Fragen an alle, die sich bei diesen Aussagen zu Hause fühlen:

  • Kosten: Was kosten Hotfixes (z.B. eine Sicherheitslücke) die erst in der Fachabteilung, kurz vor der Release oder sogar erst beim Kunden auftauchen? Was bedeutet das für dein Image?
  • Kapazitäten: Wie viel Zeit kostet eine Release bzw. Freigabe und wieviele Kapazitäten werden dadurch gebunden? Wieviele Releases kann ein Team pro Jahr freigeben?
  • Effektivität: Wie effektiv, wie oft oder wann testet die Fachabteilung das Produkt? Wird die Software getestet, wenn es fachlich sinnvoll ist oder sind die Kriterien eher der Kostenfaktor?
  • Reaktionszeit: Wie siehts mit der Release-Reaktionszeit aus? Wie schnell kann auf Sicherheitslücken oder Safety-Themen reagiert werden?
  • Agilität: Warum arbeiten viele Software-Häuser noch nach dem Wasserfallmodell? Ist das Iterative Testen und die Freigabe von einem neuen Feature zur Entwicklungszeit zu teuer?
  • Schulden: Wieviele technische Schulden ist eine Release wert?

Wenn wir ehrlich sind, dann sind die Antworten auf diese Fragen nicht immer befriedigend, denn bei einer herkömmlichen Entwicklung ist die Antwort mit viel Aufwand und Geld verbunden.

Also stellen wir uns doch folgende Frage:Wie viele hochwertige Features könnten entwickelt werden, wenn wir eine automatisierte DevOps-Infrastruktur hätten, die die Entwicklung und Freigabe effizienter gestaltet?

Wie hilft DevOps?

Als Beispiel eine Analogie zum Maschinenbau und zur Industrialisierung: Früher wurden Autos manuell von Hand hergestellt. Mittlerweile sind die Produktionslinien automatisiert und niemand würde mehr auf die Idee kommen, ein Auto händisch herzustellen. Also vergleichen wir doch mal ein Auto mit einem Softwareprodukt: Mit Dev(Sec)Ops erhalten wir eine Produktionslinie für unsere Software Produkte und Projekte, welche die Entwicklung beschleunigt und die Qualität enorm verbessert. Bei einem Auto scheint das offensichtlich zu sein, warum also nicht auch bei der Softwareentwicklung? Der einzige manuelle Schritt ist die Entwicklung in einer IDE selbst. Für alle weiteren Themen bietet DevOps unter anderem folgende Lösungen an:

  • Kosten: Die frühzeitige und automatisierte Entdeckung von Problemen, iterativ zur Entwicklungszeit, wirkt sich positiv auf die Kosten der Fehlerbehebung aus. Generell gilt: Je früher ein Problem erkannt wird, desto günstiger wird es zu beheben sein.
  • Automatisierung: Von Build über Tests bis hin zur statischen Code-Analyse und Freigabe werden sämtliche Prozesse rund um das Produkt automatisiert, was Zeit spart und die Zuverlässigkeit erhöht.
  • Kapazitäten: Durch Automatisierung ist die Anzahl der Releases nicht mehr durch die Kapazität der QA-Fachabteilung begrenzt. Die dadurch freigewordene Power, kann in weitere Automatisierung oder direkt in die Produktentwicklung fließen, wodurch neue Produkt-Features entstehen.
  • Qualitätssteigerung: Qualitätsmetriken werden regelmäßig und automatisiert gesammelt, protokolliert, bewertet und zur Qualitätssicherung eingesetzt, indem durch Schwellenwerte reale Quality-Gates etabliert werden.
  • Reaktionszeit: Die kontinuierliche Bewertung der Qualität sorgt dafür, dass der Hauptentwicklungszweig unserer Software immer „Ready For Release“ ist. Daher können bei Bedarf erforderliche Releases ad-hoc automatisiert durchgeführt werden, was die Reaktionszeit, insbesondere bei Sicherheitslücken, verbessert.
  • Standardisierung: Jeder kennt die vielen Flussdiagramme, die z.B. mit Visio entstehen und den Entwicklungsprozess dokumentieren. In der Realität hat das Team aber einen Bypass entwickelt, wodurch der Entwicklungsprozess komplett umgangen wird. Ein automatisierter DevOps-Ansatz sorgt dafür, dass die Qualitätssicherungen und Freigabeprozesse nicht nur auf dem Papier standardisiert sind, sondern automatisiert sichergestellt werden. Das hat enorme Vorteile bei jedem Audit.
  • Didaktisch: Eine automatisierte und systemgestützte Qualitätssicherung sammelt viele Metriken und ist bei der Durchsetzung von Schwellenwerten unparteiisch. Sie zeigt gnadenlos Verbesserungspotenziale zur Entwicklungszeit auf und macht das Entwicklungsteam mit Lösungsvorschlägen besser.
  • Agilität: Der hohe Automatisierungsgrad enabled Agilität in der Softwareentwicklung, denn die Qualität wird zur Entwicklungszeit festgestellt und bewertet. Dabei wird Qualität nicht nur durch die funktionalen Anforderungen definiert, sondern auch durch nicht funktionalen Anforderungen. Beides ist automatisiert bewertbar, wodurch z.B. auch die „Definition of Done“ kontinuierlich überprüft und in einem Quality-Gate berücksichtigt werden kann.

Das ist keine bloße Theorie, sondern ist tatsächlich praxiserprobt. Natürlich entstehen initiale Kosten, welche sich aber recht schnell amortisieren. Auch muss DevOps nicht als riesiges Schiff nach dem Motto “ganz oder garnicht” eingeführt werden. Schritt für Schritt werden die wichtigsten Themen angegangen und somit die PS des Unternehmens Schritt für Schritt auf die Straße gebracht. Mit den richtigen Reifen zur bestmöglichen Beschleunigung.

Konkretes DevOps Beispiel

Nehmen wir an, der größte Aufwand einer Freigabe geht auf das Konto “Manuelles Testen” der Fachabteilungen. Vor allem, wenn mehrere Iterationen notwendig sind. In jeder Iteration wird wieder und wieder etwas gefunden und der Prozess geht von vorne los. Stellen wir uns nun diese riesige Fachabteilung vor, welche nun nicht mehr nur manuell testet, sondern einen gewissen Teil ihrer Kapazität in das Automatisieren der Tests steckt. Klar kann dies nicht von heute auf morgen umgesetzt werden, aber wir stellen uns einfach die Entwicklungs- und Qualitätspower vor, die dadurch freigesetzt werden kann. Von Release zu Release werden stückweise die technischen Schulden abgebaut, der manuelle Anteil des Freigabeprozesses wird immer kleiner und der automatisierte immer größer. Die frei gewordene Kapazitäten werden wieder in Automatisierung gesteckt, wodurch DevOps und Automatisierung immer schneller Fahrt aufnimmt. Auf einmal werden Ziele wie z.B. eine ausreichende Code-Coverage tatsächlich erreichbar, was wiederum einen direkten und spürbaren Mehrwert für das Produkt selbst hat.

Ein leider oft unterschätztes Resultat

Nicht nur der Freigabeprozess profitiert von einer automatisierten Qualitätssicherung, sondern auch der Lebenszyklus des Produkts, denn eine automatisierte Qualitätssicherung ist das beste Anti-Ageing für ein Softwareprodukt! Schauen wir uns eine Testsuite mit einer entsprechenden Code-Coverage, stellvertretend als eine von vielen Metriken der Qualitätssicherung, an und beurteilen den Seiteneffekt.

Durch das Automatisieren und Etablieren einer Test-Suite können wir nicht nur unsere funktionalen Anforderungen überprüfen, sondern können mit  Code-Coverage auch die Qualität der Testsuite selbst bewerten. Durch eine hohe Code-Coverage entsteht ein Vertrauen in eine Testsuite, wodurch das Entwicklungsteam mehr Mut zu notwendigen Refactorings entwickelt.

Stellen wir uns eine Entwicklung ohne automatisierte Tests oder mit schlechter Coverage vor. Jedes neue Feature würde minimal-invasiv realisiert werden, da das Team Angst vor dem Impact der Änderung hat. Da die bestehende Software nur manuell und vor allem nicht regelmäßig getestet werden kann, entstehen berechtigterweise Bedenken bezüglich Seiteneffekte.

Als Resultat werden nicht die technisch notwendigen und sinnvolle Änderungen durchgeführt, da diese Änderungen zu invasiv wären. Aus Angst vor Fehlern scheut ein Entwicklungsteam also vor der notwendigen Operation am offenen Herzen zurück. Als Ergebnis bleiben notwendige Refactorings aus, wodurch es zu dem berühmten Spruch mit dem Balkon am Balkon kommt. Wirklich jeder kennt den Spruch. Und ja, wenn wir an einen Balkon immer weitere Balkone entwickeln, erhöhen wir die technischen Schulden und die Software wird nach einigen Jahren unwartbar und stirbt letztlich.

Hätte das Entwicklungsteam nun jedoch eine Test-Suite, die eine möglichst hohe Coverage als Unterstützung produziert, würden sie sich an die notwendigen Herzoperationen trauen. Klar, denn das Risiko ist gering und abschätzbar, da der bestehende Funktionsumfang durch eine Test-Suite automatisiert sichergestellt wird. Durch diesen doppelten Boden erhält das Entwickungsteam Rückenwind und die Selbstsicherheit die notwendigen Refactorings zu machen, wodurch die Wartbarkeit der Software steigt und neue Features leichter integrierbar werden.

Fazit

Mit DevOps drehen wir die Teufelsspirale zu unseren Gunsten auf den Kopf. Der Grad der Automatisierung wird von Release zu Release steigen, die technischen Schulden immer weiter reduziert, die Qualität wird steigen und trotzdem erhalten wir mehr Kapazitäten zur Entwicklung von neuen qualitativ hochwertigen Features.

Kostet also DevOps wirklich nur Geld und bringt uns wirklich keine neuen Features?

Gerne kannst du auf unserer Seite bleiben und mehr über unsere Schulungen, unser Konzept und unser Team erfahren. Wir freuen uns darauf, dich kennenzulernen!