Ich muss meine Antwort auf diese Frage im Kontext dessen stellen, was DevOps ist, insbesondere innerhalb der DevOps-Transformationen, an denen ich beteiligt war. DevOps ist das Eigentum des gesamten Software Development Lifecycle. Alle Praktiken in der Tabelle sind ein wichtiger Bestandteil von DevOps und ermöglichen und untermauern sowohl das Systemdenken als auch die Verstärkung von Rückkopplungsschleifen .
Das Hauptunterscheidungsmerkmal zwischen CI / CD und DevOps ist jedoch der tatsächliche Betrieb von Software in einer Produktionsumgebung, in der sie ihren Kunden und dem Unternehmen, dem sie dient, einen Mehrwert bieten kann.
Als Berater, der an einer DevOps-Transformation teilnimmt oder diese leitet, habe ich folgende Aspekte im Kopf:
Kultur : Wie Dave zu Recht betonte, ist eine Kultur des kontinuierlichen Experimentierens und Lernens entscheidend für den Erfolg jeder Transformation. Aus DevOps-Sicht kommt es darauf an, wie wir eine Kultur schaffen, die das ausgewählte DevOps-Modell unterstützt. Dieses Modell könnte "Sie erstellen es, Sie führen es aus" oder eher im Sinne der Site Reliability Engineering- Praxis von Google sein .
Betriebsmodell : Dies ist der Teil des Geschäftsvorschlags, in dem dargelegt wird, wie die Organisation Wert liefert, indem im Allgemeinen die verwendeten Personen, Prozesse und Tools auf hoher Ebene miteinander verknüpft werden. Ohne ein Betriebsmodell haben Sie keine Blaupause für die Art und Weise, wie die Organisation die von der Kultur definierten Praktiken anwendet. Dies führt wiederum zu einem Mangel an Klarheit und unterschiedlichen Verhaltensweisen.
C-Level Aircover : Es ist oft unsere Aufgabe als Berater, die im Rahmen von Transformationsprogrammen arbeiten, radikale Änderungen an der Funktionsweise von Unternehmen vorzunehmen. Sie werden die Leute verärgern, und einige Leute werden die Änderungen nicht mögen - es ist wichtig, dass Sie eine "Luftabdeckung" von oben haben, um Dinge zu ändern und vorwärts zu gehen.
Sobald das hohe Niveau erreicht ist, ist es wichtig, etwas zu finden, das Sie realistisch liefern können:
- Fangen Sie so klein wie möglich an, idealerweise, wenn Sie einige Leute haben, die die Kultur verstehen, eine Skizze eines Betriebsmodells und ein Buy-In von den Führungskräften das "Minimum Viable Project" erstellen, versuchen Sie nicht, den Ozean durch die Einführung von DevOps zu kochen vor einem Publikum von Tausenden. Setzen Sie sich ein erreichbares Ziel:
- Automatisieren Sie die Erstellung der Infrastruktur aus Produkt X.
- Automatisieren Sie die Bereitstellung von Product X in Azure in allen Umgebungen.
- Rückgabe der Unterstützung durch Outsourcer Y an ein Entwicklungsteam in London.
- Erstellen Sie eine Reihe von Tests für unsere riskanteste Funktion und führen Sie sie in kontinuierlicher Integration aus.
- Es ist großartig, dass Sie einige Erfolge erzielt haben. Jetzt ist es an der Zeit, dies in mehr Teams zu backen, ein paar weitere Teams in den Mix aufzunehmen und sie zum Laufen zu bringen. Haben Sie keine Angst, zunächst "White Glove Support" anzubieten, um sie beim Übergang zu unterstützen. Sie werden in den kommenden Wochen und Monaten viel Handarbeit benötigen.
- Jetzt haben Sie mehrere Early Adopters, die einer neuen Arbeitsweise folgen. Wenn Sie eine kritische Masse haben, ist es Zeit, Ihre Arbeit mit einem breiteren Publikum zu evangelisieren:
- Halten Sie regelmäßige Show-and-Tell- Sitzungen ab und bitten Sie die Early Adopters, zu demonstrieren, wie erfolgreich sie waren.
- Bieten Sie Drop-In-Sitzungen an, damit andere Teile des Unternehmens untersuchen können, wie sie mit Ihrem Team an Bord kommen können.
- Ermöglichen Sie die Schaffung von Communities of Practice mit Schwerpunkt auf bestimmten Disziplinen: Kontinuierliche Bereitstellung, automatisierte Tests, Geschäftskommunikation, Risikomanagement, Überwachung und Alarmierung usw.
Bleiben Sie auf Kurs und schließen Sie die Transformation ab, indem Sie den Rest der Organisation einbeziehen. Verstehen Sie die Beziehung zwischen dem Gartner-Hype-Zyklus und dem Adoptions-Lebenszyklus . Bereiten Sie sich darauf vor, dass das Transformationsprogramm in den "Trog der Ernüchterung" fällt, bleiben Sie auf Kurs und behalten Sie das Endziel im Blick.
Für eine eingehendere Untersuchung des Endpunkts lesen Sie Geoffrey A. Moores Crossing the Chasm . Ich könnte buchstäblich ein Buch darüber schreiben, wie man eine DevOps-Transformation liefert, aber bis ich sie abgeschlossen habe, würde es wahrscheinlich keine DevOps-Transformationsarbeit mehr für mich geben.
