Server-Infrastruktur der Entwicklung CRM bei itdesign, Teil 2

Die Server Infrastruktur will gut geplant sein. (Foto: Joerg Trampert, pixelio)

Die Server Infrastruktur will gut geplant sein. (Foto: Joerg Trampert, pixelio)

Im ersten Teil des Artikels stellten wir Ihnen die Grundlagen der Server-Infrastruktur der Entwicklung CRM vor. Im zweiten Teil erfahren Sie nun Details zur Server-Infrastruktur der Produkt-Entwicklung und der Qualitätssicherung bei itdesign. Diese Details umfassen als Voraussetzung für effiziente Arbeit die wichtigsten Server der beiden Abteilungen.

Wie werden die itdesign Module für CAS genesisWorld entwickelt?

Die Software-Entwickler programmieren die itdesign Module für CAS genesisWorld direkt auf ihren Computern. Dennoch müssen diese Entwicklungs-Computer täglich aktualisiert werden. Da jeder Entwickler für den eigenen Computer verantwortlich ist, kann der Aktualisierungs-Vorgang nicht zentral durchgeführt werden. Erschwerend kommt hinzu, dass die Entwicklungs-Computer nicht auf den gleichen Stand aktualisiert werden, sondern die Entwickler an unterschiedlichen Versionen der Teil-Systeme von CAS genesisWorld arbeiten. Aus diesem Grund muss die Aktualisierung vom Entwickler selbst durchgeführt werden. Damit dieser Vorgang wenig Aufwand verursacht, werden fertige Teil-Systeme zur Verfügung gestellt. Außerdem gibt es Skripte, mit denen die Aktualisierung häufig verwendeter CAS genesisWorld-Systeme halbautomatisch stattfindet, so dass der Entwickler nur den Aktualisierungs-Prozess starten muss. Geänderter Source-Code muss gesichert und für alle Software-Entwickler zugänglich sein. Hierfür werden im Allgemeinen Versionsverwaltungs-Systeme eingesetzt. Versionsverwaltungs-Systeme bieten eine zentrale Ablage für Dateien. Diese Ablage hat eine Historie, die neben den letzten Versionen der Datei auch den Benutzer und den Zeitpunkt der Änderung enthält. Dadurch können Änderungen zurückverfolgt und bei Bedarf vollständig rückgängig gemacht werden. Die Produkt-Entwicklung CRM setzt Subversion als Versionsverwaltung ein. Ein zentraler Subversion-Server ist für alle Entwickler zugänglich und wird regelmäßig gesichert. Damit Source-Code-Änderungen nicht regelmäßig von Hand kompiliert werden müssen, gibt es einen Server, der automatisch oder halbautomatisch Versionen kompiliert. Jede Nacht werden sogenannte nightly builds kompiliert. Diese nightly builds sind ein wichtiger Teil der continuous integration. Zusätzlich hierzu gibt es eine Web-Schnittstelle, über die halbautomatisch neue Versionen erzeugt werden.

Welche zentralen Server-Systeme werden zur Entwicklung verwendet?

Entwicklungs-Systeme zeichnen sich durch häufige Aktualisierungen der einzelnen Komponenten aus. Da an vorhandenen Komponenten täglich von unterschiedlichen Teams Änderungen vorgenommen werden, muss ein ständiger Abgleich dieser Komponenten stattfinden. Nur durch diesen Abgleich wird sichergestellt, dass es keine Inkompatibilitäten zwischen den geänderten Teil-Systemen gibt und dass Fehler aufgrund solcher Inkompatibilitäten zur Zeit der Entwicklung erkannt und behoben werden. Abseits von dezentralen Entwicklungs-Computern verwenden Entwickler in vielen Fällen zentrale Komponenten. Sehr häufig werden Anpassungen für CAS genesisWorld für den Client entwickelt, weshalb ein zentraler CAS genesisWorld-Applikationsserver zur Entwicklung verwendet wird. Diese zentralen Applikationsserver werden täglich automatisiert aktualisiert. Um Arbeitsunterbrechungen durch Wartungsfenster zu vermeiden, werden diese Systeme nachts aktualisiert. Es ist weder sinnvoll noch durchführbar, alle denkbaren System-Umgebungen zentral zur Verfügung zu halten. Durch die Austauschbarkeit einzelner Teil-Systeme sind sehr viele Kombinationen denkbar, die in der Praxis jedoch kaum eingesetzt werden. Dennoch gibt es immer wieder Fälle, in denen besondere System-Umgebungen benötigt werden. Um das Erzeugen dieser Umgebungen einfach zu gestalten, werden zentral Betriebssystem-Templates zur Verfügung gestellt, mit deren Hilfe dieser Vorgang schnell durchgeführt wird. Neben diesen Templates muss natürlich ein Hardware-Ressourcen-Puffer vorgehalten werden, um mit Hilfe dieser Templates neue Systeme zu erzeugen. Zur Speicherung der Daten werden zentrale Datenbank-Server verwendet. Die Verantwortlichkeit für diesen Datenbank-Server und die Dienste, die dieser Datenbank-Server bereitstellt, sind klar definiert. Dadurch muss sich nicht jeder Entwickler um die Datenbank-Server kümmern. Neben den Datenbank-Servern, die von der Mehrzahl aller CAS genesisWorld-Kunden eingesetzt werden, existieren auch Datenbank-Server, die für CAS genesisWorld nur selten benötigt werden. Da die Unterstützung für diese Systeme ebenfalls gewährleistet werden muss, stehen sie als zentrale Systeme zur Verfügung und werden für die tägliche Arbeit verwendet.

Wie wird CAS genesisWorld getestet?

In einem sehr anpassbaren CRM-System wie CAS genesisWorld ist es wichtig, strukturiert zu testen. Das bedeutet dass vor dem Beginn des Tests ein schriftlicher Plan mit den Test-Schritten ausgearbeitet wird. Das schließt auch den Test von unterschiedlichen Konfigurationen ein. Um Test-Ergebnisse vergleichbar zu machen, sind dauerhaft gleichbleibende Systeme von größter Wichtigkeit. Diesem Umstand wird Rechnung getragen, indem die verwendeten Systeme konfiguriert und anschließend gesichert werden. Durch das regelmäßige automatische Wiederherstellen der Systeme werden Änderungen, die zur Test-Zeit durchgeführt werden, rückgängig gemacht, ohne dass ein manueller Eingriff notwendig ist. Für automatische Tests ist dieser Aspekt sehr wichtig. Strukturiertes Testen ist sehr aufwändig. Vor dem Test müssen anhand der Funktions-Beschreibung Testfälle erarbeitet werden. Diese Testfälle müssen mögliche Nebeneffekte von Optionen berücksichtigen, die auf den ersten Blick nicht mit der neuen Funktion in Zusammenhang stehen. Anschließend müssen die Tests durchgeführt und die Ergebnisse protokolliert werden. Werden Fehler gefunden, müssen sie behoben und die Behebung des Fehlers erneut getestet werden.

Gibt es automatische Tests?

Aufgrund des hohen Aufwandes für manuelle Tests werden Tests automatisiert. Die Automatisierung eines Tests ist zwar viel Arbeit, durch die mittel- bis langfristige Zeitersparnis bei Regressions-Tests lohnt sich dieser Aufwand aber. Regressions-Tests sind Tests, bei denen bereits getestete Funktionen nochmal getestet werden. Durch solche Tests werden unerwünschte Seiteneffekte schnell aufgedeckt und anschließend von der Software-Entwicklung korrigiert. Aus diesem Grund wird jede Version, ob automatisch oder halbautomatisch erzeugt, von einem Test-Programm einzeln geprüft. Dieser automatische Test ist sehr wichtig, um dauerhaft eine gleichbleibend hohe Qualität zu liefern.

Welche Test-Systeme setzen wir ein?

Neben den automatischen Tests müssen Tests manuell durchgeführt werden. Dies ist beispielsweise dann erforderlich, wenn Funktionen noch nicht vom automatisierten Test abgedeckt sind oder ein automatisierter Test für die zu testende Funktion nicht geplant ist. Dadurch stehen, ähnlich wie in der Entwicklungs-Infrastruktur, Systeme zur Verfügung, die automatisiert aktualisiert werden. Für die Sprachen Tschechisch, Ungarisch, Rumänisch und Türkisch gibt es separate Installations-Routinen für CAS genesisWorld, die die Software in einer anderen Sprache installieren. Für diese Versionen gibt es spezielle Systeme, die für diese Sprache konfiguriert sind. Die Trennung von Systemen und Sprachversionen ist wichtig, da die Version und die Einstellungen des Betriebssystems Einfluss auf den Betrieb der Sprachversionen haben. Da für CAS genesisWorld sehr unterschiedliche Client-Systeme im Einsatz sind, muss der Qualitätssicherung ein Querschnitt dieser Systeme zum Testen zur Verfügung stehen. Dieser Querschnitt unterscheidet sich in der Konfiguration und in den verwendeten Komponenten, so dass Fehler, die durch solche Kombinationen hervorgerufen werden, gefunden werden. Neben bereits unterstützten Systemen müssen neue Systeme, vor allem neue Betriebssysteme, einem intensiven Test unterzogen werden. Voraussetzung dafür sind genügend Hardware-Ressourcen, um neue Test-Systeme zu erzeugen, auf denen dann beispielsweise die neuen Betriebssysteme installiert werden.
Neben Standard-Funktionen von CAS genesisWorld gibt es weitere Module wie beispielsweise Mobile Apps oder Exchange Sync. Diese Module bedürfen einer separaten Installation und Konfiguration und werden deshalb getrennt von den restlichen Test-Systemen betrieben.

Wie wird die Geschwindigkeit von CAS genesisWorld getestet?

Da sich Geschwindigkeitsunterschiede in Programmen erst bei größeren Änderungen bemerkbar machen, besteht in diesen Fällen die große Gefahr, dass solche Qualitäts-Verschlechterungen nicht bemerkt werden. Um aber dennoch Geschwindigkeitseinbußen zu vermeiden, müssen regelmäßig Tests mit gleichen Rahmenbedingungen durchgeführt werden. Diese Tests laufen auf Servern ab, die von der restlichen Test-Infrastruktur getrennt sind, um unerwünschte Nebenwirkungen, die den Test verfälschen, zu vermeiden und repräsentative Ergebnisse zu erzielen.

Fazit

Die Ansprüche, die von moderner Software-Entwicklung und Qualitätssicherung an die Server-Infrastruktur gestellt werden, sind sehr unterschiedlich. Durch eine zentrale Server-Infrastruktur werden Synergie-Potentiale genutzt und wiederkehrende Arbeiten zentral automatisiert. Dadurch ist der Eingriff eines einzelnen Entwicklers nicht mehr vonnöten, und die Wartung der Systeme kann im Team verteilt werden. Neben der Verringerung des Aufwandes werden Arbeitsunterbrechungen durch Wartungsfenster stark reduziert oder sogar vermieden. Für die Qualitätssicherung ist eine solche Server-Infrastruktur Voraussetzung, um vergleichbare Test-Ergebnisse zu liefern und effizient zu arbeiten. Vor allem für Leistungs-Tests, bei denen eine niedrige Varianz der Test-Ergebnisse wichtig ist, um aussagekräftige Analysen durchzuführen, ist eine abgeschottete Test-Infrastruktur wichtig. Voraussetzung für diese Server-Infrastruktur sind genügend Hardware-Ressourcen, um eine sinnvolle Infrastruktur aufzubauen und die Flexibilität zu gewährleisten, auf veränderte Rahmenbedingungen zu reagieren.

Über den Autor

Tobias Baus (Wirtschaftsingenieur) arbeitet seit 2009 bei itdesign. Nach zweieinhalb Jahren in der Technischen Beratung CRM wechselte er in die Entwicklung CRM und ist dort unter anderem für die Betreuung der Server-Infrastruktur verantwortlich.