Konfiguration, Bereitstellung, Organisation 5 häufige DevOps-Fehler und wie man sie vermeidet

Continuous Integration und Continuous Deployment helfen dabei, die Softwareentwicklung effizienter zu gestalten. Im Zuge von DevOps-Strategien werden die beiden Prinzipien kombiniert. Fünf gängige Fehler lassen sich dabei von Vornherein vermeiden.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Confluent Germany GmbH

Während die kontinuierliche Integration auf Automatisierung, Build-Erstellung und schnellen Änderungen basiert, geht es bei Continuous Deployment um die Weiterentwicklung des Codes in der Pipeline. DevOps kombiniert diese beiden Prinzipien und zielt darauf ab, nicht nur den Entwicklungsprozess, sondern auch die Unternehmenskultur zu transformieren, um die Zusammenarbeit zwischen den Abteilungen zu fördern.

Natürlich möchte jedes Unternehmen in allen seinen Projekten erfolgreich sein und seine Entwicklungsziele auf ganzer Linie erreichen. Doch dies ist kein leichtes Unterfangen. Schließlich sind ausreichend Zeit und die Zusammenarbeit unterschiedlicher Teams im Unternehmen Grundvoraussetzungen für den Geschäftserfolg, jedoch nicht immer vorhanden.

Die Aufgabe von DevOps ist es nun, auch Raum für Misserfolge in den Projekten zu lassen und dadurch sicherzustellen, dass auf Fehler schnell reagiert und aus ihnen gelernt wird. Die gesammelten Informationen aus solchen Situationen können anschließend genutzt werden, um Prozesse in Zukunft vorab zu verbessern.

Doch sollte es nicht Ziel der DevOps-Philosophie sein, dass Teams immer erst selbst auf die gleichen häufigen Fehler stoßen müssen, um aus ihnen zu lernen. Einige Fehler lassen sich durchaus zu Beginn vermeiden. Hier sind häufige DevOps-Fehler und Tipps, wie man aus ihnen lernen kann:

1) Unbeabsichtigtes Aussperren

Es ist für Entwickler recht einfach, versehentlich ihren eigenen Zugriff zu blockieren, sobald sie Implementierungen nach dem Modell „Configuration as Code“ automatisieren. Wenn sie eine fehlerhafte Änderung übertragen, die auf allen Maschinen eingesetzt wird, zwingt dieses Problem sie anschließend dazu, sich manuell mit jeder Maschine zu verbinden, um den Fehler zu beheben.

Wie man das Problem vermeidet: Entwickler müssen angemessene Schutz- und Validierungsmaßnahmen für die Konfigurationen einrichten und sicherstellen, dass alle Änderungen bereits in der frühen Entwicklungsphase regelmäßig getestet werden. Durch die Implementierung eines formalen Prozesses für Modifikationen an der Infrastruktur und im Anwendungscode reduzieren Unternehmen das Risiko von Auswirkungen auf andere Umgebungen. Dadurch sparen Entwickler wiederum Zeit und verbessern die Projektqualität.

2) Vorzeitige Bereitstellung

Häufig führen Entwickler eine kontinuierliche Integration während des laufenden Einsatzes durch, um automatisierte Test- und Feedback-Zyklen zu beschleunigen. Wenn auf diese Weise vorgegangen wird, kann es passieren, dass die Bereitstellung des neuen Codes parallel zum Testen desselben erfolgt. Wenn der Code unsachgemäß konfiguriert wird und die Änderungen vor dem Testen auf dem Endprodukt angewendet werden führt dies dazu, dass die Vorteile der automatisierten Tests vor dem Einsatz verloren gehen.

Wie man das Problem vermeidet: Es ist wichtig, Validierungen und Kontrollen einzuführen, bevor neuer Code für den Endbenutzer zugänglich ist. So können Entwickler beispielsweise ihre Continuous-Deployment-Pipelines so anlegen, dass parallele Tests als Validierungsschritt vor der Übertragung an die Produktionsumgebung verwaltet werden. Dadurch wird sichergestellt, dass nicht-getestete und nicht-validierte Änderungen nicht automatisch bereitgestellt werden.

Die DevOps-Prinzipien setzen voraus, dass Teams jederzeit einsatzbereit sein müssen. Jedoch sollte die Bereitstellung immer am Ende der Pipeline erfolgen – nachdem alle Tests, Validierungsprüfungen und Genehmigungen abgeschlossen sind und bevor sie den Anwender erreicht.

3) Konflikte im Software-Konfigurationsmanagement

Software Configuration Management (SCM) ist eine der größten Herausforderungen, vor denen ein DevOps-Team steht. Es ist nicht ungewöhnlich, dass IT-Architekten zu Beginn ihrer Karriere Zugang zu Git-Repositorien (Versionskontroll- und Quellcode-Managementsysteme) gewährt wird, was wegen mangelnder Praxiserfahrung zwangsläufig zu Problemen führt.

Versuchen Teams, den Grundprinzipien von Git zu folgen, werden sie daher wahrscheinlich einerseits auf Merge-Konflikte stoßen, die zu Problemen in der Anwendung führen, und andererseits auf verlorene HEAD-Referenzen (wenn ein bestimmter Commit statt eines Branches gewechselt wird). Dieses Problem zu beheben ist nicht nur schwierig, es gehen auch alle in diesem Modus vorgenommenen Änderungen verloren.

Wie man das Problem vermeidet: Es ist empfehlenswert, ein Merge und Branch-Modell einzurichten. Dadurch wird sichergestellt, dass die richtigen Informationen in die DevOps-Pipeline integriert werden und somit eine kontinuierliche Integration von Tests und Deployment-Änderungen möglich ist.

4) Unzureichend definierte Ziele

Obwohl Entwickler gemeinsam am Code in der Pipeline arbeiten, definieren manchmal verschiedene Teams ihre eigenen Leistungskennzahlen (auch Key Performance Indicators, KPIs). So kann beispielsweise ein Team von Qualitätsbeauftragten die Anzahl der pro Sprint durchgeführten Tests als Erfolgsmaßstab verwenden.

Da die Mitarbeiter jedoch fast immer Performance-orientiert bewertet werden, können sie dazu neigen, immer mehr Tests hinzuzufügen – ohne zu berücksichtigen, dass mehr Test auch mehr Zeit brauchen. Dies könnte sich wiederum auf andere Teams auswirken und die Dauer des Testzyklus sowie die Zeit bis zum Produktivstart verlängern. Anstelle von mehr Tests sollten vorhandene Tests optimiert werden, um effizienter zu testen.

Wie man das Problem vermeidet: Obwohl dieser Aspekt nicht oft angesprochen wird, ist es wichtig, das „Warum“ von DevOps zu verstehen. Unternehmen müssen für jede Initiative Ziele und Vorgaben definieren und sicherstellen, dass alle Teams sich auf ihre Einhaltung verpflichten.

Nach der Definition der Ziele können die KPIs und Erfolgsmessungen auf die Ziele abgestimmt werden. Unternehmen müssen eine Reihe gemeinsamer Ziele, Erfolgsmaßnahmen und Leistungsindikatoren entwickeln, um eine klare Priorisierung bei der Erstellung von Pipelines zu ermöglichen.

5) Falsche Identifizierung von organisatorischen Barrieren

Oft ist es die Unternehmenskultur selbst, die zur Herausforderung für Unternehmen wird. Ohne die vollständige Integration der Teams riskieren Unternehmen, dass neue Silos geschaffen und Tätigkeiten zersplittert werden. Für die interne Entwicklung ist dies überaus problematisch, da Abteilungen sich oft gegenseitig die Schuld an Fehlern oder Problemen zuschieben, anstatt das Unternehmen und damit die Problemlösung als Ganzes zu betrachten.

Wie man das Problem vermeidet: Der beste Weg, Teams zu organisieren, ist die Aufgliederung nach Themen wie etwa Produkte oder Funktionen. Darüber hinaus müssen zu Beginn eines Entwicklungsprozesses alle Beteiligten einbezogen werden, damit die Rollen der verschiedenen Teams von Anfang an klar definiert sind.

Ziel ist es, dass alle Stakeholder und Entwicklungsteams am gleichen Strang ziehen, um DevOps für das Unternehmen wirklich möglich zu machen. Auch wenn der Weg dorthin kein leichter ist: Die DevOps-Kultur ist für die Softwareentwicklung genauso wichtig wie die dabei verwendeten Technologien und Werkzeuge.

Es exisistiert kein Königsweg

Bei all diesen Überlegungen über die häufigsten DevOps-Fehler darf jedoch nicht vergessen werden: Jedes Unternehmen ist anders – und damit variieren auch die Fehler, die es bei der Implementierung von DevOps macht. Es gibt keinen allgemeingültigen Weg, eine erfolgreiche DevOps-Transformation durchzuführen oder sie schnell umzusetzen.

Brian Dawson

DevOps wird Unternehmen immer mit Herausforderungen konfrontieren. Daher hängt der Erfolg stets von der Lern- und Anpassungsfähigkeit des Unternehmens ab. Nur durch die Entwicklung dieser beiden Eigenschaften werden Unternehmen in der Lage sein, ihre eigene DevOps-Kultur erfolgreich (weiter) zu entwickeln.

* Brian Dawson ist ein Experte für DevOps bei CloudBees.

(ID:45767534)