DevOps
Eine Kultur und ein Satz von Automatisierungspraktiken, die Entwicklung und Betrieb verschmelzen, sodass dasselbe Team die Software baut, ausliefert und betreibt, mit schnellem Feedback aus der Produktion zurück zum Code.
DevOps begann als Reaktion auf eine bestimmte Dysfunktion: Entwickler warfen Code über eine Mauer zu einem separaten Operations-Team, Ops bekam die Schuld, wenn etwas kaputtging, und die Feedbackschleife zwischen Schreiben und Betreiben von Software war zerbrochen. DevOps schließt diese Schleife. Das Team, das die Software baut, liefert sie auch aus und betreibt sie, und der Schmerz des Betriebs fließt direkt zurück zu den Leuten, die ihn beheben können.
In der Praxis wird diese Kultur durch Automatisierung ermöglicht: CI/CD, damit Änderungen sicher und oft in die Produktion fließen, Infrastructure as Code, damit Umgebungen reproduzierbar sind statt handgebaute Unikate, und Observability (Logs, Metriken, Traces, Alerts), damit das Team sieht, was die Produktion tatsächlich tut. Keines dieser Werkzeuge ist für sich genommen DevOps. Sie sind das, was die Kultur überlebensfähig macht.
Der Jobtitel “DevOps Engineer” ist meist eine Fehlbezeichnung, und eine aufschlussreiche. DevOps ist keine Rolle, die man zwischen Dev und Ops setzt, das baut nur die Mauer mit neuem Namen wieder auf. Was die meisten “DevOps Engineer”-Stellen eigentlich wollen, ist ein Plattform- oder Infrastruktur-Engineer, der die Automatisierung baut, die andere Entwickler nutzen. Nützliche Person, falsches Etikett. Wenn eure Organisation ein DevOps-Team hat, das Deploys übernimmt, damit Entwickler es nicht müssen, habt ihr Ops mit einem Rebranding, kein DevOps.
Wavects Sicht: DevOps ist eine Arbeitsweise, keine Abteilung. Wir bauen die Automatisierung, die ein kleines Team befähigt, seine Software durchgängig zu verantworten, und behandeln “you build it, you run it” als Standard. Seht euch unsere Full-Stack-Entwicklungsarbeit an, wie das in der Praxis aussieht.