Teil 3: Software Configuration Management als eine der größten DevOps-Hürden überwinden

DevOoops – Von Pre-Git zu Git

Brian Dawson

© Shutterstock / studiostoks

„DevOoops“ ist die ironische Bezeichnung von Fehlern, die bei der Umsetzung von DevOps-Initiativen entstehen können. Dabei ist das oberste Ziel solcher Initiativen die Effizienzsteigerung im Softwarebereitstellungsprozess. Doch nicht immer führen diese zur angestrebten reibungslosen Verknüpfung agiler Software-Entwicklung (Development) mit einem steten, stabilen und sicheren IT-Betrieb (Operations). Die dreiteilige Fachartikelserie DevOoops beleuchtet die Hintergründe je eines „DevOoops“ anhand konkreter Szenarien und gibt dazu passend konkrete Handlungs- und Lösungsempfehlungen. Im dritten und letzten Teil geht es um das Software Configuration Management und dessen Wichtigkeit für den Erfolg von DevOps.

Eine der größten Herausforderungen bei DevOps ist das SCM (Software Configuration Management). SCM ist ein wichtiger Grundbaustein, um eine gemeinsame Sicht auf kritische Assets der Software-Entwicklung – vom Beginn selbiger bis zum produktiven Einsatz – zu ermöglichen. Die angemessene Berücksichtigung der SCM-Struktur, ihres Branching- und Merging-Modells und der Zugriffskontrollen unterstützt die Zusammenarbeit, die Kommunikation und somit letztlich den Erfolg von DevOps.

Im DevOps and Jenkins Community Report 2019 gaben 66 Prozent der befragten Unternehmen an, moderne Lösungs-SCMs einzusetzen, insbesondere Git-basierte Lösungen wie GitHub oder BitBucket. Aber auch die älteren SCM-Lösungen verschwinden noch nicht ganz: 45 Prozent aller Unternehmen nutzen nach wie vor Pre-Git, Pre-DVCS (Distributed Version Control Systems) wie Perforce, Subversion und CVS. Obwohl es möglich ist, DevOps-Praktiken mit diesen Legacy-Lösungen anzuwenden, ist es wichtig (und anspruchsvoller), ein Branching-/Merging-Modell und einen zugehörigen Workflow zu entwerfen, der die wichtigsten Aspekte von DevOps wie Peer Review, Collaboration und kurzlebige Branches unterstützt.

Moderne Lösungen wie GitHub sind so konzipiert, dass sie von vornherein auf Zusammenarbeit ausgelegt sind – einschließlich des revolutionären Pull Request, der es wesentlich einfacher macht, Prozesse zu implementieren, die Continuous Delivery (CD) und DevOps optimal unterstützen.

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? As a follow-up to our previous cheat sheet featuring the most important commands and functions, DevOpsCon speaker Michael Hofmann has put together the 8 best practices you should keep in mind when using Istio.

Allerdings erzeugen wenig durchdachte CD-Workflows oder unzureichende CD-Systeme eine Vielzahl von Konflikten – und das auf unterschiedliche Art und Weise. Wenn beispielsweise die Interaktionen zu komplex sind, wird der Code von den Entwicklern zu selten in die Pipeline übertragen. Ist es jedoch schwierig, auf die Pipeline zuzugreifen und Transparenz über den Prozess zu erhalten, kann dies zu ungelösten Konflikten führen. Dies führt zwangsläufig zu unerwarteten Qualitätsproblemen.

Entsprechend wichtig ist die Herausforderung, das richtige, passende Werkzeug auswählen. Und falls ein Team nicht die Möglichkeit hat, ein modernes Tool zu nutzen, ist es notwendig, ein existierendes Werkzeug genau für diesen Zweck zu optimieren. Darüber hinaus darf nicht vergessen werden, zwei weitere Aspekte im Zusammenhang mit diesem DevOoops-Beispiel zu betrachten:

  •         Branching: Ein passendes Branching- und Merging-Modell ist erforderlich, um sicherzustellen, so dass die entsprechenden Eingaben in die DevOps-Pipeline sinnvoll erfolgen. Nur dann sind die Teams in der Lage, Änderungen kontinuierlich zu integrieren, zu testen und schließlich bereitzustellen. Optimalerweise folgen die Unternehmen dem aus dem Englischen bekannten KISS-Prinzip (keep it simple, stupid). Denn kommt ein komplettes Whiteboard oder eine Tabellenkalkulation zum Einsatz, die für einen Buchhalter geeignet wäre, nur um alle aktiven Branches aufzulisten, dann ist das sicherlich nicht der passende Weg. Zu empfehlen ist hier, dem Ideal der Mainline-Trunk-Entwicklung so nahe wie möglich kommen: mit kurzlebigen Feature Branches, minimalen Applikationsversionen, etc.
  •         Know-how: Wenn Unternehmen versuchen, DevOps zu implementieren, werden höchstwahrscheinlich gleichzeitig neue Tools und Praktiken implementiert. Wie bei jeder Einführung mit neuen Prozessen und Tools, ist davon auszugehen, dass dies nicht ganz reibungslos von statten gehen wird. So ist beispielsweise der Wechsel von einer zentralen Versionskontrolle wie Apache Subversion (SVN) zu einer verteilten Versionskontrolle wie GIT ein Paradigmenwechsel. Diesen komplett zu verstehen, ist nicht immer einfach und kann zu destruktiven Fehlern wie dem Löschen von Knoten aus der Änderungshistorie, dem Überschreiben von Änderungen oder der Fehlkonfiguration der Zugriffskontrolle führen. Unternehmen, die eine solche Umstellung planen, sollten darüber nachdenken, ob es nicht sinnvoll wäre, entsprechende Experten einzustellen und außerdem Zeit zur Weiterbildung der Mitarbeiter einzurechnen.

Das Wichtigste nochmal zum Schluss:

  •         Ein geeignetes Branching- und Merging-Modell ist erforderlich, um sicherzustellen, dass die Teams die entsprechenden Informationen in die DevOps-Pipeline eingeben, damit Änderungen kontinuierlich integriert, getestet und schließlich bereitgestellt werden können.
  •         Nutzt das Unternehmen eine ältere Pre-GIT-SCM-Lösung, muss für diese Legacy-Lösung eine passende Branching- und Merging-Strategie entwickelt werden, um die Geschwindigkeitsvorteile, die das DevOps-Modell heutzutage bietet, überhaupt zu erreichen.
  •         SCM-Tools sind nur dann erfolgreich, wenn sie richtig zum Einsatz kommen. Der Erwerb neuer Fähigkeiten und eine Einarbeitungsphase müssen fest in das Projekt eingeplant werden.
Geschrieben von
Brian Dawson
Brian Dawson
Brian Dawson ist DevOps-Evangelist bei CloudBees.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: