Zahlt sich ein Investment in DevOps aus?

Ueli Scheidegger
Nov 5, 2019 · 6 min read

fastforward hat gross ins Setup einer top DevOps Infrastruktur investiert. Unsere Software wird jetzt durch einen gut strukturierten und hoch automatisierten Prozess kompiliert, getestet und installiert. Dies hat uns eine Stange Geld gekostet. Wieso haben wir uns also dazu entschieden?

Was ist “DevOps”?

Da Testing viel Aufwand bedeutet, werden typischerweise die Anzahl der Installationen verringert, was weniger Flexibilität und längere Wartefristen für neue Funktionen oder Verbesserungen bedeutet. Und darüber freut sich natürlich die Konkurrenz!

Hier kommt DevOps ins Spiel. Es ist eine Kombination von Entwicklung (im Englischen: Development) und Betrieb (im Englischen: Operations) und beinhaltet alle Methoden und Tools, die dabei helfen, Software schnell und ohne grossen Aufwand zu implementieren, zu testen und zu installieren.

Die fastforward DevOps-Prozesse

Versionsverwaltung…

…Automatisches Kompilieren…

…Testing…

Wir führen drei Arten von Tests durch:

  1. Unit Tests überprüfen die Funktion von kleinen Einheiten (im Englischen: Units) der Software. Diese Tests sind klein, schnell und überprüfen eine einzige granular Funktion.
  2. Integrationstests überprüfen die Zusammenarbeit von verschiedenen Teilen der Software und können sogar beurteilen, ob unsere Software weiterhin mit anderer Software, z.B. über ein Netzwerk, zusammen funktioniert. Diese Tests dauern typischerweise länger zum Durchführen und benötigen meist auch eine Umgebung in einem bestimmten Zustand (z.B. die Verfügbarkeit einer Datenbank oder eines Netzwerks). Aber sie sind wertvoll, denn sie zeigen uns z.B. auch, ob die Drittsysteme noch im vereinbarten Zustand sind, oder ob sie allenfalls geändert wurden, ohne dass wir davon Kenntnis hatten.
  3. End-to-end Tests testen schliesslich die Benutzeroberfläche. In unserem Fall geschieht dies durch ein Skript, welches einen Web Browser kontrolliert, eine URL öffnet, einen Link klickt, Daten in ein Formular eingibt, etc. End-to-end Tests sind normalerweise ziemlich langsam, weshalb wir sie nicht bei jeder kleinen Code-Änderung ausführen. Aber wenn eine Entwicklerin fertig ist mit einer Neuerung, macht es Sinn, dass sie die End-to-end Tests ausführt, bevor sie ihren Code zum bestehenden Code hinzufügt. Ebenso sollten die End-to-end Tests ausgeführt werden, wenn wir eine neue Version zum Installieren freigeben.
Beispiel eines automatisierten Frontend-Test

…und Installation

In den meisten DevOps-Ansätzen findet man verschiedene Umgebungen, z.B. “DEV” als Spielplatz für die Entwickler (im Englischen: Developers); die “TEST”-Umgebung, um eine Funktion zu testen; die “INT”-Umgebung (von Integration), die wie die “PROD”-Umgebung aufgesetzt sein sollte, um möglichst aussagekräftige Testresultate zu liefern, sowie oftmals auch für Last-Tests verwendet wird. Und schliesslich die “PROD”-Umgebung (von Produktion), wo sich echten Nutzerinnen des Systems befinden. Aber was machen wir, wenn Entwicklerin A ihre neue Funktion testen möchte, aber DEV ist von Entwickler B besetzt, der noch Code von Entwicklerin C überprüft?

Natürlich könnte man noch ein paar Umgebungen mehr aufsetzen und hoffen, dass jeweils genügend vorhanden sind. Bei fastforward haben wir uns für “ad hoc”-Umgebungen entschieden, um dieses Problem zu lösen: Nachdem eine Code-Änderung erfolgreich durch den automatischen Kompilations- und Test-Prozess gelaufen ist, wird er auf einer eigens dafür erstellten Umgebung installiert — natürlich wiederum automatisch. Diese Installation kann jetzt für Überprüfung der Funktion durch einen Kollegen, eine Testerin und/oder den Kunden selbst benutzt werden und — klar!— wird danach automatisch wieder abgebaut. Dies gibt uns viel Flexibilität, um Code zu schreiben, testen und mit Kundinnen und Benutzern zu besprechen.

Und wieviel kostete das alles?

Und was bringt uns das Ganze?

Automatische Tests nehmen uns viel Stress ab. Mit guten Test-Szenarien wissen wir, dass unsere Änderung keine anderen Funktionen kaputt macht. Und wenn eine Änderung doch mal Probleme verursachen sollte, sagen uns die Tests sofort, dass und wo etwas schief geht. Das minimiert nicht nur die Zeit, die wir vorher für manuelles Testing aufwenden mussten, sondern gibt uns auch die Freiheit, eine neue Version zu installieren, wann immer wir wollen.

Automate Builds geben uns sofortige Rückmeldungen zu unserem Code. Vielleicht hat der Entwickler eine Library auf seinem Computer, aber er hat vergessen, sie beim Build Skript hinzuzufügen. Dank dem automatischen Build System weiss unser Team das sofort. So müssen andere Entwickler nicht viel Zeit verschwenden, wenn sie neue Arbeit in einem kaputten System beginnen wollen.

Screenshot of the build, test, staging, e2e-test, and deployment pipeline of one of our projects.
Der Build-, Test-, Staging-, End-2-End-Test- und Installations-Prozess von einem unserer Projekte.

Fazit

Vergleicht man also die Kosten von DevOps mit den Alternativkosten, die anfallen, wenn man keine solche Infrastruktur hat, so ist schnell klar, welchen Wert gutes DevOps hat. Unsere Kunden profitieren auf jeden Fall sehr von unserer teuren Investition, denn sie erhalten alle Vorteile zu einem Bruchteil des Preises, da wir die Kosten zwischen unseren Kundinnen aufteilen können. Und darüber hinaus können unsere Mitarbeiter erst noch besser schlafen, da es weniger böse Überraschungen gibt. Ich würde das als eine Win-win-Situation bezeichnen.