,
4 Min. Lesezeit
Wissen ist wertvoll, aber seine wahre Kraft entfaltet es erst, wenn wir es in die Tat umsetzen. Bei Freyr Digital waren wir mit DevOps, den damit verbundenen Praktiken und der Art und Weise vertraut, wie es unser Unternehmen in ein leistungsstarkes Produktentwicklungszentrum verwandeln könnte, das in der Lage ist, qualitativ hochwertige Produkte und Lösungen für unsere Kunden in den Biowissenschaften zu liefern. Als wir unsere Reise begannen, legten unsere Bemühungen ein starkes Fundament, aber um wirklich ein Entwicklungszentrum zu werden, wussten wir, dass wir einen strategischeren und adaptiveren Ansatz verfolgen mussten.
Die größte Herausforderung bei der Umsetzung von Wissen in die Praxis besteht darin, zu wissen, wann die richtigen Schritte zu unternehmen sind. Da Maßnahmen viele Menschen in einer Organisation betreffen, hängt es davon ab, wo wir als Organisation stehen, welche Prozesse und Praktiken wir derzeit anwenden und welche Fähigkeiten und Kompetenzen unsere Mitarbeiter besitzen, das Richtige zur richtigen Zeit zu tun.
Dies markierte einen Wendepunkt in unserer Transformation. Als Portfolio von Softwareanbietern, die sich auf maßgeschneiderte Lösungen spezialisiert haben, verfügten wir über ein engagiertes Team, das stets sein Bestes gab, um Ergebnisse zu liefern. Wir sahen jedoch eine Gelegenheit, die Qualität zu verbessern, die Produktivität zu steigern und die Umwandlung von Geschäftsanforderungen in Ergebnisse zu beschleunigen. Anstatt uns auf Last-Minute-Korrekturen zu konzentrieren, wollten wir von der reaktiven Problemlösung zu proaktiver Innovation übergehen und skalierbare, wirkungsvolle Lösungen entwickeln.
Wir hatten eine Vision davon, wo wir sein wollten – wie wir Software entwickeln, testen, bereitstellen und veröffentlichen wollten. Wir wussten jedoch, dass das Erreichen dieser Ziele eine durchdachte Strategie, kontinuierliches Lernen und ein Engagement für Verbesserungen erforderte.
Spulen wir vor bis heute: Im letzten Jahr haben wir über 100 Releases mit nahezu null Bereitstellungsfehlern durchgeführt und eine fast vollständige Automatisierung bei der Einführung von Änderungen erreicht. Darüber hinaus haben wir erhebliche Fortschritte bei den Einnahmen, schlankere und agilere Teams sowie eine allgemeine Verlagerung hin zu unserer Vision, ein führendes Unternehmen für Softwareprodukte, -lösungen und -dienstleistungen zu werden, festgestellt. Obwohl es immer noch mehr zu erreichen gibt, sind wir zuversichtlich, dass wir ein starkes Fundament gelegt haben und bereit sind, zu beschleunigen.
Auf unserem weiteren Weg nehmen wir uns einen Moment Zeit, um über unsere Transformation nachzudenken – was funktioniert hat, was nicht und welche Lehren wir daraus gezogen haben. Indem wir unsere Reise teilen, hoffen wir, andere zu unterstützen, die ähnliche Veränderungen durchlaufen.
Diese Blogreihe ist hauptsächlich empirisch und teilt, was wir getan haben, während sie unsere Handlungen auch mit Best Practices und Empfehlungen aus verschiedenen DevOps- und Agile-Ressourcen verbindet.
Das Richtige zur richtigen Zeit tun
Einer der Schlüsselaspekte unserer Transformation war die Identifizierung der richtigen Maßnahmen zur richtigen Zeit. Angesichts mehrerer möglicher Initiativen benötigten wir einen strukturierten Ansatz, um einen sinnvollen Fortschritt zu gewährleisten.
Rückblickend lassen sich diese Maßnahmen in drei Kategorien einteilen: Tools und Prozesse, Softwarearchitektur und Menschen. Diese Kategorien sind stark miteinander verknüpft, wobei Änderungen in einer Kategorie die anderen beeinflussen. Es war jedoch möglich, inkrementell Änderungen in jeder Kategorie vorzunehmen und den Fortschritt in Richtung unserer Gesamtziele zu messen.
Die Initiativen in diesen Kategorien waren oft voneinander abhängig. Änderungen in einem Bereich eröffneten Möglichkeiten für weitere Verbesserungen in einem anderen.
Die ersten Schritte
Um ein starkes Fundament zu legen, konzentrierten wir uns auf drei Kerninitiativen:
- Integration unserer Quellcode-Basen mit SonarQube für Code-Qualitätsmetriken.
- Umstellung aller Teams auf ein gemeinsames Tool zur Verwaltung von Anforderungen, Quellcode und Testplänen – in unserem Fall Azure DevOps.
- Teams mit klaren Verantwortlichkeiten strukturieren, um Eigenverantwortung und Rechenschaftspflicht zu stärken.
Diese drei Initiativen verschafften uns Einblicke in:
- Die geleistete Arbeit (Anforderungen und Aufgaben).
- Die Codequalität (SonarQube-Metriken).
- Die beteiligten Personen (Teamverantwortlichkeiten).
Davon war die Definition klarer Teamverantwortlichkeiten die größte Herausforderung. Anfangs waren die Teamstrukturen flexibel, und Mitarbeiter wechselten je nach Bedarf zwischen Projekten. Der Übergang zu dedizierten Teams mit klaren Funktionsbereichen war ein notwendiger Schritt, wurde jedoch durch unsere bestehende Produktarchitektur erschwert, die nicht vollständig darauf ausgelegt war, klare Verantwortlichkeiten zu unterstützen.
Die Rolle der Softwarearchitektur
Wir erkannten schnell, dass die Produktarchitektur einer der kritischsten Bereiche für Veränderungen war. Eine modulare Architektur war unerlässlich, um unabhängigen Teams die Übernahme von Verantwortung für ihre Arbeit zu ermöglichen. Ohne diese waren unsere Bemühungen, Teamverantwortung zu schaffen, in ihrer Wirkung begrenzt.
Die Neugestaltung unseres Portfolios war ein komplexer Prozess. Dazu gehörte die vollständige Umstellung auf die Cloud und der Beginn des Aufbaus Cloud-nativer Anwendungen mithilfe einer Microservices-Architektur. Dieses Thema wird in einem zukünftigen Beitrag behandelt. Die wichtigste Erkenntnis ist jedoch, dass Veränderungen schrittweise erfolgen und einige Schritte anderen vorausgehen müssen, um Vorteile und weitere Fortschritte zu ermöglichen.
Metriken und kontinuierliche Verbesserung
Nachdem wir mit der Arbeit an der Re-Architektur (einem fortlaufenden Projekt) begonnen hatten, verlagerten wir unseren Fokus auf das Monitoring von Metriken und das Festlegen von Zielen:
- Codequalitätsmetriken in SonarQube.
- Code-Integrationsmetriken in Azure DevOps.
- Metriken zum Feature-Durchsatz für einzelne Teams.
- Einführung Cloud-nativer Dienste.
Diese Ziele waren keine strikten Vorgaben, sondern leitende Vorgaben, um Teams bei der Ausrichtung ihrer Bemühungen zu unterstützen.
Mitarbeiter stärken
Mit den vorhandenen Metriken wurde deutlich, dass Teams Unterstützung benötigten, um diese Ziele zu erreichen. Zum Beispiel war das Festlegen von Zielen für die Unit-Test-Abdeckung und die API-Testautomatisierung zwar unkompliziert, deren Erreichung jedoch eine Herausforderung, insbesondere bei Legacy-Code, der nicht auf Testbarkeit ausgelegt war.
Um dies zu beheben, haben wir:
- Niedrigere Ziele für Legacy-Code festgelegt.
- Workshops und praktische Schulungen zum Schreiben hochwertiger Unit-Tests und zum Entwerfen von testbarem Code organisiert.
- Anleitungen zum Erstellen von Stubs für API-Tests bereitgestellt.
- Überprüfungen von Unit-Tests durch leitende Architekten durchgeführt.
Das Dreieck aus Tools, Architektur und Menschen
Ein gutes Beispiel für das Zusammenspiel dieser Kategorien war das Code- und Repository-Management. Die Integration mit SonarQube, eine Verbesserung der Tools, zeigte eine geringe Unit-Test-Abdeckung auf, was auf architektonische Probleme hinwies, die die Testbarkeit einschränkten. Verbesserungen in der Architektur und den Teamfähigkeiten führten zu qualitativ besseren Unit-Tests, diese wurden jedoch aufgrund schlechter Branching-Praktiken nicht regelmäßig ausgeführt. Wir haben dies behoben, indem wir Branching-Strategien standardisiert und die regelmäßige Integration von Code in den Haupt-Branch sichergestellt haben, wodurch CI-Pipelines alle Tests ausführen konnten.
Die richtige Reihenfolge der Veränderungen
Ein Ansatz zur Transformation besteht darin, beste Praktiken wahllos umzusetzen. Obwohl dies Vorteile bringen kann, rechtfertigen die Ergebnisse oft nicht den Aufwand, was zu Frustration führt.
Wir verfolgten einen anderen Ansatz, basierend auf dem Flussprinzip: den End-to-End-Prozess analysieren, Engpässe identifizieren und diese schrittweise angehen.
Jede Verbesserung zeigte neue Engpässe auf, die weitere Maßnahmen erforderten. Dies war kein Spiel nach dem Prinzip „Hau den Lukas“, sondern ein bewusster Prozess, das Richtige zur richtigen Zeit zu tun.
Zum Beispiel hätte die Vorschrift einer Unit-Test-Abdeckung ohne Verbesserung des Code-Designs zu Frustration und „Coverage Theater“ (oberflächlichen Tests, die nur zur Erfüllung von Metriken geschrieben wurden) geführt. Indem wir uns zuerst mit Architektur und Fähigkeiten befassten, stellten wir einen sinnvollen Fortschritt sicher.
Ausblick
Wahre Transformation ist kein einzelner großer Umbruch, sondern intelligente, gut getimte Entscheidungen, die kontinuierlichen Fortschritt vorantreiben. Wir freuen uns, unsere Erfahrungen und Erkenntnisse zu teilen, um anderen zu helfen, ihren eigenen Weg zu skalierbaren, wirkungsvollen Veränderungen zu finden.
In den kommenden Blogs dieser Reihe – DevOps für den Erfolg – werden wir jede Phase unserer Transformation im DevOps-Dreieck – Tools, Architektur und Menschen – aufschlüsseln, die uns geholfen hat, nachhaltige Wirkung zu erzielen.
