Erfahren Sie, wie die Continuous Quality Platform von Parasoft dabei hilft, Testumgebungen zu steuern und zu verwalten, um zuverlässig hochwertige Software zu liefern. Für Demo registrieren >>
Lesezeit: 11 MinutenDer beste Weg um Bringen Sie Service-Virtualisierung in Ihr Unternehmen wird Schritt für Schritt dort eingesetzt, wo es am wertvollsten ist, um die Gesamtkosten des Testens zu senken und die Möglichkeit zu erhalten, Ihren Testautomatisierungsprozess mit einem vollständig automatisierten DevOps-Workflow wirklich zu kontrollieren.
Wenn Sie sich entscheiden, dass es Zeit ist, beispielsweise etwas Gewicht zu verlieren, können Sie Nachforschungen anstellen und am Ende Ratschläge wie „S.Top Alkohol trinken! Fangen Sie an, Grünkohl zu essen! Geh um 8 Uhr ins Bett! Gehen Sie jeden Tag 5 Meilen! " Und obwohl es möglicherweise sinnvoll ist, all diese Aktivitäten zu nutzen, um einen gesunden Lebensstil anzunehmen, werden Sie wahrscheinlich scheitern, wenn Sie versuchen, sie alle auf einmal zu übernehmen. Stattdessen müssen Sie Schritt für Schritt vorgehen: Fügen Sie hier eine zusätzliche Übung hinzu, treffen Sie dort eine gesunde Wahl für das Essen… und bringen Sie sich langsam auf ein Niveau, auf dem Sie wirklich wie ein Profi Diät halten können.
Service-Virtualisierung ist nicht anders. Im Laufe der Jahre habe ich zahlreichen Kunden geholfen Nehmen Sie diesen wertvollen DevOps-Enabler an, und ich finde, dass die meisten Unternehmen den Big-Bang-Ansatz verfolgen wollen – indem sie sofort eine vollständig bereitgestellte Lösung einführen, die sich über mehrere Teams erstreckt und als Teil ihrer Continuous Delivery-Pipeline integriert ist. Und obwohl all diese Dinge unerlässlich sind, um den potenziellen ROI, den Service-Virtualisierung Ihnen bieten kann, voll auszuschöpfen, werden Sie wahrscheinlich nicht in der Lage sein, effektiv zu skalieren, wenn Sie versuchen, all diese Dinge am ersten Tag zu tun Ihre vollständige DevOps-Bereitstellung. Wie kommen Sie dorthin?
In diesem Blog werde ich genau das teilen. Wir werden einer Person folgen, von ihrer einzelnen Lizenz für die kostenlose Servicevirtualisierung bis hin zur vollständigen Bereitstellung der Servicevirtualisierung durch ihr Unternehmen, die in den DevOps-Workflow integriert ist. Dies basiert auf einer wahren Begebenheit, aber aus Gründen der Anonymität werden wir diese einzelne Sally nennen.
Treffen Sie Sally, die Entwicklerin. Sally war schlau und konnte sich viel schneller entwickeln als ihre Kollegen. Sie hatte während der Testphase angefangen, Mocks zu verwenden, um sich zu isolieren, aber sie verbrachte viel Zeit damit, die Art von Logik zu entwickeln, die sie zum Einbau in diese Systeme benötigte, da die tatsächlichen Anwendungen, die sie auslöschte, etwas komplex waren.
So lernte sie, wie mithilfe der Service-Virtualisierung in kürzester Zeit ein komplizierterer virtueller Service erstellt werden kann. Sie hat die heruntergeladen kostenlose Version von Parasoft Virtualize um eine kostenlose Service-Virtualisierung zu erhalten, die es ihr ermöglichte, virtualisierte Services zu erstellen und diese einfach zu ändern, während sich die tatsächlichen Services ändern. Infolgedessen konnte sie alle ihre Tests und Entwicklungen in einer völlig isolierten Umgebung durchführen.
Während sie diese Vorteile mit einigen ihrer Mitarbeiter diskutierte, wollten auch sie die von ihr erstellten Services nutzen, da es sich um gemeinsame Services zwischen den verschiedenen Entwicklern handelte und sie ihre Anwendungen einfach auf Sallys Computer richten und die Vorteile nutzen konnten.
Daher erhielten auch sie mit Parasoft Virtualize eine kostenlose Service-Virtualisierung und begannen, neue Services zu erstellen, diese Services anzupassen und diese Services von ihren kostenlosen Desktops aus zu nutzen. Das Team machte bedeutende Fortschritte bei der Entwicklung und beim Testen, da es in der Lage war, viele der in der Umwelt vorhandenen Engpässe zu reduzieren. Das Team wurde bekannt für seine Beweglichkeit und bekam die besten Projekte.
Eines Tages wurde Sallys Team vom Management angesprochen, das neugierig auf die Service-Virtualisierungslösung war, die das Team verwendete, um die Anwendungen schneller zu erstellen und zu testen. Sie wollten eine Diskussion über die praktische Anwendung in der größeren Umgebung führen. In den Integrations- und Produktionsumgebungen gab es einige Probleme mit Ausfällen, die durch ältere Anwendungen verursacht wurden. Die Anwendungen stützten sich auf eine Reihe von Oracle-Datenbanken sowie einen komplexen ESB und einen Mainframe.
Diese Systeme waren aus einer Reihe von Gründen schwer zu testen, und Sally und ihr Team konnten zeigen, dass es einfach war, die Dienste hinter dem ESB zu simulieren, da es sich um grundlegende REST- und SOAP-Dienste sowie einige JMS und MQ mit handelte hausgemachtes XML. Um die ältere Hardware in Angriff zu nehmen, mussten sie ihren Service-Virtualisierungs-Desktop aufladen, sodass sie auf die Vollversion von upgraden konnten Parasoft Virtualisieren.
Zu diesem Zeitpunkt konnten sie die Service-Virtualisierung problemlos auf die verschiedenen Herausforderungen anwenden, die in den vom Management beschriebenen Anwendungsfällen auftreten. Es dauerte einige Tage, um sicherzustellen, dass die virtuellen Dienste alle unterschiedlichen Anwendungsfälle erfüllten, aber sie konnten alle Herausforderungen, die sie in diesen Umgebungen hatten, entsperren. Dies war einer der wichtigsten Wendepunkte für die Service-Virtualisierungsbewegung in Sallys Organisation, da sie das Know-how von Sallys Team bei der grundlegenden Service-Virtualisierung nutzen konnten, um kompliziertere Herausforderungen zu bewältigen, mit denen tatsächlich Kosten verbunden waren.
Das Managementteam unternahm dann den nächsten wertvollen Schritt für sein Unternehmen und schuf ein dediziertes Kompetenzzentrum für Servicevirtualisierung innerhalb des Unternehmens, das zum Aufbau virtueller Services genutzt werden kann, wenn neue Herausforderungen auftreten. Sally war natürlich die natürliche Passform, um das Team zu führen.
Sally begann Prozesse zu entwickeln, um Virtualisierungsinitiativen zu integrieren und Akzeptanzkriterien zu erstellen, damit das Team selbst kein neuer Engpass wurde. Governance wurde ein wichtiger Teil des Gesprächs. Das Team hat eine Reihe von Rollen und Verantwortlichkeiten eingerichtet, um sicherzustellen, dass jedes Virtualisierungsprojekt erfolgreich war. Es gab 5 Rollen:
Das Einrichten dieser Rollen war entscheidend für den Erfolg des Service-Virtualisierungsteams, um die Anforderungen für den Erfolg der Virtualisierungsprojekte zu klären. Jedes Mitglied des Service-Virtualisierungsteams verfügte über eine Parasoft Virtualize-Desktopsoftware. Sie würden die virtuellen Dienste auf dem Desktop erstellen und sie dann den Benutzern zur Verfügung stellen.
Als das Team immer beliebter wurde, wurde klar, dass es seinen Einsatz skalieren musste. Wenn eines der Teammitglieder die Maschine herunterfahren oder in den Urlaub fahren müsste, würde dies Auswirkungen auf Benutzer haben, die die virtuellen Dienste nutzen. Daher entschied Sally, dass es Zeit war, ihre Bereitstellungsarchitektur erneut zu aktualisieren, und beschaffte sich einen Virtualisierungs-Staging-Server.
Auf diese Weise konnte sich jedes Teammitglied zusammenschließen und seine virtuellen Assets gemeinsam nutzen. Der Server war "immer eingeschaltet" und fungierte als virtuelle Artefaktbibliothek. Der Server war mit der Quellcodeverwaltung verbunden, sodass verschiedene Versionen der Dienste, die auf dem Server bereitgestellt wurden, automatisch eingecheckt wurden. Dadurch konnte das Team einen zentralen Wahrheitspunkt für alle virtuellen Assets festlegen, und niemand musste raten wo war die neueste Version.
Das Team summte mehrere Monate lang glücklich mit und löste große und bedeutsame Herausforderungen für die Organisation. Es war größer geworden und hatte ein paar weitere Mitglieder hinzugefügt. Um die Sichtbarkeit und das Bewusstsein des Teams zu erhöhen (und auch das Budget zu vergrößern), hatte Sally das Programm „Hoo-Rah“ implementiert. Jedes Mal, wenn das Team etwas mit quantifizierbarem ROI aufbaute, verfolgte es die Gewinne und verschickte eine öffentliche E-Mail, in der erklärt wurde, was es getan hatte und welche Teams davon profitiert hatten. Beispiele für diese "Hoo-Rah" waren:
Diese „Hoo-rah“ -E-Mails waren von entscheidender Bedeutung, um zusätzliche Teams zusammenzubringen, halfen aber auch den wichtigsten Stakeholdern des Unternehmens, die Bedeutung der Service-Virtualisierung für den Testautomatisierungsprozess zu verstehen.
Dann, eines Abends im Spätsommer, führte ein Mitglied des Sicherheitsteams eine Prüfung einer kritischen Anwendung durch und entdeckte einen potenziellen Angriffsvektor in das System, der ausgenutzt werden konnte und nicht nur dazu führte, dass vertrauliche Kundendaten verloren gingen, sondern auch die Organisation zwang aus Compliance. Wenn dies nicht schnell behoben wird, muss die Organisation das Compliance-Komitee aktualisieren und den Strafprozess einleiten.
Das Team erkannte, dass, wenn es den Fehler innerhalb eines bestimmten Zeitfensters beheben könnte, es die Änderungen in die Produktionsumgebung übertragen könnte und alles gut wäre. Die Herausforderung bestand darin, dass sie, um das Problem erfolgreich zu reproduzieren, viele ihrer Drittanbieter-Zahlungssysteme in einen Zustand versetzen mussten, in dem sie verschiedene Fehlerzustände zurückgeben und absichtlich PII- oder Kundendaten preisgeben würden.
Das Team war nicht in der Lage, diese Systeme, die außerhalb seiner Kontrolle lagen, in den Zustand zu zwingen, den es benötigte, um den Fehler aufzudecken und die Korrekturen zu validieren, die es einführen würde. Sally wurde mitten am Abend angerufen und gebeten, zur Arbeit zu gehen.
Das Team machte sich schnell daran, vorhandene virtuelle Dienste, die sie für diese Zahlungssysteme von Drittanbietern erstellt hatten, wiederzuverwenden und sie in einen Zustand zu versetzen, in dem sie negatives Verhalten zurückgeben würden. Da die Anwendung nicht erneut bereitgestellt werden musste, konnten sie einfach das Verhalten ändern, während die Entwickler ihre Änderungen vornahmen, und alle unterschiedlichen Kombinationen löschen, die zu dem potenziellen Exploit führten. Unnötig zu erwähnen, dass das Team erfolgreich einen heißen Patch in die Produktion gebracht hat, der dem Unternehmen Millionen gespart hat.
Das Team des Service-Virtualisierungszentrums von Sally war jetzt bei Entwicklern und Testern beliebt, und viele von ihnen fragten selbst nach dem Zugriff auf Parasoft Virtualize, damit sie ihre eigenen Prototypen erstellen und negative und positive Szenarien validieren konnten. Sally hatte die Infrastruktur, um dies zu unterstützen, aber sie musste ihnen nicht unbedingt den schweren Hammer geben, der die professionelle Desktop-Version war, also aktualisierte sie ihre Infrastruktur erneut und integrierte die Thin-Client-Oberfläche von Parasoft, um ihre DevOps-Workflows vollständig zu aktivieren. Dieses zentralisierte Dashboard ermöglichte jedem Benutzer in der Organisation den Zugriff und ermöglichte es ihm, virtuelle Dienste und Testfälle direkt über seinen Browser zu erstellen.
Diese Weiterentwicklung der Bereitstellung führte zu einem „Hybridmodell“, in dem einzelne Teammitglieder zusammengeschlossen agieren, ihre eigenen virtuellen Dienste für ihre Anforderungen erstellen, auf sie zugreifen, sie ändern usw. Und als es an der Zeit war, diese virtuellen zu integrieren Für die Integration in die größere Architektur verfügten sie über einen Mechanismus zur Zusammenarbeit mit dem Virtualisierungszentrum. Das Team könnte zusätzliche Server hinzufügen, um die Auslastung zu unterstützen, und Leistungsserver einschalten, wenn das Leistungsteam an Bord kommt.
Zu diesem Zeitpunkt verfügte Sally über eine umfassende Bibliothek virtueller Assets sowie entsprechende automatisierte Testfälle. Sie hatte eine Bibliothek mit Testdaten, die in diese beiden Testartefakte eingespeist wurden. Der Großteil der eigentlichen Serviceerstellung wurde von den einzelnen Teams durchgeführt, und Sallys Team war in erster Linie dafür verantwortlich, all diese verschiedenen virtuellen Services in einer „Umgebung“ zu orchestrieren. Die Umgebung war eigentlich nur eine Vorlage für virtuelle Assets, Testfälle und Testdaten, die in eine bestimmte Konfiguration integriert wurden, um eine Testinitiative zu erfüllen. Sie haben viele dieser Umgebungsvorlagen erstellt und sie an den verschiedenen Anwendungen in der Organisation ausgerichtet.
Wann immer eine Anwendung getestet werden musste und die reale Umgebung nicht ausreichte, spaltete das Virtualisierungszentrum eine Umgebung mit verschiedenen virtuellen Diensten ab und ermöglichte den Teammitgliedern das Testen. Die Teams waren im Rahmen ihrer Testausführung immer mehr auf virtuelle Dienste angewiesen, und dies war ein natürlicher Übergang in die Pipeline für die kontinuierliche Bereitstellung.
Die endgültige und vollständig realisierte Bereitstellung für die Servicevirtualisierung in Sallys Organisation sah folgendermaßen aus:
Einzelne Teammitglieder würden die virtuellen Dienste und Testfälle in ihrem Browser erstellen. Wenn die virtuellen Dienste aktualisiert oder zusätzliche Logik hinzugefügt werden müsste, würde das Virtualisierungs-COE dies mit seinen professionellen Desktops erledigen. Die virtuellen Dienste und Testfälle würden dann innerhalb der Thin Client-Schnittstelle kombiniert, und wenn diese Umgebungen verfügbar sein müssten, würde ihr Build-System sie entweder in der Cloud oder auf dedizierten Servern aufrufen und bereitstellen. Die automatisierten Testfälle würden dann beginnen, die Ergebnisse würden an ihr aggregiertes Dashboard gesendet und die dynamische Umgebung würde zerstört.
Echte kontinuierliche Tests, die durch Service-Virtualisierung ermöglicht werden, finden nicht über Nacht statt. Diese Geschichte ist real und alles ist mit Service-Virtualisierung möglich, aber es erfordert, dass die Organisation eingekauft wird und von Grund auf neu beginnt, genau wie Sally. (Übrigens ist sie jetzt im Vorstand.) Dies ist der beste Weg, um Service-Virtualisierung in Ihr Unternehmen zu bringen - Schritt für Schritt dort, wo sie am wertvollsten ist. Die genaue Reise eines jeden wird anders sein, aber das Endergebnis sollte das gleiche sein: Senkung der Gesamtkosten für Tests und Gewinnung der Fähigkeit, Ihren Testautomatisierungsprozess wirklich zu steuern.
Als Produktmanager bei Parasoft strategisiert Chris die Produktentwicklung der Funktionstestlösungen von Parasoft. Seine Expertise in der SDLC-Beschleunigung durch Automatisierung hat ihn zu wichtigen Unternehmensbereitstellungen wie Capital One und CareFirst geführt.