Großbritanniens größter Dienstleister für Händler
Die Bereitstellung von Datenbanken war stockend und zeitintensiv
Von der Testinstallation von SQL Clone bis hin zur vollständigen Einführung
Verkürzung der Bereitstellungszeit für Datenbanken um mehr als 85%
Paymentsense ist Großbritanniens größter Dienstleister für Händler. Seine kontaktlosen Kartenterminals und Online-Zahlungsdienste bieten 50.000 KMUs eine einfache und kostengünstige Möglichkeit, jedes Jahr Kartenzahlungen im Wert von über 5 Milliarden Pfund abzuwickeln – im Geschäft, online, per Telefon und unterwegs.
Hinter den Kulissen kümmert sich ein Team, bestehend aus 20 Anwendungs- und Datenbankentwicklern mit Sitz in Großbritannien und vier weiteren, die via Fernzugriff arbeiten, um alle Finanzdienstleistungsanwendungen – mit über 80 Datenbanken in den Entwicklungsumfeldern und 15 in der Produktion.
Um die Entwicklung zu beschleunigen, wählte das Team einen DevOps-Ansatz. Außerdem verfügt es über einen einheitlichen Entwicklungs-, Test- und Bereitstellungsprozess sowohl für Anwendungen als auch für Datenbanken. Mit einer Kombination aus TeamCity, JIRA und Octopus Deploy testet und stellt das Team den ganzen Tag über kontinuierlich Updates bereit
Obwohl dieser Ansatz sehr effizient war, stellte er für Ahmed Althamari, den zuständigen Senior SQL Server DBA, auch eine Hürde für weitere Fortschritte dar. Zwar hatte Paymentsense bereits einen Prozess für die Bereitstellung von Datenbanken für Entwicklungs- und Testumfelder, jedoch erwies sich dieser als stockend und zeitintensiv und verursachte viele Platzprobleme.
So musste er nicht nur lange auf die Erstellung der Datenbankkopien warten, sondern auch oft Dateien auf dem Zielserver verschieben, um überhaupt genug Speicherplatz freizugeben. Manchmal mussten die Datenbankkopien sogar auf einer ganz anderen Festplatte erstellt werden. Für diesen Prozess musste eine bessere Methode gefunden werden.
50,000Der Kunde£5 billion+Pfund abzuwickeln 80Datenbanken“Probleme mit dem Festplattenspeicher störten die Arbeit, wenn Entwickler eine neue Datenbankkopie erstellen wollten.”
Bereits vor der Einführung von SQL Clone, hatte das IT-Team einen effizienten Entwicklungsprozess für Datenbanken. Jeder Entwickler konnte Kopien der Datenbank erstellen, um diese in seiner eigenen Sandbox weiterzuentwickeln und zu testen. Im Testumfeld waren so oft 15 oder mehr Kopien derselben Datenbank im Einsatz.
Dies ermöglichte die gleichzeitige Entwicklung verschiedener Teilbereiche und förderte auf diese Weise einen kontinuierlichen Bereitstellungsprozess, bei dem Änderungen in der Entwicklung vorgenommen, getestet und dann an die Vorproduktion gesendet wurden, bevor sie schließlich flächendeckend übernommen wurden.
Die Hauptprobleme lagen im Prozess der Datenbankbereitstellung – und insbesondere in der Notwendigkeit, alle Entwicklungsserver und die 15 Datenbanken im Testumfeld durchgehend auf dem neuesten Stand zu halten. Der Zeitaufwand für die Wiederherstellung der Datenbanken und der benötigte Speicherplatz waren für alle Beteiligten eine ständige Sorge.
Für die mit durchschnittlich 200-300 GB größten Datenbanken im Testumfeld, kopierte Ahmed lediglich das Schema und importierte anschließend eine kleine Menge Beispieldaten zum Testen.
Obwohl das Schema fehlerfrei war, schränkte es jedoch den Testprozess ein, da die Daten eher eine Abbildung als eine echte Kopie darstellten. Gelegentlich führte dies dazu, dass neu eingesetzte Codes in der Produktion unerwartete Ergebnisse lieferten, die mit den Beispieldaten in der Testumgebung nicht übereinstimmten.
“ "Die Entwickler konnten sich nicht darauf verlassen, dass die Testergebnisse das Verhalten in der Produktion genau widerspiegeln würden.”
Obwohl die Bereitstellung einiger Datenbanken mit Hilfe von Schemata und Beispieldaten den Prozess reibungsloser und weniger zeitaufwendig machte, war dies für Ahmed keine zufriedenstellende langfristige Lösung
“Wenn Sie Datenbanken nur testen und nicht gegen Millionen von Datenzeilen laufen lassen, dann können Sie die wirklichen Auswirkungen der Änderungen auf die Performance nicht sehen.”
Ahmed war bereits mit Redgate vertraut. Jeder Entwickler nutzte SQL Prompt, um SQL-Codes zu schreiben, umzuarbeiten und auszutauschen, sowie SQL Backup Pro als Backup-Software. Daher war er interessiert an SQL Clone und der Aussicht, dass Entwickler vollständige Kopien von Datenbanken zur Verfügung gestellt bekommen und gleichzeitig Zeit wie auch Speicherplatz bei der Bereitstellung sparen könnten. Er informierte sich umfassend über SQL Clone und sprach mehrmals mit seinem Vorgesetzten und Abteilungsleiter über einen möglichen Einsatz.
“SQL Clone schien genau das zu sein, wonach ich suchte, aber die Einführung hätte eine Änderung unserer Entwicklungsprozesse bewirkt – und das ist immer ein Risiko, weil es bedeutet, dass man sie erst einmal zerstören muss. Zudem gibt es in den ersten Tagen immer Bugs bzw. Probleme und eine Instabilität dieser Prozesse ist auf lange Sicht nicht akzeptabel.”
Er arbeitete eng mit Redgate zusammen, um eine Testinstallation von SQL Clone zu implementieren. Nachdem diese in einer echten Darstellung des Lifecycles vollständig getestet worden war, wurde sie schließlich übernommen.
“Wir haben die Zeit für die Datenbankbereitstellung um mehr als 85% reduziert, was eine echte Zeitersparnis ist.”
Der Entwicklungsprozess bei Paymentsense ist im Großen und Ganzen derselbe wie vor SQL Clone.
“Das Problem war nicht unsere Arbeitsweise, sondern die Systeme, die wir genutzt haben. Die Datenbankbereitstellung war langsam und die Verwendung von Beispieldatensätzen bedeutete, dass wir nicht testen konnten, welche Auswirkungen unsere Änderungen auf die Performance hatten.”
Die Einführung von SQL Clone hat einiges verändert. Mit Hilfe der PowerShell-Schnittstelle gibt es nun einen automatisierten Prozess, der in der Nacht ein Backup der Datenbanken durchführt, mit SQL Clone ein Data-Image aus diesem Backup erstellt und es dann auf einem geteilten Laufwerk speichert. Im Zuge eines weiteren Prozesses werden dann mehrere Klone von diesem Data-Image erstellt. Diese sind dann am nächsten Tag verfügbar. Alle nicht verwendeten Klone und Images werden entfernt.
Wenn Entwickler einen neuen Teilbereich erschließen und diesen unabhängig von der Datenbank testen wollen, erstellt der kontinuierliche Bereitstellungsprozess bei Bedarf einen neuen Klon, sodass sie immer eine aktuelle Kopie zum Arbeiten haben. Die Bereitstellung mit SQL Clone nimmt nur wenige Sekunden Zeit in Anspruch. Wie Ahmed sagt:
“Wir möchten Entwickler dazu ermutigen, einen Datenbankklon als eine leicht zu verwendende Ressource zu betrachten, die sie erstellen, in ihren Entwicklungsprozess integrieren und dann wieder löschen können.”
Im Moment führen sie das Data Masking als separaten Schritt durch, indem sie Skripte gegen jeden Klon ausführenDie nächste Aufgabe besteht darin, diesen Schritt in ihren über Nacht stattfindenden automatisierten Prozess zu integrieren. Dies spart nicht nur Arbeitsstunden, sondern beseitigt auch das Speicherplatzproblem, da jeder Klon nur etwa 40 MB benötigt, unabhängig von der Größe der Originaldatenbank. Noch wichtiger ist, dass die Arbeit der Entwickler jetzt viel genauer ist, weil die Klone auf eine realistische Kopie der Daten in der Produktion zugreifen.
case study
Productivity is the big advantage Ryan sees in adopting SQL Clone. It’s not just about saving time on current provisioning processes, it’s about giving the team the ability to introduce new practices and processes that will enable them to do more. What if they wanted to compare different approaches to developing the same feature, or the behavior of before-fix and after-fix versions of a feature, for example?
whitepaper
As database teams grapple with shortening release cycles and tightening data protection laws, the need to deliver realistic and compliant test data to development quickly and safely is greater than ever. Review the most common approaches and their pros and cons in this free whitepaper.
Großbritanniens größter Dienstleister für Händler
Die Bereitstellung von Datenbanken war stockend und zeitintensiv
Von der Testinstallation von SQL Clone bis hin zur vollständigen Einführung
Verkürzung der Bereitstellungszeit für Datenbanken um mehr als 85%
“Probleme mit dem Festplattenspeicher störten die Arbeit, wenn Entwickler eine neue Datenbankkopie erstellen wollten.”
Paymentsense ist Großbritanniens größter Dienstleister für Händler. Seine kontaktlosen Kartenterminals und Online-Zahlungsdienste bieten 50.000 KMUs eine einfache und kostengünstige Möglichkeit, jedes Jahr Kartenzahlungen im Wert von über 5 Milliarden Pfund abzuwickeln – im Geschäft, online, per Telefon und unterwegs.
Hinter den Kulissen kümmert sich ein Team, bestehend aus 20 Anwendungs- und Datenbankentwicklern mit Sitz in Großbritannien und vier weiteren, die via Fernzugriff arbeiten, um alle Finanzdienstleistungsanwendungen – mit über 80 Datenbanken in den Entwicklungsumfeldern und 15 in der Produktion.
Um die Entwicklung zu beschleunigen, wählte das Team einen DevOps-Ansatz. Außerdem verfügt es über einen einheitlichen Entwicklungs-, Test- und Bereitstellungsprozess sowohl für Anwendungen als auch für Datenbanken. Mit einer Kombination aus TeamCity, JIRA und Octopus Deploy testet und stellt das Team den ganzen Tag über kontinuierlich Updates bereit
Obwohl dieser Ansatz sehr effizient war, stellte er für Ahmed Althamari, den zuständigen Senior SQL Server DBA, auch eine Hürde für weitere Fortschritte dar. Zwar hatte Paymentsense bereits einen Prozess für die Bereitstellung von Datenbanken für Entwicklungs- und Testumfelder, jedoch erwies sich dieser als stockend und zeitintensiv und verursachte viele Platzprobleme.
So musste er nicht nur lange auf die Erstellung der Datenbankkopien warten, sondern auch oft Dateien auf dem Zielserver verschieben, um überhaupt genug Speicherplatz freizugeben. Manchmal mussten die Datenbankkopien sogar auf einer ganz anderen Festplatte erstellt werden. Für diesen Prozess musste eine bessere Methode gefunden werden.
“ "Die Entwickler konnten sich nicht darauf verlassen, dass die Testergebnisse das Verhalten in der Produktion genau widerspiegeln würden.”
Bereits vor der Einführung von SQL Clone, hatte das IT-Team einen effizienten Entwicklungsprozess für Datenbanken. Jeder Entwickler konnte Kopien der Datenbank erstellen, um diese in seiner eigenen Sandbox weiterzuentwickeln und zu testen. Im Testumfeld waren so oft 15 oder mehr Kopien derselben Datenbank im Einsatz.
Dies ermöglichte die gleichzeitige Entwicklung verschiedener Teilbereiche und förderte auf diese Weise einen kontinuierlichen Bereitstellungsprozess, bei dem Änderungen in der Entwicklung vorgenommen, getestet und dann an die Vorproduktion gesendet wurden, bevor sie schließlich flächendeckend übernommen wurden.
Die Hauptprobleme lagen im Prozess der Datenbankbereitstellung – und insbesondere in der Notwendigkeit, alle Entwicklungsserver und die 15 Datenbanken im Testumfeld durchgehend auf dem neuesten Stand zu halten. Der Zeitaufwand für die Wiederherstellung der Datenbanken und der benötigte Speicherplatz waren für alle Beteiligten eine ständige Sorge.
Für die mit durchschnittlich 200-300 GB größten Datenbanken im Testumfeld, kopierte Ahmed lediglich das Schema und importierte anschließend eine kleine Menge Beispieldaten zum Testen.
Obwohl das Schema fehlerfrei war, schränkte es jedoch den Testprozess ein, da die Daten eher eine Abbildung als eine echte Kopie darstellten. Gelegentlich führte dies dazu, dass neu eingesetzte Codes in der Produktion unerwartete Ergebnisse lieferten, die mit den Beispieldaten in der Testumgebung nicht übereinstimmten.
“Wir haben die Zeit für die Datenbankbereitstellung um mehr als 85% reduziert, was eine echte Zeitersparnis ist.”
Obwohl die Bereitstellung einiger Datenbanken mit Hilfe von Schemata und Beispieldaten den Prozess reibungsloser und weniger zeitaufwendig machte, war dies für Ahmed keine zufriedenstellende langfristige Lösung
“Wenn Sie Datenbanken nur testen und nicht gegen Millionen von Datenzeilen laufen lassen, dann können Sie die wirklichen Auswirkungen der Änderungen auf die Performance nicht sehen.”
Ahmed war bereits mit Redgate vertraut. Jeder Entwickler nutzte SQL Prompt, um SQL-Codes zu schreiben, umzuarbeiten und auszutauschen, sowie SQL Backup Pro als Backup-Software. Daher war er interessiert an SQL Clone und der Aussicht, dass Entwickler vollständige Kopien von Datenbanken zur Verfügung gestellt bekommen und gleichzeitig Zeit wie auch Speicherplatz bei der Bereitstellung sparen könnten. Er informierte sich umfassend über SQL Clone und sprach mehrmals mit seinem Vorgesetzten und Abteilungsleiter über einen möglichen Einsatz.
“SQL Clone schien genau das zu sein, wonach ich suchte, aber die Einführung hätte eine Änderung unserer Entwicklungsprozesse bewirkt – und das ist immer ein Risiko, weil es bedeutet, dass man sie erst einmal zerstören muss. Zudem gibt es in den ersten Tagen immer Bugs bzw. Probleme und eine Instabilität dieser Prozesse ist auf lange Sicht nicht akzeptabel.”
Er arbeitete eng mit Redgate zusammen, um eine Testinstallation von SQL Clone zu implementieren. Nachdem diese in einer echten Darstellung des Lifecycles vollständig getestet worden war, wurde sie schließlich übernommen.
Der Entwicklungsprozess bei Paymentsense ist im Großen und Ganzen derselbe wie vor SQL Clone.
“Das Problem war nicht unsere Arbeitsweise, sondern die Systeme, die wir genutzt haben. Die Datenbankbereitstellung war langsam und die Verwendung von Beispieldatensätzen bedeutete, dass wir nicht testen konnten, welche Auswirkungen unsere Änderungen auf die Performance hatten.”
Die Einführung von SQL Clone hat einiges verändert. Mit Hilfe der PowerShell-Schnittstelle gibt es nun einen automatisierten Prozess, der in der Nacht ein Backup der Datenbanken durchführt, mit SQL Clone ein Data-Image aus diesem Backup erstellt und es dann auf einem geteilten Laufwerk speichert. Im Zuge eines weiteren Prozesses werden dann mehrere Klone von diesem Data-Image erstellt. Diese sind dann am nächsten Tag verfügbar. Alle nicht verwendeten Klone und Images werden entfernt.
Wenn Entwickler einen neuen Teilbereich erschließen und diesen unabhängig von der Datenbank testen wollen, erstellt der kontinuierliche Bereitstellungsprozess bei Bedarf einen neuen Klon, sodass sie immer eine aktuelle Kopie zum Arbeiten haben. Die Bereitstellung mit SQL Clone nimmt nur wenige Sekunden Zeit in Anspruch. Wie Ahmed sagt:
“Wir möchten Entwickler dazu ermutigen, einen Datenbankklon als eine leicht zu verwendende Ressource zu betrachten, die sie erstellen, in ihren Entwicklungsprozess integrieren und dann wieder löschen können.”
Im Moment führen sie das Data Masking als separaten Schritt durch, indem sie Skripte gegen jeden Klon ausführenDie nächste Aufgabe besteht darin, diesen Schritt in ihren über Nacht stattfindenden automatisierten Prozess zu integrieren. Dies spart nicht nur Arbeitsstunden, sondern beseitigt auch das Speicherplatzproblem, da jeder Klon nur etwa 40 MB benötigt, unabhängig von der Größe der Originaldatenbank. Noch wichtiger ist, dass die Arbeit der Entwickler jetzt viel genauer ist, weil die Klone auf eine realistische Kopie der Daten in der Produktion zugreifen.
