Schriftliche DevOps-Schulung

Warum richten Sie kontinuierliche Reviews zur Qualitätssicherung ein?

Ihre Organisationen setzen vor Produktions-Deployments stark auf Reviews, Audits, Inspektionen und Freigaben. Diese Prüfungen führen meist Personen durch, die an der Arbeit nur am Rande oder gar nicht beteiligt sind. Schlimmstenfalls verstehen die Prüf- und Freigabestellen Ihre Arbeit falsch, und Sie müssen sie unmittelbar vor dem Deployment in Produktion erst aufklären.

Probleme mit externen Kontrollmechanismen

In den meisten Organisationen ist es leichter, Kontrollen einzuführen, als gegenseitiges Vertrauen aufzubauen. Mehr Fragen in Änderungsformularen, zusätzliche Freigabeebenen und längere Wartezeiten für Prüfung und Freigabe sind typische Probleme externer Kontrollen.

In einer von Anweisungen und Kontrolle geprägten Kultur mit wenig Vertrauen wiederholen sich viele Vorfälle. Ein Teufelskreis entsteht: Die tatsächliche Arbeit und wiederkehrende Probleme bleiben unsichtbar, und große Arbeitspakete sollen die Zahl aufwendiger Deployments möglichst niedrig halten. Lange Durchlaufzeiten schwächen die Wettbewerbsfähigkeit beim Markteintritt. Langsames, spätes und schwer umsetzbares Feedback hindert Teams daran, aus Fehlern zu lernen.

Eine kompetente DevOps-Organisation weiß, dass die Menschen, die am nächsten an der Arbeit und ihren Problemen sind, sie am besten verstehen. Zusätzliche externe Kontrollen und Freigaben bringen dem Wertstrom daher keinen Mehrwert. Die große Führungsaufgabe unserer Zeit besteht darin, eine Kultur zu schaffen, in der Arbeit sichtbar ist und echter Respekt und gegenseitiges Vertrauen zum Alltag gehören.

Verlagern Sie die Kontrolle von regelmäßigen Inspektionen zu Peer-Reviews im Arbeitsalltag. Lassen Sie Entwicklung, Betrieb, Qualitätssicherung und Informationssicherheit im DevOps-Team kontinuierlich zusammenarbeiten und die Arbeit der jeweils anderen prüfen, damit sichere Deployments möglich sind.

Komplexe Arbeit ohne externe Kontrollen koordinieren

Schon die Arbeit eines einzelnen Teams an einem Projekt ist komplex. Arbeiten mehrere Teams an verschiedenen Komponenten desselben Systems, steigt die Komplexität weiter. Diese Maßnahmen helfen Ihnen und Ihrem DevOps-Team:

• Änderungsgremien, denen neben Führungskräften auch Fachleute angehören, können helfen, Abhängigkeiten zwischen Teams vor Änderungen zu erkennen.
• Lose gekoppelte Architekturen auf Basis von SOA und Microservices verringern Abhängigkeiten und Kommunikationsaufwand.
• Technische Vertreter der DevOps-Teams sollten Abhängigkeiten sowie die Reihenfolge von Entwicklung und Deployment ermitteln.
• Kommunizieren Sie laufend über gemeinsame Chatplattformen, um Änderungen abzustimmen und das Verständnis der anderen nachzuvollziehen und zu überprüfen.
• Folgenschwere und riskante Änderungen wie Migrationen oder Infrastrukturänderungen erfordern Probeläufe in Testumgebungen und technische Vorkehrungen wie Failover und vollständige Rollbacks.

Leistungsstarke DevOps-Organisationen setzen vor allem auf Peer-Reviews

Viele bekannte DevOps-Organisationen wie Amazon, Netflix, Etsy und GitHub nutzen den „Pull Request“-Prozess für Review und Deployment. So funktioniert er:

1. Die Entwicklerin legt vom Trunk aus einen separaten Entwicklungsbranch an. Dieser sollte nur wenige Arbeitstage bestehen und einen eindeutigen Namen wie „login-screen-v2“ haben. Die Entwicklerin arbeitet lokal und checkt den Branch regelmäßig in die Versionsverwaltung ein.
2. Sobald sie ihren Entwicklungsbranch für bereit zur Übernahme in den Trunk hält, öffnet sie einen Pull Request und bittet um Feedback.
3. Nach Rückmeldung und Freigabe durch andere Mitglieder des DevOps-Teams führt sie den Code mit dem Trunk zusammen und stellt ihn anschließend in Produktion bereit.

Bei besonders wichtigen Änderungen wie an Datenbankschemata oder bei möglichen Folgen für die Informationssicherheit kann die Entwicklerin zusätzliche Pull Requests öffnen, um weitere Fachleute wie Datenbankadministratoren oder Sicherheitsfachleute um Rückmeldung zu bitten.

Auch beim Review gilt das Prinzip kleiner Arbeitspakete. Sonst dauert die Prüfung länger und belastet die Prüfenden stärker. Je größer die Änderung, desto stärker steigt ihr Risiko und desto unzuverlässiger wird der Review. Ist eine Änderung zu groß und schwer verständlich, bitten Sie die Entwicklerin, sie in kleinere, verständliche Teile aufzuteilen.

Im DevOps-Team muss jeder seine Änderungen prüfen lassen, unabhängig von seiner Erfahrung oder Position. Alle sollten die Abfolge der Commits beobachten, damit mögliche Konflikte schnell erkannt und gelöst werden, bevor sie die Deployment-Pipeline oder ein Produktions-Deployment beeinträchtigen.

Pair Programming, allein oder mit testgetriebener Entwicklung (TDD), ermöglicht Peer-Reviews bereits beim Programmieren. Bei der Kombination schreibt eine Person den Anwendungscode und die andere die automatisierten Tests. Bei gleicher Teamgröße und denselben Anforderungen wurde gemessen und nachgewiesen, dass Pair Programming 15 % mehr Zeit beansprucht, aber 85 % der Programmierfehler vermeidet. Prüfen Sie daher, ob sich diese Methode für Ihr DevOps-Team eignet.

Erwägen Sie außerdem direkte Reviews am Arbeitsplatz, automatische Benachrichtigungen zu Check-ins und Werkzeuge zur Unterstützung von Code-Reviews und höherer Codequalität.

FAZIT

Geben Sie jedem DevOps-Team Verantwortung für die Qualität seiner Lieferergebnisse. Schaffen Sie eine Kultur, in der kontinuierliche, hochwertige Code-Reviews ebenso viel zählen wie hochwertiger Code.