Dies ist der erste Beitrag einer Reihe, die Ihrem Engineering-Team beim Übergang zu einem DevOps-Modell helfen soll. Wir beginnen mit den Warums und gehen in späteren Beiträgen auf die Wies ein. Bleiben Sie dran.

DevOps ist ein Softwareentwicklungsansatz, der sich auf die Zusammenarbeit zwischen Entwicklern und Betrieb konzentriert, wobei Entwickler die Kontrolle über ihren Code von Anfang bis Ende haben und der Betrieb Tools für die Automatisierung entwickelt, die von ihren Entwicklern verwendet werden können. Mit einem DevOps-Modell verfolgen Sie das gemeinsame Ziel, durch häufigere Bereitstellung und Zusammenarbeit schnell qualitativ hochwertige Produkte und Dienste bereitzustellen.

Die meisten von uns haben schon einmal in einem Büro gearbeitet, in dem es so viel Bürokratie gibt, dass es einen Monat dauern kann, nur um einen neuen Hefter zu bekommen oder eine kaputte Tastatur zu ersetzen. Niemand mag diese unnötigen und scheinbar unzähligen Genehmigungsstufen. Vor allem nicht bei kleinen Updates, wie einem Anmeldebutton auf der Homepage oder einer schnellen Fehlerbehebung, um den Frust eines Kunden zu beseitigen.

Als Reaktion auf diese Blockaden gehen wir in unsere Büros, setzen uns an unsere Schreibtische und widmen uns nur einem kleinen Teil des Puzzles. Wir können einfach nichts erledigen, also warum sich die Mühe machen? Aber wir wollen mehr tun. Wir wollen uns wertvoll fühlen und wissen, dass wir mehr beitragen können, um die Dinge besser zu machen. Für Ingenieure können diese Hindernisse Arbeitsabläufe beeinträchtigen, die Kreativität hemmen und ihrem Produkt schaden.

Die Gründung einer DevOps-Kultur in unseren Unternehmen wird uns helfen, viele dieser Hindernisse zu beseitigen. Das DevOps-Modell ist eine Softwareentwicklungsideologie, die Entwickler und Betriebsingenieure dazu ermutigt, zusammenzuarbeiten, um Produkte durch häufigere Bereitstellung und Automatisierung besser und schneller zu machen.

Anstatt in Ihrem Wasserfallmodell zu ertrinken und linear von einem Schritt zum nächsten zu gelangen, hilft die Einführung einer DevOps-Kultur dabei, eine kollaborative Umgebung zu schaffen, in der die Arbeit zwischen Betrieb und Entwicklung verteilt wird. Auf diese Weise können Betriebsingenieure Systeme entwickeln, die es Entwicklern ermöglichen, ihren eigenen Code bereitzustellen und ihren Code häufig bereitzustellen.

DevOps-Teams sind ganzheitlich

In einer richtig aufgebauten Kultur sind die Rollen von Softwareentwicklern und Betriebsingenieuren eng miteinander verknüpft. Anstatt Probleme ohne Rücksicht auf die Menschen auf der anderen Seite über die Mauer zu werfen, arbeiten sie mit ihren Teams zusammen, anstatt gegeneinander zu arbeiten.

Die meisten von uns haben sich auf ihre Kerndisziplinen spezialisiert, doch unser berufliches Umfeld sollte es uns ermöglichen, auch andere Fähigkeiten zu erlernen und anzuwenden, selbst wenn diese nicht in unserem Lebenslauf aufgeführt sind. Mit mehr Flexibilität in unseren Rollen können wir mehr erledigen, weil wir uns dazu stärker befähigt fühlen.

Diese Rollenmischung führt schließlich zu einer organischen Zusammenarbeit und einem sozialen Austausch zwischen den Teams. Dadurch bleibt Ihr Team homogen und die Ziele sind aufeinander abgestimmt. Dies fördert eine Kultur, in der die Kommunikation auf Linienebene zwischen den Teams im Vordergrund steht, sodass Code häufiger und zuverlässiger bereitgestellt werden kann.

Da jeder von Anfang bis Ende die Verantwortung für seine eigene Arbeit übernimmt, sind sie für alle auftretenden Probleme selbst verantwortlich, statt mit dem Finger auf andere zu zeigen. Ein Entwickler, der beispielsweise eine neue Funktion einführt, ist für die Zuverlässigkeit dieser Funktion verantwortlich und schiebt die Verantwortung nicht einfach auf das Betriebsteam.

Haben wir häufigere Bereitstellungen erwähnt?

Lassen Sie uns diesen Punkt etwas genauer betrachten. Schnellere und häufigere Bereitstellungen sind besser für Ihr Unternehmen. In einem DevOps-Organisationsmodell verschieben Sie bei jeder Bereitstellung viel kleinere Blöcke. Das bedeutet, dass das Risiko geringer ist. Die Wahrscheinlichkeit, dass bei diesen kleineren Blöcken etwas schief geht, ist exponentiell geringer als bei der gleichzeitigen Verschiebung mehrerer, größerer Blöcke. Sollte etwas kaputtgehen, müssen Sie nur einen kleinen Teil zurücksetzen, anstatt monatelange Arbeit aufwenden zu müssen, um das Problem zu identifizieren.

Da Sie häufiger bereitstellen können, können Sie Code in kleineren Stücken ausrollen, sodass bei jeder Bereitstellung weniger Risiken bestehen. Wenn etwas schief geht, können Sie einen kleinen Codeabschnitt zurücksetzen, ohne monatelange Arbeit in der Qualitätssicherung auf sich nehmen zu müssen.

Innerhalb eines DevOps-Modells ist jede Änderung an Ihrer Umgebung einfacher zu überwachen, sodass Sie wichtige Kennzahlen messen und Ihr System dann auf der Grundlage der Daten verbessern können. Mit der richtigen Automatisierung, wie z. B. kontinuierliche Integration , Ihre Entwicklungsumgebungen können endlich mit Ihren Produktionsumgebungen mithalten, sodass Sie neuen Code sicher testen können, ohne dass Ihre Kunden Probleme mit Ihrem Service haben. Dadurch wird das Verhalten Ihres Codes für Ihre Kunden deutlich vorhersehbarer. Dadurch können sie problemlos eine neue Funktion Ihres Produkts nutzen.

Definieren Sie Ihre Kultur

Letzten Endes ist Ihre Kultur einzigartig für Ihr Team und Ihr Unternehmen (und das sollte sie auch sein). Wir helfen Ihnen dabei, die Schritte zu identifizieren, die Sie unternehmen müssen, um mit der Schaffung Ihrer eigenen kollaborativen Umgebung zu beginnen, aber das Ergebnis kann niemand von uns vorhersagen.

Lesen Sie weiter, in den nächsten Wochen werden wir tiefer in die Frage eintauchen, wie Sie ein DevOps-Organisationsmodell in die Kultur Ihres Unternehmens einführen können.

Update 10.04.14 – Lesen Sie weiter in der Reihe zum Übergang zu DevOps:

• Der Abbau von Silos geschieht nicht über Nacht
• Skalieren und Eliminieren von Verschwendung in Ihrer DevOps-Umgebung
• Grundlagen für ein erfolgreiches DevOps-Team