Table of Content
Eine Continuous Delivery Pipeline umfasst Continuous Integration, Delivery und Deployment und wird oft als CI/CD-Pipeline bezeichnet. Die CI/CD-Pipeline ist ein Teilbereich einer größeren Toolkette, welche automatisiertes Testen und Versionsverwaltung beinhaltet. Aus diesem Grund wird eine Continuous Delivery Pipeline häufig verwendet, um das gesamte System zu beschreiben.
Continuous Delivery Pipelines bewegen den Anwendungscode von seiner Quelle (Entwickler) und stellen ihn den Endanwendern als Anwendung oder Online-Service zur Verfügung. Der Aufbau und das Management einer Contiuous Delivery Pipeline kann jedoch nicht erfolgreich sein, wenn man nicht genau versteht, wie man die damit verbundenen Risiken bewältigen kann. Doch was genau verbirgt sich hinter „Risiken“? Hier werden wir fünf wesentliche Risikobereiche innerhalb eines Continuous-Delivery-Prozesses sowie deren Ursachen, Folgen und Lösungen betrachten.
Die 5 Risiken
1.Testautomatisierung
Die Testautomatisierung ist die Grundlage aller modernen Delivery-Pipelines und ein entscheidender Faktor für den Erfolg oder Misserfolg Ihrer Pipeline. Wenn ein Entwickler neuen oder aktualisierten Code in Ihr Versionsverwaltungssystem (VCS) eincheckt, werden eine Reihe von Tests gestartet. Automatisierte Tests erfüllen viele Aufgaben, wobei eine ihrer wichtigsten Aufgaben darin besteht, als Gatekeeper zu fungieren, der verhindert, dass instabiler, riskanter oder unsicherer Code veröffentlicht und an Kunden ausgegeben wird.
Risiken
Die größten Risiken bei der Testautomatisierung haben eine Reihe von Ursachen, wie z. B. eine übermäßige Abhängigkeit von manuellen Tests (nicht genügend automatisierte Tests) oder zu viele Funktionstests (und nicht genügend Integrationstests). Teams oder Organisationen, die eine Delivery-Pipeline aufbauen und anwenden wollen, aber stark auf manuelle Tests angewiesen sind, haben das größte Risiko zu scheitern. Dies liegt daran, dass die aktuellen DevOps-Delivery-Verfahren auf ein effizientes Build-System setzen, das neue Softwareversionen so schnell wie möglich deployt. Manuelle Tests sind einfach nicht mit DevOps kompatibel, da sie langsam und arbeitsintensiv sind und zu Engpässen führen.
Das Schreiben komplett neuer Tests könnte das Starten des automatisierten Buildprozesses verzögern. Daher könnten Sie versucht sein, bestehende automatisierte Tests wiederzuverwenden. Das Problem ist, dass es sich bei diesen Tests um funktionale Unit-Tests handelt, mit denen Entwickler überprüfen, ob das, was sie entwickeln, funktioniert. Sie sind nicht dazu ausgelegt, ihr Zusammenwirken oder die operativen Aspekte des gesamten Systems, wie API-Aufrufe, Performance und Vernetzung zu testen. Diese Tests müssen vor und nicht nach dem Release in ein Produktivsystem durchgeführt werden.
Lösung
Der beste Weg, um Risiken bei der Testautomatisierung zu vermeiden, ist die Erstellung einer umfassenden Reihe von automatisierten Tests. Außerdem müssen Sie detaillierte Integrationstests anlegen, die sicherstellen, dass der neue Code in das System integriert werden kann. Einige Tests führen nicht-funktionale Tests durch, die die Performance, die Vernetzung, externe APIs, Abhängigkeiten und die Sicherheit überprüfen. Ihre Testreihen sollten einige Funktionstests enthalten. Diese sollten jedoch nicht auf Kosten von Betriebs- oder Integrationstests gehen.
2. Tools
Jeder automatisierte Prozess ist nur so gut wie die dafür ausgewählten Tools. Der Prozess muss aus Anwendersicht so nahtlos und transparent wie möglich sein.
Risiken
Eines der Risiken bei der Wahl der falschen Tools ist die Beeinträchtigung der Benutzererfahrung. Wenn der Anwender das Gefühl hat, dass die neuen Tools den Prozess mühsam gestalten, werden diejenigen, die gezwungen sind, ihn zu befolgen, ihn ablehnen und nach ihren eigenen Alternativen suchen. Es spielt keine Rolle, ob sich die Probleme auf ein einzelnes Subsystem oder auf eine ganze Pipeline konzentrieren. Die Wahl des falschen CI/CD-Tool-Sets, das einem in die Quere kommt, ist ein Risiko, das Sie um jeden Preis vermeiden sollten. Wenn einige Tools nicht richtig konfiguriert oder in das System integriert sind, führen sie außerdem zu Engpässen. Ein System, das Verzögerungen verursacht, wird nicht nur innerhalb eines Unternehmens zum Problem, sondern auch für seine potenziellen und bestehenden Kunden außerhalb des Unternehmens.
Lösung
Nach der Inbetriebnahme des Systems wird es schwieriger, toolbedingte Risiken zu beseitigen. Am besten eliminieren Sie diese Risiken daher bereits in der Planungsphase Ihrer Pipeline. Das Finden der richtigen Tools erfordert umfangreiche Recherchen. Teams oder Organisationen, die diesem Auswahlprozess nicht genügend Zeit widmen wollen, gehen bereits unnötige Risiken ein. Ein wichtiger Faktor ist die Anzahl der verfügbaren Optionen für ein bestimmtes Produkt. Ein Toolset, das versucht, zu viele Optionen abzudecken, läuft Gefahr, nicht die gewünschten Ergebnisse zu erzielen.
3. Nicht versionierter Code
Der Output Ihrer Delivery-Pipeline ist nur so gut wie ihr Input. Mit anderen Worten, die Qualität Ihres Endprojektes hängt stark von der Qualität des ursprünglichen Quellcodes ab. Dies bedeutet, dass die Versionsverwaltung ein wichtiger Teil der Risikominimierung ist.
Risiken
Wenn die Versionsverwaltung nicht durchgeführt wird und es den Entwicklern überlassen bleibt, Code nach eigenem Ermessen einzuchecken, wird dieser Code nicht durch Ihre automatisierten Tests getestet. Dies wiederum wird zu möglichen neuen Problemen und Fehlern führen, die nicht vor größeren Produktions-Releases entdeckt werden. Dieses Problem wird oft noch verschlimmert, wenn ein Unternehmen letztendlich mehrere Versionsverwaltungssysteme unterstützt. Wenn sich ein Entwickler dafür entscheidet, Code in ein Repository einzuchecken, das nicht Teil der Delivery-Pipeline ist, wird er nicht in den endgültigen Build aufgenommen.
Lösung
Ein Versionsverwaltungssystem ist ein wichtiger Teil Ihrer Continuous Delivery Pipeline. Sie können damit beginnen, indem Sie sicherstellen, dass alle Entwickler Code in ein einziges verteiltes Versionsverwaltungssystem übertragen, wie z. B. Git. Ein weiterer Vorteil der Versionsverwaltung besteht darin, dass sie die Entwickler in die Continuous Delivery Pipeline drängt und sie dabei unterstützt, die Qualität der automatisierten Integrationstests Ihres Systems zu verbessern und sie bei Bedarf durch zusätzliche Tests zu ergänzen.
4. Security
Die Reduzierung sicherheitsrelevanter Risiken beinhaltet den Umgang mit einer Reihe von technischen und nicht-technischen Risiken.
Risiken
Der Aufbau einer Delivery-Pipeline ist eine wichtige Vorgehensweise von DevOps. Der Fokus der DevOps-Fachleute liegt jedoch auf der Handhabung von Anwendungsfeatures und -funktionen sowie dem Prozess der Erstellung, dem Release und der Integration von Software. Die meisten von ihnen verfügen nicht über die nötige Schulung oder Motivation, um mit diesen Problemen umzugehen, und wie wir alle wissen, ist das Ignorieren der Software-Sicherheit ein riskanter Ansatz, der immer mit tragischen Folgen verbunden ist.
Eines der größten Probleme beim Aufbau einer automatisierten Delivery-Pipeline ist das Risiko, dem Komfort und der Effizienz Priorität gegenüber der Sicherheit einzuräumen. Zur ordnungsgemäßen Durchsetzung der Softwaresicherheit gehören die Beachtung der Nachrichten, die Kenntnis der neuesten Exploits und das Deployment von Patches. Dieser Prozess kann anstrengend sein, vor allem, wenn er nicht Ihre Kernkompetenz oder Hauptverantwortung ist.
Lösung
Viele Sicherheitsrisiken entstehen durch einen Mangel an Erkenntnissen und Wissen, der durch Weiterbildung und Schulung behoben werden kann. Potenzielle Risiken zu erkennen und zu verstehen, wie man sie beheben kann, ist in einer ruhigen Phase einfacher, als wenn man gleichzeitig mit ihren negativen Auswirkungen umgehen muss.
5. Organisatorisches Durcheinander
Der Erfolg Ihrer Pipeline hängt aber auch von den Menschen in Ihrem Unternehmen ab. Das Problem ist, dass Menschen und Prozesse ihre eigenen Risiken bergen. Ein großes Problem ist das Durcheinander, das mit dem Bau und Betrieb einer Delivery-Pipeline verbunden ist.
Risiken
Wenn niemand weiß, welche Methodik er verfolgt, was es damit auf sich hat, warum es wichtig ist und welche Ziele und Ergebnisse erwartet werden, ist das Projekt zum Scheitern verurteilt. Wenn Sie ein Projekt auf der Basis von agilen und DevOps-Prinzipien aufbauen, wird ein Mangel an gemeinsamen Standards in Verbindung mit schlecht definierten projektbezogenen Begriffen für Verwirrung sorgen. Dies führt oft dazu, dass sich alle über Definitionen und deren Anwendung streiten. Dabei spielt es keine Rolle, ob Sie großartige automatisierte Tests erstellen oder über perfekte Tools verfügen. Wenn Sie keine unterstützende Umgebung und Organisationskultur schaffen, wird Ihre Delivery-Pipeline scheitern.
Lösung
Die mit organisatorischem Durcheinander und Chaos verbundenen Risiken können durch die Erstellung, Standardisierung und Durchsetzung von Richtlinien und Vorgehensweisen reduziert werden. Dies beinhaltet die Standardisierung der relevanten Agile-, DevOps- und Pipeline-Terminologie und -Praktiken in Ihrem Unternehmen. Bessere Kommunikationsmethoden und -Tools können die Risiken ebenfalls reduzieren. Ebenso wichtig ist es sicherzustellen, dass alle Stakeholder und Teammitglieder über das entsprechende Agile- und DevOps-Training verfügen.
Continuous Delivery ohne Risiko
Viele der Ursachen für diese Risiken sind ähnlich. Dazu gehören nicht verwaltete Prozesse, das Fehlen brauchbarer Daten und Erkenntnisse sowie die Unfähigkeit, Projekte innerhalb eines Unternehmens zu überwachen und zu verfolgen.
This block renders a quote for the post drawn from the post's custom fields. Modify the quote below the content editor in the Quote fields.
Hier kann Ihnen ein Drittanbieter-Tool helfen, die fünf oben beschriebenen Risiken für Ihre Continuous Delivery Pipeline zu bewerten und zu bewältigen. Mit Panayas Release Dynamix [RDx] können Sie Ihre Continuous Delivery Pipeline aus Wertströmen, Projekten, Portfolios, Tests und Releases managen. Die integrierte Lösung von Panaya bietet Echtzeit-Datenerfassungs-, Planungs-, Verfolgungs- und Kollaborationsfunktionen für beschleunigte Arbeitsabläufe. Nutzen Sie leistungsstarke Analyse- und Reporting-Tools, um fundierte Entscheidungen zu treffen und Risiken zu minimieren, während Sie mehrere Projekte mit den grafischen Dashboards und Echtzeit-Einblicken von RDx verwalten und verfolgen.
Setzen Sie für End-to-End-Geschäftsprozesstests in großen Unternehmen Panaya Test Dynamix ein, um die mit dem Bereitstellungsprozess verbundenen Risiken zu beseitigen. Mit Echtzeit-Überwachung und -Verfolgung erhalten Sie aktuelle Einblicke in Projektrisiken und -qualität, bewältigen Fehler und stellen die vollständige Nachvollziehbarkeit aller Änderungen sicher.
Der Aufbau einer Continuous Delivery Pipeline birgt zahlreiche Risiken, die Ihre Pipeline ernsthaft aus dem Ruder laufen lassen und möglicherweise ruinieren können. Panaya gibt Ihnen die Tools an die Hand, mit denen Sie die fünf in diesem Artikel besprochenen Risiken – sowie viele andere – adressieren und die Prozesse unterstützen können, die Risiken minimieren, wie z. B. Anforderungsmanagement, Code-Reviews und risikobasiertes Testen. Dadurch erhalten Sie einen wirklich integrierten Ansatz für das Risikomanagement für Continuous Delivery Pipelines.
