Inhalt I. Abbildungsverzeichnis... 5 II. Quellcodeverzeichnis... 6 III. Abkürzungsverzeichnis... 7 IV. Abstract Einleitung

Transkript

1 Sperrvermerk Die vorliegende Arbeit beinhaltet interne und vertrauliche Informationen der Firma dotsource GmbH. Die Weitergabe des Inhaltes der Arbeit und eventuell beiliegender Zeichnungen und Daten im Gesamten oder in Teilen ist grundsätzlich untersagt. Es dürfen keinerlei Kopien oder Abschriften - auch in digitaler Form - gefertigt werden. Ausnahmen bedürfen der schriftlichen Genehmigung der Firma dotsource GmbH. 2

2 Inhalt I. Abbildungsverzeichnis... 5 II. Quellcodeverzeichnis... 6 III. Abkürzungsverzeichnis... 7 IV. Abstract Einleitung Die dotsource GmbH Die SCOOBOX Zielsetzung Vorgehen Analyse der Problemstellung Entwicklungsmodell Prozesse Architektur Stand der Forschung und Technik Entwicklungsmodelle Iteratives Modell Agile Softwareentwicklung Continuous Delivery Prozesse Versionierung und Release Management Regelmäßige Integration Build-Prozess Automatische Tests Statische Code Analyse Infrastruktur Automatisierung Architektur Komponenten und Abhängigkeiten Agile Datenbankentwicklung Konzept und methodisches Vorgehen Entwicklungsmodelle Prozesse Versionierung und Release Verwaltung Build-Prozess

3 Automatische Tests Statische Code Analyse Infrastruktur Automatisierung Architektur Komponenten und Abhängigkeiten Agile Datenbankentwicklung Umsetzung Statische Codeanalyse Violation s Multilingual Prüfung Build-Prozess Einsatz einer Ram Disk Einsatz alternativer Task Aufrufe Parallelisierung des Build-Prozesses Datenbankmigration Automatische Tests Bewertung Realisierungen Sonar Build-Prozess Datenbankmigration Automatische Tests Zusammenfassung Fazit und Ausblick V. Glossar VI. Anhang VII. Literaturverzeichnis VIII. Thesen IX. Selbstständigkeitserklärung

4 I. Abbildungsverzeichnis Abbildung 1: Einteilung der Softwaretechnik[5]...11 Abbildung 2: Anteile bei der Softwareentwicklung...12 Abbildung 3: SCOOBOX Architektur (Ausschnitt)...14 Abbildung 4 Scrum Zusammenfassung [14]...18 Abbildung 5: Beispielhafter Aufbau eines Kanban Boards...20 Abbildung 6 Beispiel einer Deployment Pipeline [20] (S. 4)...21 Abbildung 7: Gegenüberstellung von DB-Init und DB-Migrate...34 Abbildung 8: Schematische Darstellung der Abhängigkeiten in der build.xml (erstellt mit yworks Ant Explorer)...39 Abbildung 9: Abhängigkeiten SCOOBOX Cartridges, schematisch dargestellt, Stand Abbildung 10: Ablauf des erstellten Migrate Skripts

5 II. Quellcodeverzeichnis Listing 1: Anpassung XSL Datei für gezielten Versand...36 Listing 2: Ausschnitt(vereinfacht) Clean.xml parallelisiert...39 Listing 3: Ausschnitt(vereinfacht) Build_all.xml parallelisiert...40 Listing 4: Ausschnitt (vereinfacht) Build_all.xml setparallelbuildproperties...41 Listing 5: Ausschnitt(vereinfacht) Build_all.xml build_all_fast

6 III. Abkürzungsverzeichnis Abkürzung CD CI CMS CVS DCVS ISML MMF QA ORM SVN TDD VM XP XLT XSLT Bedeutung Continuous Delivery Continuous Integration Configuration Management System Concurrent Versions System Distributed Concurrent Versions System Intershop Markup Language Minimal Marketable Feature Quality Assessment Object Relational Mapping Subversion Test Driven Development Virtuelle Maschine Extreme Programming Xceptance Load Test Extensible Stylesheet Language Transformation 7

7 IV. Abstract Software wird nach einem Release oft umfänglich weiterentwickelt und unterliegt zahlreichen Releases. Insbesondere agile Vorgehensmodelle fördern dieses Vorgehen. In vielen Entwicklungsprojekten ist es eine wichtige Anforderung, trotz dieser laufenden Fortentwicklung eine Abwärtskompatibilität zu bestimmten Systemen bereitzustellen. Genau diese Umstände treffen auf das Produkt SCOOBOX des Unternehmens dotsource GmbH zu, bei der diese Arbeit entstand. Die SCOOBOX ist eine Sammlung von Softwaremodulen, mit denen Online Shops, auf Intershop Basis, um Social Commerce Inhalte erweitert werden können. Sie wird kontinuierlich weiterentwickelt und in Kundenprojekten der dotsource GmbH eingesetzt. Vor der Erstellung dieser Arbeit war eine Aktualisierung der SCOOBOX innerhalb eines Kundensystems nur mit sehr hohem Aufwand möglich. Ziel dieser Arbeit ist es deshalb diesen Aufwand zu verringern. Auf Basis von aktuellen Recherchen wird in dieser Arbeit der aktuelle Stand der Technik zu dieser Thematik beschrieben. Für Einzelne, Methoden kwird die praktische Umsetzung betrachtet. Insbesondere wurden Verbesserungen in den Bereichen der statischen Codeanalyse, der automatischen Tests und der agilen Datenbankentwicklungsprozesse umgesetzt. Für eine verbesserte Codeanalyse und die Einführung von automatische Tests wurde der Build Prozess so optimiert, dass er weniger Zeit (etwa 2 min statt 7 min) in Anspruch nimmt Neue Code Analyse Regeln wurden für Intershop Pipelines und ISML Dateien erstellt. Die Prüfung von JavaScript Dateien und die Ausführung automatischer Oberflächen- und Unit-Tests wurden vorbereitet. 8

8 1. Einleitung Die Entwicklung von Software ist zunehmend dadurch gekennzeichnet, dass die Produkte komplexer werden, während sich die zur Verfügung stehende Zeit gleichzeitig verkürzt. Auch Anforderungen können sich im Prozess der Entwicklung verändern. Daraus folgt eine kontinuierliche Fort- und Weiterentwicklung der Software, die jedoch die Gefahr birgt, dass durch Veränderungen die Kompatibilität mit bestehenden Produktivsystemen eingeschränkt wird. Nach einer Untersuchung aus dem Jahr 2011 gibt es bei mehr als einem Drittel der Projekte so schwerwiegende Probleme, dass ihr Abschluss bedroht ist. [1] Die immer breiter werdenden Anwendungsmöglichkeiten für moderne Software sind die Basis für einträgliche Gewinnmargen in der IT-Branche. Allerdings ist zu berücksichtigen, dass der Entwicklungsprozess in der Regel hoher Anfangsinvestitionen bedarf. Umso bedeutender ist es, Methoden zu entwickeln und einzusetzen, die den Entwicklungsprozess sicher gestalten und im Ergebnis hochqualitative Produkte generieren. Für die Unternehmen ist es ein bedeutender und sich dauerhaft wiederholender Prozess, die effektivsten Methoden und Technologien zu erproben und anzuwenden. Dadurch können Wettbewerbsvorteile erzielt und die Termintreue gegenüber Kunden verbessert werden. Die vorliegende Arbeit beschäftigt sich mit der Analyse und Optimierung eines Softwareentwicklungsprozesses am Beispiel der SCOOBOX, welche ein Produkt der dotsource GmbH ist. Die dotsource GmbH und die SCOOBOX werden in den folgenden Abschnitten vorgestellt Die dotsource GmbH Die dotsource GmbH wurde im Jahr 2006 in Jena gegründet. Heute beschäftigt das Unternehmen rund 90 Mitarbeiter. Im Jahr 2012 wurde ein Umsatz von 4,3 Millionen Euro realisiert. Mit diesen Ergebnissen ist dotsource eine der wachstumsstärksten E-Commerce Agenturen Deutschlands. Im Internetagentur-Ranking2013 [2] wurde sie auf dem 56. Platz notiert. Die dotsource GmbH ist professioneller Anbieter von E-Commerce Produkten. Der größte Geschäftsanteil wird durch die Umsetzung von Großprojekten für Onlineversandhäuser realisiert. Als Basis werden Softwareprodukte von Intershop und Magento eingesetzt. Aktuell wird das Portfolio mit weiteren Partnern, wie z.b. Eggheads oder Hybris erweitert. Ein zusätzlicher Geschäftsbereich ist das Angebot von Beratungs- und Unterstützungsdienstleistungen. [3] 9

9 Um den langfristigen Erfolg zu sichern, werden im Unternehmen nach und nach neue Konzepte des E-Commerce getestet, verbessert und umgesetzt. Dafür hat die SCOOBOX, welche im nächsten Abschnitt vorgestellt wird, eine besondere Bedeutung. Eine langfristige Vision ist "E-Commerce ab der ersten Idee", welche das Ziel beschreibt, E-Commerce Plattformen zu erstellen, bei deren Konzeption, Entwicklung und Realisierung der Kunde durchgehend beraten wird. [4] 1.2. Die SCOOBOX Die SCOOBOX (Social Commerce Out Of the BOX) ist eine Erweiterung der Standard Intershop Software. In der Vergangenheit wurde sie ausschließlich für die Umsetzung von Kundenprojekten verwendet. Die SCOOBOX stellt Funktionen bereit, wie es sie in den sozialen Netzwerken gibt, wie etwa eine Pinnwand oder eine Nachrichtenfunktion. Weitere Features sind zum Beispiel Blog, Forum, Mobile Shopping und Co-Shopping. Zusätzlich gibt es die Möglichkeit, die Nutzerprofile mit sozialen Netzwerken, wie Facebook oder Google+ zu verknüpfen. Am Beispiel der SCOOBOX soll in dieser Arbeit aufgezeigt werden, welche Optimierungen, technischer Art, den Bestand eines Softwareentwicklungsprojektes für die nächsten Jahre sichern können Zielsetzung Das Ziel dieser Arbeit ist es, Technologien, Prozesse und Tools zu finden, mit denen Softwareentwicklungsprozesse optimiert werden können. Der Schwerpunkt ist die Verbesserung der Abwärtskompatibilität. Die SCOOBOX wurde in der Vergangenheit projektorientiert und mit den in der Agentur etablierten Prozessen entwickelt. Es sollen praktische Lösungen zur Verbesserung erarbeitet werden. Nach folgenden Kriterien soll beurteilt werden, welche Maßnahmen ergriffen werden sollen: Nutzen Initialaufwand laufende Aufwände Einsetzbarkeit in anderen Teams Anschließend sind die Lösungen in kurzfristige und langfristige Ziele einzuteilen, von denen ausgewählte Maßnahmen umgesetzt werden. Aufgrund der zeitlichen Begrenzung 10

10 bei der Erstellung dieser Arbeit ist es nicht möglich, die Auswirkungen der praktischen Umsetzungen auf die Abwärtskompatibilität zu betrachten. Nach dem Guide to the Software Engineering Body of Knowledge wird die Softwaretechnik in Teilbereiche untergliedert (siehe Abbildung 1). Software Requirements (Anforderungsanalyse) Software Design (Softwareentwurf) Software Construction (Programmierung) Software Testing (Softwaretests) Softwaretechnik Software Maintenance (Softwarewartung und -evolution) Software Configuration Management Software Engineering Management Software Engineering Process (Vorgehensmodelle) Software Quality (Software Qualität) Abbildung 1: Einteilung der Softwaretechnik [5] In der Arbeit werden alle diese Bereiche, mit Ausnahme der Software Requirements untersucht Vorgehen Zunächst muss analysiert werden, welche Probleme bei einer Systemaktualisierung der SCOOBOX berücksichtigt werden müssen. Dabei kann auf Erfahrungen von Mitarbeitern aus Projekten und eigene Recherchen zurückgegriffen werden. Es ist eine Literaturrecherche zum Thema Softwaretechnik mit dem Fokus agile Softwareentwicklung und Kompatibilität notwendig. Vor diesem Hintergrund soll eine umfassende Übersicht über aktuelle Technologien bezüglich des Themas erstellt werden. 11

11 Entsprechend der Zielsetzung der Arbeit sind Lösungen zu erarbeiten. Kurzfristig umsetzbare Konzepte sollen in der laufenden Entwicklung angewendet werden. Nicht automatisierbare Prozesse werden im Team etabliert, während automatisierbare Prozesse installiert und eingerichtet werden. Abschließend sind die Resultate bezüglich ihres Aufwandes und Potenziales zu bewerten Analyse der Problemstellung Wie in Gesprächen mit Mitarbeitern festgestellt wurde, gibt es beim Entwicklungsprozess der SCOOBOX vielschichtige Ansätze zur Verbesserung der Abwärtskompatibilität. In den folgenden Abschnitten werden diese beschrieben Entwicklungsmodell Im SCOOBOX Entwicklungsprozess werden einige Elemente der agilen Entwicklung angewendet, welche vorwiegend durch das Scrum Modell beschrieben werden. Dieses Modell wird im Abschnitt näher beschrieben. Die Kundenprojekt-orientierten Teams im Unternehmen wenden das iterative Modell an, das im Abschnitt beschrieben wird. Abbildung 2: Anteile bei der Softwareentwicklung 12

12 Nach einer Umfrage von 2012 (siehe Abbildung 2) des Unternehmens SoftServer werden genau diese zwei Methoden überwiegend eingesetzt. Gegebenenfalls sind andere Vorgehensmodelle für die Anforderungen bei dotsource effektiver oder es ist sinnvoll einzelne Methoden (best practices) zu übernehmen oder zu kombinieren Prozesse In Gesprächen mit Mitarbeitern wurde festgestellt, dass es im Entwicklungsprozess der SCOOBOX zu wenig Minor Releases gibt. Das führt dazu, dass Kundenprojekte in der Regel nicht auf einer definierten Version SCOOBOX basieren. Bei Start eines Kundenprojektes wird die jeweils aktuelle Revision des Software Repositories verwendet. Das erschwert die Aktualisierung, weil keine standardisierten, wiederholbaren Prozesse etabliert werden können. Ein Ziel ist es deshalb, Prozesse zu etablieren, die häufigere Releases ermöglichen. Ein weiterer Komplex, der in dieser Arbeit betrachtet wird, ist Continuous Integration (CI) Bei dotsource gibt es bereits etablierte CI Prozesse, die mit dem Werkzeug Jenkins realisiert sind. Jenkins führt die Integration automatisch einmal täglich (Nightly Build) durch. Es wäre wünschenswert, die Integration häufiger durchzuführen, um den Entwicklern ein schnelleres Feedback zu liefern. Dafür ist es notwendig, einen möglichst schnellen Build-Prozess zu realisieren. Bislang wird ein modifiziertes Intershop Build-Skript verwendet, für das es kleinere Abwandlungen zwischen den Java-Teams gibt. Die Softwarequalität kann mit automatischen Tests und statischer Code Analyse optimiert werden. Gegenwärtig gibt es keine automatischen Tests im SCOOBOX Projekt. Die statische Codeanalyse wird durch das Werkzeug Sonar durchgeführt, welches durch das Jenkins System gestartet wird. Sonar prüft Java Dateien mit den Plug-ins Findbugs und PMD. Die statische Codeanalyse wird bei der SCOOBOX Entwicklung bislang ausschließlich auf Java Dateien angewendet. Bei einer SCOOBOX Aktualisierung treten Probleme erfahrungsgemäß aber insbesondere bei den Dateien auf, die nicht durch Sonar analysiert werden. Das sind vorwiegend ISML- und XML-Dateien. Beispielsweise sind einige ISML-Dateien sehr groß, was dazu führt, dass bei einer Aktualisierung sehr viel Code auf Änderungen untersucht werden muss. Das trifft insbesondere dann zu, wenn in einem Kundenprojekt die SCOOBOX Funktionen stark modifiziert wurden. Ein weiteres Problem ist, dass die Verletzungen der Sonar Regeln nur in der Weboberfläche und in der Entwicklungsumgebung angezeigt werden. So müssen Entwickler häufig darauf hingewiesen werden, dass sie ihre Sonar Verletzungen berichtigen sollen. Die Einführung eines verbesserten Feedback-Prozesses ist deshalb 13

13 erforderlich. Zusätzlich erschweren unterschiedliche Regelsets zwischen den Teams ein einheitliches Verständnis. Es kommt in der laufenden Entwicklung immer wieder vor, dass sich Schnittstellen ändern. Veraltete Schnittstellen sollten beibehalten werden und als deprecated gekennzeichnet werden, um eine Abwärtskompatibilität der Standardsoftware zu gewährleisten. Es wäre positiv, wenn die Entwickler automatisch auf solche Fehler aufmerksam gemacht werden Architektur Die SCOOBOX ist auf Basis ihrer Features in Module eingeteilt (z.b. Messages). Ein Modul ist wiederum in mehrere Untermodule, sogenannte Cartridges zerlegt (siehe Abbildung 3). SCOOBOX Messages Album Core Storefront Backoffice Core Storefront Backoffice Abbildung 3: SCOOBOX Architektur (Ausschnitt) Für Demonstrationszwecke wurde der SCOOBOX Demoshop Outbacker erstellt. Dieser verursacht erfahrungsgemäß Probleme bei der Aktualisierung der SCOOBOX. Die Ursache ist die unzureichende Abgrenzung von Outbacker Komponenten zur SCOOBOX Basisfunktionalität. Der Outbacker Demoshop enthält zwar ebenfalls eigene Cartridges, doch hat es sich so entwickelt, dass Outbacker Inhalte in anderen Cartridges vorhanden sind. Ein weiteres Architekturproblem ist die Datenbankentwicklung im SCOOBOX Projekt. Während der Entwicklung der SCOOBOX werden regelmäßig Änderungen an den Tabellen der Oracle-Datenbank vorgenommen. Bei einer Aktualisierung der SCOOBOX Applikation entstehen Inkompatibilitäten mit der Datenbank. Aufgrund des Wertes der Bestandsdaten ist eine Neuinitialisierung der Datenbank nicht möglich. Stattdessen müssen die Daten in das neue System überführt werden. Es dürfen dabei keine Daten verloren gehen oder beschädigt werden und der Online-Shop muss anschließend 14

14 ordnungsgemäß ausgeführt werden. Das ist aktuell nur mit hohem manuellem Aufwand möglich. 15

15 2. Stand der Forschung und Technik In diesem Kapitel wird der Stand der Forschung und Technik in Bezug zur Zielstellung dieser Arbeit dargestellt. Im ersten Teil werden Entwicklungsmodelle, im zweiten Teil Prozesse und im dritten Teil auf die Architektur bezogene Maßnahmen beschrieben Entwicklungsmodelle Die klassischen Entwicklungsmodelle werden in der reinen Softwareentwicklung allgemein immer weniger angewendet (siehe Abbildung 2). Im Bereich des E-Commerce ist es besonders wichtig, auf veränderte Anforderungen, schnell reagieren zu können. Aufgrund dieser Besonderheit werden in diesem Abschnitt überwiegend agile Methoden und Modelle beschrieben Iteratives Modell Das iterative Vorgehensmodell wird oft als Zwischenstadium beim Übergang zu einem agilen Vorgehensmodell benutzt. Oft wird es als Miniwasserfall bezeichnet. [6] Es beinhaltet die gleichen Phasen wie das klassische Wasserfallmodell: [7] (S.23) Anforderungsanalyse Systemdesign Programmierung/Modultest Integration/Systemtest Auslieferung Im Gegensatz zum Wasserfallmodel wiederholen sich die Phasen in relativ kurzen Zeitabständen. Dadurch verringern sich ökonomische Risiken, ohne dass eine große Umstellung notwendig ist. Durch die häufige Wiederholung werden Probleme schneller sichtbar und Anforderung und Planung können schneller angepasst werden Agile Softwareentwicklung Die agilen Softwareentwicklungsmodelle und Prinzipien entstanden etwa um das Jahr 2000 und werden heute zunehmend eingesetzt. Im Jahr 2001 wurden Werte und Prinzipien der agilen Entwicklung im sogenannten Agilen Manifest festgeschrieben: [7] (S23, 24) Individuen und Interaktionen mehr als Prozesse und Werkzeuge Funktionierende Software mehr als umfassende Dokumentation 16

16 Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung Reagieren auf Veränderung mehr als das Befolgen eines Plans. [8] Basierend auf diesen Werten wurden folgende Prinzipien festgelegt (Auszug): [9] Zufriedenstellen der Kunden durch schnelles Ausliefern funktionierende Software möglichst häufig ausliefern Änderungen an den Anforderungen immer begrüßen zukunftsgerichtete Entwicklung, konstantes Entwicklungstempo tägliche Kommunikation der Programmierer mit den fachlichen Experten wichtigstes Fortschrittsmaß ist funktionierende Software persönliche Kommunikation ist zu bevorzugen Motivation der Projektbeteiligten anhaltende Aufmerksamkeit für technische Erstklassigkeit und gutes Design selbst organisierende Teams Der agile Ansatz ermöglicht es Entwicklerteams, schneller auf veränderte Anforderungen zu reagieren und verringert die Risiken. Die Qualität des Software-Designs und die Kommunikation im Team werden verbessert. Der Kunde bekommt genau das Produkt, welches ihm in seinem Geschäftsumfeld den größten Nutzen bringt. Die Anwendung der agilen Prinzipien wirkt sich aber auch positiv auf die Entwicklungsgeschwindigkeit und Softwarequalität aus. [10] (S.13) Es gibt aber auch Kritiker des agilen Vorgehens. Einer davon ist Mike Gualtieri. Er vertritt die These, dass es falsch ist, die Funktion der Software als primäres Fortschrittsmaß festzulegen. Er behauptet, dass es schlecht ist, wenn Programmierer von ihrer eigentlichen Aufgabe, dem Programmieren zu sehr abgelenkt werden: Software developers want to be measured on what they know code instead of what they don t know: the domain, business requirements, and the user. Zu dem agilen Prinzip, der engen Kommunikation zwischen Entwickler und Kunden schreibt er: Developers would much rather stick with what they know The absurd Agile solution to getting the requirements right is to meet with the business every day. [11] Basierend auf den Werten und Prinzipien entstanden zahlreiche Vorgehensmodelle, die vor allem Praktiken der Programmierung und das Projekt Management betreffen (best practices). Die drei typischen agilen Vorgehensmodelle Scrum, Extreme Programming und Kanban werden in den folgenden Abschnitten vorgestellt. 17

17 Scrum Scrum ist ein Modell, welches ausschließlich den Projektablauf beschreibt. Scrum gibt keinerlei Richtlinien zur konkreten Softwareentwicklung vor. [12] Scrum definiert drei Rollen, den Product Owner, den ScrumMaster und das Team (siehe Abbildung 4). Der Product Owner vertritt den Kunden. Er formuliert Anforderungen und priorisiert sie. Der Scrum Master ist für den reibungslosen Ablauf des Projektes verantwortlich, ist selbst aber kein Mitglied des Teams. [13] (S.18) Abbildung 4 Scrum Zusammenfassung [14] Die Anforderungen für das Produkt werden im Product-Backlog festgehalten. Für feststehende Zeiträume, sogenannte Sprints, wird gemeinsam eine Planung durchgeführt. Das heißt, es werden Elemente des Product-Backlog in das Sprint-Backlog übertragen. Am Ende eines Sprints werden die Ergebnisse dem Product Owner vorgestellt. Innerhalb eines laufenden Sprints hat dieser keinen Einfluss auf die Entwicklung. [13] (S. 93) Ein wichtiges Hilfsmittel, mit dem die Kommunikation im Team verbessert werden soll, sind kurze tägliche Treffen, welche als Daily Scrum bezeichnet werden. Zusätzlich werden einmal pro Sprint so genannte Retrospectives im Entwicklerkreis durchgeführt. Sie werden genutzt, um den Entwicklungsprozess kontinuierlich zu analysieren und zu verbessern. [15] 18

18 Scrum allein gestellt ist kein agiler Entwicklungsprozess. Die Agilität wird erst erreicht, wenn zusätzlich die Prinzipien des Agilen Manifests berücksichtigt werden. [16] Extreme Programming Xtreme Programming (XP) ist eine Sammlung von Methoden, die darauf ausgerichtet sind, Aufwände und Risiken gut einschätzen zu können. Im Gegensatz zu Scrum werden neben der Planung zusätzlich Prozesse vorgegeben, die die Entwicklung betreffen. Die markanteste Eigenschaft von XP ist eine stark eingeschränkte Anfangsplanung, die agile Vorgehensweisen dadurch unterstützt, dass mit relativ geringem Aufwand Änderungen durchgeführt werden können. Das gibt Entwicklern und Kunden die Möglichkeit, während der Entwicklung dazugewonnene Erkenntnisse in das Projekt einzubeziehen. Ein weiterer Effekt ist, dass früh erkannt werden kann, wenn die Umsetzung bestimmter Ziele zu aufwändig oder nicht durchführbar sind. [17] Das Team ist komplett selbstorganisiert. Es erstellt Aufwandsschätzungen und plant die Iterationen selbst. Die User Storys für das Endprodukt und die Liefertermine werden aber durch den Kunden bestimmt. [10] (S. 16) Eine Methode des XP ist die Paarprogrammierung. Sie verteilt das Wissen innerhalb des Teams. So wird die Codequalität verbessert, was die Aufwände für Wartung und Weiterentwicklung senkt. Das kann sich langfristig positiv auf die Gesamtkosten auswirken. [18] Auch Code Reviews und Refactorings sollten regelmäßig durchgeführt werden. [17] Um die Geschwindigkeit der Entwicklung konstant hoch zu halten, sollte immer ein möglichst einfaches Design (Continuous/Evolutionary Design) gewählt werden, mit dem die aktuelle Aufgabe gerade so erfüllt wird. Es sollten keine Annahmen über zukünftige Anforderungen gemacht werden, weil diese sich laufend ändern können. Dieses Vorgehen steht in direktem Zusammenhang mit der kurzfristigen Planung. Die Software sollte so oft wie möglich ausgeliefert werden (Small Releases). Das gibt dem Kunden die Möglichkeit, regelmäßig Produktentwicklung zu überprüfen und gegebenenfalls Änderungswünsche einzubringen. Test Driven Development (TDD) und Continuous Integration sind weitere Methoden von XP, mit denen die Qualität sichergestellt werden soll. TDD bedeutet, dass die Entwickler parallel zur Entwicklung selbst Unit und Akzeptanz Tests schreiben. Akzeptanz Tests überprüfen die User Storys und Unit Tests überprüfen die Java Ebene (Klassen). Die Tests werden automatisch, vor dem Check-in von Programmcode, durchgeführt. [17] Continuous Integration wird im Absatz beschrieben. 19

19 Kanban Das Kanban Vorgehensmodell entstand auf Basis des gleichnamigen Prozesses des Unternehmens Toyota Motor Corporation. Das Ziel von Kanban ist es, die Zeit, für die Entwicklung eines einzelnen Features zu verringern. Es gibt keine festgelegten Entwicklungsphasen oder Zeiten. Die Features der Software werden in MMF (Minimum Marketable Features) eingeteilt. Jedes MMF enthält eine Reihe von Aufgaben (Tasks). Es wird gleichzeitig immer nur an einem MMF gearbeitet. Die restlichen MMFs sind in einer Warteschlange und dürfen erst begonnen werden, wenn das Aktuelle abgeschlossen ist. Nur in Ausnahmefällen kann auch kurzzeitig an einem anderen MMF gearbeitet werden (Urgent Slot). Die Reihenfolge in dieser Warteschlange kann jederzeit durch das Projektmanagement verändert werden. Die Visualisierung erfolgt auf dem sogenannten Kanban Board. Das Board kann als Entwicklungswerkzeug oder auch als Tafel realisiert werden (siehe Abbildung 5). Bei Anwendung von Kanban entsteht ein fließender Entwicklungsprozess bei minimaler Ablenkung von außen. [19] Abbildung 5: Beispielhafter Aufbau eines Kanban Boards Continuous Delivery Eine der neueren Softwareentwicklungsmethoden ist Continuous Delivery (CD). Die Ursache für ihre Entwicklung ist der Wunsch, regelmäßig und in kurzen Abständen Releases erstellen zu können. Das hat vor allem wirtschaftliche Vorteile. Man kann nach und nach einzelne Features verkaufen. Dadurch lassen sich Projekte leichter finanzieren. 20

20 Die Release Zyklen können mit Hilfe von CD auf wenige Wochen oder sogar Tage verkürzt werden. Um das zu ermöglichen, wird der gesamte Entwicklungsprozess stark automatisiert und einige neue Methoden eingeführt. Abbildung 6 Beispiel einer Deployment Pipeline [20] (S. 4) Der Kern von CD ist die sogenannte Deployment Pipeline. Diese kann bei jedem Projekt etwas anders gestaltet werden. Der allgemeine Aufbau ist in Abbildung 6 dargestellt. Die Prozesse sind chronologisch vom Commit bis zum Release angeordnet. Die Pipeline läuft soweit wie möglich automatisch ab. Im CD-Modell sind vor allem die folgenden Maßnahmen und Prozesse wichtig: [21] Verstecken von unfertigen Features (Feature Toggles) Continuous Integration Automatisierte Tests Automatisiertes Deployment schnelles Feedback und Einbeziehung aller in der Firma beteiligten Personen in den Feedback-Prozess Es gibt eine Vielzahl an Umsetzungsvarianten von CD, was auf die unterschiedlichen Anforderungen der Unternehmen zurückzuführen ist. Ein Beispiel ist das Open Source Projekt: OpenDelivery. Dort werden ausschließlich Open Source Tools genutzt. Für eine bessere Skalierbarkeit laufen alle automatischen Prozesse innerhalb einer Cloud Infrastruktur ab. [22] 2.2. Prozesse Es gibt bei der Softwareentwicklung vielschichtige Prozesse mit Potenzial für Verbesserung. In diesem Abschnitt wird eine Übersicht über diese angegeben Versionierung und Release Management Alle Dateien, die für die Ausführung und das Testen der Anwendung notwendig sind, sollten in einem Versionskontroll-System erfasst werden. Dazu gehören zum Beispiel. Build-Skripte sowie Bibliotheksdateien. Es ist darüber hinaus empfehlenswert, alle anderen, das Projekt betreffenden Dateien wie Dokumentation in das Versionsverwaltungssystem aufzunehmen. [20] (S. 33) 21

21 In dem folgenden Abschnitt werden die drei am häufigsten verwendeten Typen der Versionsverwaltungssysteme vorgestellt Zentrale Versionsverwaltung Die zentrale Versionsverwaltung wurde mit CVS bereits Anfang der 90er Jahre eingeführt. CVS wurde ab dem Jahr 2000 weitestgehend durch Subversion (SVN) abgelöst, das bis heute eine sehr große Verbreitung aufweist. [23] (S.20,21) Die Daten und ihre Geschichte werden auf einem einzelnen Server in einem sogenannten Repository gespeichert. Jedem Entwickler ist es möglich mit einem Client System auf die Dienste des SVN Servers zuzugreifen. Ein zentrales Konzept in Versionsverwaltungssystemen ist das sogenannte Branching. Ein Branch ist ein eigener Entwicklungszweig, der von anderen Programmierern nicht beeinflusst werden kann. Wenn der Inhalt eines Branches wieder dem Hauptentwicklungszweig zugeführt werden soll, ist es notwendig die einzelnen Dateien zusammenzuführen (Merging). Das kann problematisch sein, wenn der Umfang der Änderungen groß ist und keine Automatik durch die Entwicklungsumgebung zur Verfügung steht. Es haben sich mehrere Strategien für die Erstellung von Branches entwickelt: [20] (S ) Develop on Mainline Branching und merging o Branch for Release o Branch by Feature o Branch by Team Develop on Mainline bedeutet, dass alle Entwickler auf der gleichen Codebasis arbeiten. Es werden keine Branches erstellt. Das begünstigt den Continuous Integration Prozess, weil nur ein Entwicklungszweig getestet werden muss. Die Problematik von Branching und Merging kann durch die Stream Basierte- und die verteilte Versionsverwaltung verringert werden. Diese Systeme werden in den nächsten Abschnitten beschrieben Stream basierte Versionsverwaltung Die Stream basierten Versionsverwaltungssysteme besitzen ebenfalls eine zentrale Architektur. Für Branches wird der Begriff des Streams eingeführt. Im Gegensatz zu Branches werden Streams nicht wieder zusammengeführt (kein Merging). Stattdessen können die Änderungen eines Streams für andere Streams vorgeschlagen werden. Für jeden Stream gibt es einen verantwortlichen Entwickler, der über Kompetenz im 22

22 Gesamtsystem verfügt und über die Annahme von Änderungen entscheidet. Die Argumente für bzw. gegen diese Art der Versionskontrolle sind in Tabelle 1 zusammengefasst. [20] (S.400) Vorteile Kapselung der Entwicklung wie bei der zentralen Versionsverwaltung weniger gegenseitige Beeinflussung der Entwickler Merging vereinfacht Nachteile verschlechtert Continuous Integration genauso wie Branching und Merging jeder Stream muss stabil gehalten werden Stream Owner geringe Auswahl an Werkzeugen (alle kommerziell) Tabelle 1: Vor- und Nachteile: Stream Based Version Control Die wichtigsten Werkzeuge dieser Kategorie sind: AccuRev (kommerziell) ClearCase (kommerziell) Perforce (kommerziell) Verteilte Versionsverwaltung Neben den zentralen- und den Stream basierten Versionsverwaltungssystemen gibt es die verteilten Versionsverwaltungssysteme. Sie haben eine grundlegend andere Funktionsweise. Jeder Nutzer hat ein eigenes lokales Repository. Er kann darauf genauso zugreifen wie auf ein zentrales Repository. Die Änderungen des eigenen Repositories werden durch spezielle Synchronisationsbefehle an die Repositories anderer Entwickler gesendet. Diese können wiederum entscheiden, welche Änderungen sie annehmen. Das führt zu einigen Vor- und Nachteilen, die in Tabelle 2 aufgeführt sind. 23

23 Vorteile Nachteile hohe Geschwindigkeit bei allen Operationen (außer Klonen eines Repositories) Schutz vor Datenverlust durch einen Serverausfall (betrifft nur synchronisierte Patches) Möglichkeit ohne Netzwerkverbindung mit der Versionsverwaltung zu arbeiten Nutzung des eigenen Repository für unfertige Code Teile, ohne andere Entwickler zu stören zentraler Ansatz mit CI Server ist auch möglich gute Visualisierung der Verfolgung von Änderungen (Web of Trust) [24] mehr Speicherbedarf auf den Entwicklungsmaschinen Revisionsnummern verlieren Eindeutigkeit Tabelle 2: Vor- und Nachteile: Distributed Version Control [25] Es gibt eine große Anzahl an Werkzeugen für eine verteilte Versionsverwaltung. Die am häufigsten eingesetzten sind: BitKeeper (kommerziell) GIT Mercurial Regelmäßige Integration Regelmäßige Integration oder Continuous Integration (CI) ist das regelmäßige Erstellen (build), Ausführen und Testen einer Software auf einem System, welches einer Produktivumgebung entspricht. Neuer Quell-Code sollte oft und kleinteilig integriert werden. [26] (S.2) Ist eine Integration nicht erfolgreich, sind Fehler dadurch einfach zu lokalisieren. Üblicherweise wird empfohlen, für eine kurze Zeit zu versuchen, den Fehler zu korrigieren. Ist das nicht möglich, muss der Ausgangszustand wiederhergestellt werden (Revert), damit andere Entwickler nicht gestört werden. [20] (S.70) Voraussetzung für die häufige und schnelle Ausführung der Integration ist die vollständige Automatisierung des CI-Prozesses. Die Gesamtdauer sollte weniger als 10 Minuten betragen. [20] (S.60) Bei hoher zeitlicher Optimierung kann die Technik der sogenannten Pretested Commits eingesetzt werden. Das bedeutet, dass das Build System die Integration sofort nach einem Commit durchführt. Nur wenn diese erfolgreich ist, werden die Änderungen in der Versionsverwaltung aufgenommen. Im negativen Fall wird der Entwickler automatisch informiert. 24

24 Es gibt viele Werkzeuge, die dabei helfen, den CI-Prozess zu automatisieren. Einige der bekannteren sind: Bamboo (kommerziell) Cruise Control Go (kommerziell) Hudson/Jenkins Pulse (kommerziell) Team City (kommerziell) Build-Prozess Bei komplexen Softwaresystemen werden in der Regel ebenso komplexe Build-Skripte eingesetzt. Die Skripte sollten genauso wie Programmcode behandelt werden. Das bedeutet, sie sollten in die Versionsverwaltung aufgenommen, kontinuierlich verbessert und getestet werden. Je schneller und zuverlässiger der Build-Prozess abläuft, desto häufiger kann die Integration durchgeführt werden (siehe Absatz 2.2.2). Es gibt mehrere allgemeine Ansätze, den Build-Prozess zu beschleunigen. Drei werden in den folgenden Abschnitten beschrieben. Eine Möglichkeit ist die Durchführung eines sogenannten inkrementellen Build-Prozesses. Hier werden nur die Dateien verarbeitet, die seit dem letzten Build-Prozess nicht verändert wurden. Moderne Build Systeme erkennen selbstständig, welche Quell Dateien neu kompiliert werden müssen, und welche unverändert sind. [20] (S.146) Das setzt nur voraus, dass die Dateien im Ziel Verzeichnis (Target) zuvor nicht gelöscht (Clean) werden. Eine andere Möglichkeit zur Beschleunigung des Build-Prozesses ist dessen Parallelisierung. Der Erfolg dieser Maßnahme hängt maßgeblich von der eingesetzten Hardware ab. Besonders die Geschwindigkeiten des Prozessors und des Dateisystems sind von Bedeutung. Die einfachste Maßnahme zur Beschleunigung des Build-Prozesses ist der Einsatz besonders geeigneter Hardware. Die größte Geschwindigkeit kann durch die Verwendung von modernen Speichermedien (Laufwerke, Arbeitsspeicher) und Prozessoren erreicht werden. Eine weitere Maßnahme ist der Einsatz von RAM Disks. Es sollten jedoch keine wichtigen Daten (z.b. das Source Verzeichnis) auf ihnen abgelegt werden, was ihren Einsatz deutlich einschränkt. [27] 25

25 Automatische Tests Automatische Tests sind ein Mittel die Funktion einer Software fortlaufend sicherzustellen. Sie sollten ebenfalls in den CI-Prozess eingebunden sein. Das bedeutet, dass sie sich auf die Kernfunktionen begrenzen müssen. Zusätzliche automatische Tests müssen gegebenenfalls auf einem weiteren Testsystem in größeren Zeitabständen durchgeführt werden. Welche Art Tests (z.b. Unit Tests, Oberflächen Tests) in welchem Umfang eingesetzt werden, muss für jedes Projekt spezifisch festgelegt werden. Eine spezielle Herangehensweise für die Erstellung von Tests ist das sogenannte Test Driven Development. Die Tests werden noch vor den Softwarefunktionalitäten entwickelt. Dieses Vorgehen stellt sicher, dass das System genau die spezifizierten Funktionen erfüllt. Das ist besonders bei der Anwendung agiler Entwicklungsmethoden hilfreich, weil regelmäßig Änderungen am Gesamtsystem durchgeführt werden. [10] Statische Code Analyse Die Statische Code Analyse hat zwei Ziele: die Vereinheitlichung von Code Styles und die Identifikation von Schwachstellen im Quellcode. Ein einheitlicher Code Style verbessert die Wartbarkeit (engl. maintainability) und Erweiterbarkeit der Software, weil Entwickler den Code besser nachvollziehen können. Die Statische Code Analyse kann Entwickler auch auf Probleme aufmerksam machen, die in Tests nicht zwingend auffallen. Das können zum Beispiel Performance Einbußen oder Sicherheitsprobleme sein. Die statische Code Analyse kann auf viele Programmiersprachen angewendet werden. Entsprechend gibt es sehr viele verschiedene Werkzeuge, die sie realisieren Infrastruktur Automatisierung Ein weiterer Ansatz für die Beschleunigung des Entwicklungsprozesses ist die Automatisierung der Erzeugung der Infrastruktur. Die Infrastruktur ist die Umgebung, in der der Build-Prozess und anschließend die Software selbst ausgeführt wird. [28] Dazu gehören Konfigurationsdateien sowie die Installation von Drittsoftware wie zum Beispiel ein Apache Tomcat Server oder eine Oracle Datenbank. Der große Vorteil dieser Automatisierung ist die Möglichkeit, ein System wiederholt und im identischen Zustand zu erzeugen. [20] (S.291) In der Regel wird die Automatisierung der Infrastruktur zusammen mit Diensten von Cloud Anbietern angewendet. So können beliebig viele Systeme erzeugt werden, auf denen automatische Tests ausgeführt werden können. Bei Open Delivery [22] wird zum Beispiel bei jeder Änderung an einem Teil der 26

26 Software ein neues System in der Amazon EC2 Cloud generiert und anschließend getestet. So bekommen Entwickler ein besonders schnelles Feedback. Momentan verfügbare Werkzeuge für diese Aufgabe sind zum Beispiel: Puppet Julu Chef Pester Crowbar Toft Pallet 2.3. Architektur Die Architektur hat grundlegenden Einfluss auf die Wartbarkeit und Erweiterbarkeit eines Softwaresystems. In den folgenden Absätzen wird zunächst auf Komponenten und deren Wechselwirkungen und anschließend auf die Applikationsentwicklung mit Datenbankabhängigkeit eingegangen Komponenten und Abhängigkeiten Es ist aus mehreren Gründen vorteilhaft große Softwaresysteme in Komponenten mit klar definierten Schnittstellen zu zerlegen. Es verbessert die Wiederverwendbarkeit von Codeteilen und somit die Wartbarkeit. Die Entwicklung im Team ist effizienter, weil sich Aufgaben besser trennen lassen und Komponenten einzeln kompiliert und getestet werden können. In einer Software mit modularem Aufbau können einfach einzelne Teile ausgetauscht werden. Das ist notwendig, weil es in komplexen Softwaresystemen immer Ressourcen mit unterschiedlichen Entwicklungsgeschwindigkeiten und Lebenszyklen gibt. [20] (S.346) In agilen Entwicklungsprozessen ist die Bildung von Komponenten von besonders großer Bedeutung, weil Aufgaben in kleine Arbeitspakte zerlegt werden müssen (siehe Absatz 2.1.2). Durch die Unterteilung der Anwendung in Komponenten entstehen Abhängigkeiten (Dependencies) zwischen diesen. Es ist wichtig sie hinreichend zu dokumentieren, um wiederholbare Prozesse definieren zu können. Neben den internen gibt es externe Abhängigkeiten. Das sind zum Beispiel verwendete Java Bibliotheken. Um externe Abhängigkeiten effektiv verwalten zu können, gibt es zwei Varianten: Aufnahme der Dateien in das Versionsverwaltungssystem Verwendung eines Dependency Management Werkzeugs 27

27 Speziell für Java Projekte gibt es zwei Werkzeuge für diese Aufgabe. In das Build Werkzeug Apache Maven ist bereits eine Dependency Management Funktion integriert. Für Apache Ant Projekte kann Apache Ivy eingesetzt werden. Ein neuer Trend in der Softwareentwicklung könnten die sogenannten Micro Services werden. Micro Services sind kleinste Funktionen, die eine spezifische Aufgabe erfüllen. Im Technology Radar des Software Consultance Unternehmens thoughtworks (Oktober 2012), wurde festgestellt, dass diese Technik getestet werden sollte. [29] Agile Datenbankentwicklung Bei der Anwendung agiler Entwicklungsprozesse und gleichzeitiger Verwendung einer relationalen Datenbank entstehen Konflikte zwischen der Applikation und der Datenbank. Denn die Datenbank enthält oft wertvolle Kundendaten. Sie müssen ohne Verluste in das veränderte Datenbank-Schema überführt werden. Besonders bei der XP Praxis Continuous Design (Abschnitt ) sind Änderungen an der Datenbank in schneller zeitlicher Abfolge üblich. In den folgenden Abschnitten sind vier Ansätze beschrieben, mit denen dieser Konflikt gelöst werden kann Migrationsskripte im Build-Prozess Eine Möglichkeit zur Lösung des Problems sind Migrationsskripte, die in das Build-Skript integriert werden. In der Datenbank wird eine Tabelle angelegt, in der die aktuelle Datenbankversion abgelegt ist. In einer Build Konfigurationsdatei wird gespeichert, welche Datenbankversion für die Applikation benötigt wird. Werden entwicklungsseitig Änderungen an der Datenbank durchführt, wird ein Migrationsskript (roll-up) angelegt, in dem die Änderungen vorgenommen und die ursprünglichen Daten überführt werden. Im Migrationsskript können optional Anweisungen zum rückgängig machen der Änderungen (roll down) angegeben werden. Beim Build werden automatisch genau die Skripte ausgeführt, die notwendig sind, um die Datenbank auf die richtige Version zu überführen. [20] (S.328,329) Die korrekte Funktionsweise der Skripte wird sichergestellt, indem sie im CI-Prozess getestet werden. Es gibt für die verschiedenen Build Systeme einige Werkzeuge, die die Ausführung der Migrationsskripte steuern. Sie ähneln sich in ihrer Funktionsweise sehr stark. 28

28 Refactoring Tool Um die aufwändige Arbeit mit Skripten etwas zu erleichtern, kann ein spezielles Datenbank Refactoring Werkzeug eingesetzt werden. Aktuell gibt es nur wenig Werkzeuge dieser Art. Dazu gehören: Flyway Liquibase MyBatis Es werden Features wie zum Beispiel die Generierung von SQL-Skripten oder das Erstellen von Changelogs angeboten. [30] Die Befehle sind meist auch für Build-Skripte verfügbar. Für Liquibase gibt es ein umfangreiches System für Erweiterungen. [31] Entkopplung der Datenbank von der Anwendung Eine andere Herangehensweise ist es, keine Änderungen an der bestehenden Datenbankstruktur zuzulassen. Stattdessen werden die neuen Strukturen parallel angelegt. Die Applikation muss sowohl mit den alten als auch den neuen Daten umgehen können. [20] (S.333) Dieses Vorgehen kann nur begrenzt angewendet werden, weil die Komplexität der Anwendung mit der Zeit immer weiter zunimmt. Die Entkopplung kann auch durch eine Zwischenschicht wie das sogenannte Object Relational Mapping (ORM) geschehen. ORM ermöglicht es, vereinfacht auf eine relationale Datenbank mit Hilfe einer objektorientierten Programmiersprache zuzugreifen Schemalose Datenbanken In den letzten Jahren haben die nicht-relationalen (schemalosen) Datenbanksysteme an Bedeutung gewonnen. Durch den Einsatz einer schemalosen Datenbank können sich Kompatibilitätsprobleme automatisch verringern, weil sich die Organisation der Datenhaltung in die Applikation verlagert. [32] Eine vielversprechende Zukunftstechnologie ist Polyglot Persistence, welche es erlaubt, mehrere Datenbanktypen gleichzeitig einzusetzen und über ein gemeinsames Interface anzusprechen. [33] Dadurch ergibt sich die Möglichkeit für jede Anforderung das optimale Datenbanksystem zu verwenden, ohne das die Komplexität der Entwicklung in großem Maß erhöht wird. 29

29 3. Konzept und methodisches Vorgehen Mit Hilfe der im Kapitel 2 dargestellten und aus der Literatur bekannten Methoden zur Softwareentwicklung, ergänzt durch die Erfahrungen der Mitarbeiter bei dotsource, wurde ein Konzept für die Umsetzung einiger der beschriebenen Methoden erstellt, welches in diesem Kapitel vorgestellt wird Entwicklungsmodelle Für Unternehmen, die im Geschäftsfeld des E-Commerce tätig sind, ist es von großer Bedeutung, schnell auf veränderte Anforderungen reagieren zu können (siehe Absatz 2.1). Es müssen zum Beispiel neue Features entwickelt oder neue Technologien eingesetzt werden. In der SCOOBOX Entwicklung werden zum Beispiel oft neue Ideen aus dem Bereich Social Commerce getestet. Ein weiterer wichtiger Aspekt ist, dass das SCOOBOX Projekt für die Ausbildung neuer Mitarbeiter genutzt wird. Es ist wichtig, dass diese in kurzer Zeit am Entwicklungsprozess teilnehmen können. Die oben genannten Anforderungen können agile Vorgehensmodelle am besten erfüllen (siehe Absatz 2.1.2). Es ist nicht notwendig ausschließlich ein bestimmtes Modell umzusetzen, weil die Vorgehensmodelle meist nur bestimmte Bereiche des Entwicklungsprozesses beschreiben. Stattdessen besteht die Möglichkeit alle Elemente, die einen bestimmten Nutzen versprechen, in die eigenen Prozesse zu integrieren, Im SCOOBOX Team wurden wesentliche Elemente des Scrum Modells in den Entwicklungsprozess aufgenommen. Es gibt ein Product- und ein Sprint-Backlog, in denen die User Storys verwaltet werden. Die technische Umsetzung ist mit der Projektverwaltungssoftware Projektron BCS [34] realisiert worden. Daily Scrum- sowie Sprintreview Meetings werden regelmäßig durchgeführt. Aufgrund positiver Erfahrungen sollten Verbesserungen auf dieser Basis eingeführt werden. Im folgenden Absatz wird beschrieben, aus welchen Gründen die Planungsprozesse von Kanban und XP keine empfehlenswerten Lösungsansätze für die SCOOBOX Entwicklung liefern. Das Kanban Modell beschreibt (wie auch Scrum) überwiegend das planungsspezifische Vorgehen. Die sequenzielle Bearbeitung der Features (MMF) stellt eine wesentliche Beschränkung des Entwicklungsprozesses dar. Das kann bei bestimmten Projekten zu einer Erhöhung der Entwicklungsgeschwindigkeit führen. Im Fall der SCOOBOX gibt es komplexe Abhängigkeiten zwischen den einzelnen Ressourcen. Bei Einsatz des Kanban-Modells würde es im Team häufige Überschneidungen der Aufgaben geben, was das aufwändige Zusammenführen (Merging) von Dateien bedingt. Die Planungsmethodik von XP ist für das SCOOBOX Projekt ebenfalls ungünstig, weil die Anwendung der 30

30 Methode Continuous Design notwendig ist. Continuous Design ist sehr anspruchsvoll und erfordert deswegen besonders erfahrene Entwickler. Das XP-Vorgehensmodell beschreibt einige praktische Methoden (siehe Tabelle 3), die im SCOOBOX Projekt getestet werden können. Methode Vorteil Zeitrahmen Einführung Paar Programmierung Refactoring/Code Reviews Test Driven Development Kleine Releases Höhere Software Qualität kurzfristig Ausbildung neuer Mitarbeiter Verteilung des Wissens im Team Höhere Software Qualität langfristig Verteilung des Wissens im Team Bessere Stabilität der Software in der langfristig Entwicklung mehr Startpunkte für kurzfristig Migrationsprojekte, wirtschaftlicher Vorteil bei Teilauslieferung Tabelle 3: empfohlene Maßnahmen zm Vorgehen Die Paarprogrammierung kann kurzfristig getestet werden, weil diese auf einzelne Personen und Zeiträume begrenzt werden kann. Refactoring und Code Reviews sind eher langfristig einzuführende Maßnahmen, weil sie viel Zeit der erfahreneren Programmierer im Team beanspruchen. Für eine Einführung von Test Driven Development sind zuvor noch weitere Voraussetzungen zu erfüllen (siehe 3.2.3) Prozesse Versionierung und Release Verwaltung Im Unternehmen wird derzeit das Programm Subversion zur Versionierung und Release Verwaltung eingesetzt. Um die Abwärtskompatibilität sicher zu stellen, müssen regelmäßig Minor Releases erstellt werden, die als Tag in der Versionsverwaltung erzeugt werden. Grundsätzlich kann immer ein Release erscheinen, wenn eine bestimmte Anzahl an User Storys eines Features testbar sind. Das setzt voraus, dass unfertige Funktionen auf einer feinen Ebene versteckt werden können und automatische Tests etabliert sind. Deshalb ist das Erhöhen der Release-Frequenz als langfristiger Prozess zu definieren. 31

31 Heute gibt es weitaus bessere Werkzeuge als das bei dotsource verwendete Subversion. Mit einem Wechsel des Versionsverwaltungswerkzeugs kann der Entwicklungsprozess effektiver gestaltet werden (siehe Absatz 2.2.1). Eine Umstellung aber muss umfassend geplant und organisiert werden, weil sie das gesamte Unternehmen betrifft Build-Prozess Eine hohe Geschwindigkeit der Build-Skripte verbessert die kontinuierliche Integration (siehe Absatz 2.2.3) und unterstützt die Entwickler bei der täglichen Arbeit. Es ist deshalb empfehlenswert, Techniken zu ermitteln, mit denen Verbesserungen durchgeführt werden können. Langfristig kann es sinnvoll sein, einzelne Entwickler für die Optimierung dieser Skripte einzusetzen. Sie können diese Aufgabe auch teamübergreifend wahrnehmen, weil es beim Build-Prozess Überschneidungen gibt Automatische Tests Es ist empfehlenswert, automatische Tests einzuführen, weil dadurch die Stabilität der SCOOBOX Builds verbessert werden kann und die QA-Abteilung entlastet wird. Im geringen Umfang (aufgrund der zeitlichen Anforderung) sollten diese Tests in den Continuous Integration-Prozess eingebunden werden. Durch regelmäßige Integration können Probleme schneller erkannt und behoben werden. Weil erst die automatische Ausführung von Tests entwickelt und erprobt werden muss, ist der Einsatz von automatischen Tests ein langfristiges Ziel Statische Code Analyse Der Einsatz des Analysewerkzeugs Sonar hat die Java-Codequalität bereits maßgeblich verbessert. Aufgrund aktiver Weiterentwicklung und der Verfügbarkeit zahlreicher Schnittstellen und Plug-ins kann Sonar auch weiterhin eingesetzt werden. Ein bestehendes Problem ist, dass ausschließlich Java Code geprüft wird. In einem Intershop Software-System werden neben Java mehrere andere Programmiersprachen verwendet [35]. Es gibt Sonar-Plug-ins für alle gängigen Programmiersprachen. Es sollte deshalb kurzfristig möglich sein, zusätzliche Prüfungen in die Analyse aufzunehmen Infrastruktur Automatisierung Die Automatisierung der Infrastruktur kann einen Beitrag zur Verbesserung des Entwicklungsprozesses leisten (siehe Absatz 2.2.6). Allerdings ist der initiale Aufwand 32

32 sehr hoch und die Vorteile stellen sich erst vollkommen ein, wenn Cloud Computing und Testautomatisierung eingesetzt werden. Gegenwärtig gibt es keine automatischen Tests im SCOOBOX Projekt, sodass zunächst von der Einführung dieser Technologie abgesehen werden muss. Eine Cloud Infrastruktur würde zudem laufende Kosten erzeugen. Dennoch sollten die Entwicklungen auf diesem Gebiet beobachtet werden Architektur Es gibt mehrere Ansätze, die Architektur so zu modifizieren, dass Wartbarkeit und Erweiterbarkeit verbessert werden (siehe Absatz 2.3). Es stehen Intershop-spezifische Technologien zur Verfügung, die sinnvollerweise weitestgehend eingesetzt werden sollten Komponenten und Abhängigkeiten Externe Abhängigkeiten werden in der SCOOBOX Entwicklung innerhalb eines Subversion Repositories gespeichert. Die Verwaltung interner Abhängigkeiten wird durch eine Funktionalität des Intershop Studios realisiert. Mit Intershop Version 7 wurde das Intershop Component Framework eingeführt. Es ist eine Umsetzung einer Technik mit dem Namen Dependency Injection. Die einzelnen Java-Klassen müssen ihre Abhängigkeiten nicht mehr selbst auflösen. Das übernimmt eine zentrale Steuerung zur Laufzeit - das Component Framework. Diese Technologie muss getestet und ihre Auswirkung auf die Abwärtskompatibilität überprüft werden. Aufgrund der umfangreichen Features des Intershop Component Framework ist es momentan nicht notwendig, ein externes Tool einzuführen Agile Datenbankentwicklung Ab dem Release von SCOOBOX 4.1 sollten für Änderungen an der Datenbank Migrationsskripte erstellt werden. In der Abbildung 7 sind zwei Installationen dargestellt, due gleichwertig sein müssen. 33

33 DB-Init 4.1 DB-Init 4.2 DB-Migrate zu 4.2 Abbildung 7: Gegenüberstellung von DB-Init und DB-Migrate Dafür bietet sich das Intershop Tool DBMigrate an. Die technische Umsetzung muss bis zu dem Release der SCOOBOX 4.1 erprobt werden. Es ist notwendig, den Migrationsprozess so zu automatisieren, dass er auch auf den Testsystemen ausgeführt werden kann. 34

34 4. Umsetzung Im Zeitraum der Erstellung der vorliegenden Arbeit konnten folgende Verbesserungen in den Entwicklungsprozess der SCOOBOX eingebracht werden: Überprüfung zusätzlicher Programmiersprachen mit Sonar verbessertes Feedback durch s bei Sonar Verstößen Beschleunigung des Build-Prozesses Einführung von Datenbank Migrationsskripten Vorbereitung für automatische Unit und Oberflächen Tests In diesem Kapitel ist die Umsetzung im Detail beschrieben Statische Codeanalyse Aufgrund der umfangreichen Erweiterbarkeit von Sonar, wurde das bestehende Code Analyse System beibehalten und modifiziert. Der Feedback-Prozess wurde durch Einführung von s erweitert und zusätzliche Analysen sind integriert wurden Violation s Während der Erstellung dieser Arbeit wurde durch einen Mitarbeiter des Unternehmens ein Skript erstellt, welches die Verletzungen der Sonar Regeln und Nutzerdaten ausliest. Die Daten werden im XML-Format über die Sonar Web Service API vom Server geladen. Anschließend werden aus den XML-Dateien mit Hilfe von XSLT (Extensible Stylesheet Language Transformation) HTML Dokumente erstellt. Diese können als verschickt werden. Die jeweiligen Empfänger werden mit Hilfe des SCM Activity Sonar Plug-ins ermittelt. In dieser Umsetzung wurden allerdings alle Regelverletzungen gleichbehandelt. Es wurden jeden Tag s an alle Personen verschickt, die jemals eine Sonar Verletzung verursacht haben. Im Rahmen dieser Arbeit wurde das XSLT-Skript so angepasst, dass alle Regelverstöße, die älter als eine Woche sind, herausgefiltert werden. Zur Selektion der Regelverstöße wurden die difference() und die date-time() Funktionen von verwendet (siehe Listing 1). Dazu musste die Datumsformatierung, die die Web Service API liefert, an die der Funktion angepasst werden. Aus dem Ergebnis von difference() kann die Anzahl der Tage (days) entnommen werden. Diese Variable wird für jeden Violation Knoten der XML-Datei erzeugt. Mit einer einfachen If-Anweisung können Einträge gefiltert werden, die ein bestimmtes Alter überschreiten. 35

35 Die nachfolgende Übersicht zeigt einen vereinfachten Ausschnitt der XSL- Datei: <!-- difference liefert z.b.p2dt6h19m6s Die Tage stehen immer zwischen P und D <xsl:variable name="duration" select="ex:difference(concat(substring(createdat,1,22), ':', substring(createdat,23,2) ), ex:date-time())"/> <xsl:variable name="days" select="substring-after(substring-before($duration,'d'),'p')"/> <xsl:if test="$days < 7"> </xsl:if> Listing 1: Anpassung XSL Datei für gezielten Versand Multilingual Prüfung Die Sonar Analyse wird im SCOOBOX Projekt über ein Ant-Skript gestartet. Um in der Sonar Oberfläche eine übersichtliche Struktur zu definieren, wird durch das Skript für jedes Cartridge ein eigenes Modul erstellt. Sonar kann in jedem Modul nur eine Sprache prüfen. [35] Deshalb muss für jedes Cartridge jeweils ein Modul für jede zu prüfende Sprache erstellt werden. Im Rahmen dieser Arbeit wurde das Ant-Skript um die Prüfung von XML, ISML und JavaScript Dateien erweitert. Weitere Sprachen lassen sich bei Bedarf integrieren. Für JavaScript und ISML Dateien kann weitestgehend auf Standard Regelsets zurückgegriffen werden. Dafür wurde eine Bewertung durchgeführt (siehe Anhang: Datenträger Verzeichnis S.51), auf deren Grundlage Regeln eingeführt werden können. XML Prüfungen sollten zunächst für Intershop Pipelines eingeführt werden. Hierfür wurden neue Regeln mit Hilfe von XPath Ausdrücken erstellt (siehe Tabelle 4). Im Anhang auf Seite 53 ist beispielhaft eine Pipeline dargestellt, die gegen die Regeln StartnodeCount und StartnodePosition verstößt. 36

36 Name StartnodeCount ProcessPipelineNotPrivate ProcessPipelineNotStrict StartnodePosition PipelineToLong Beschreibung In der Pipeline gibt es mehr als 12 Startknoten. Pipelines mit einer großen Anzahl von Startknoten erschweren die Weiterentwicklung aufgrund ihrer Komplexität. Startknoten von Prozess-Pipelines dürfen nicht öffentlich (public) sein, weil in ihnen sensible Business Logik ausgeführt wird. Startknoten von Process-Pipelines sollten Strict sein. Damit wird erzwungen, dass genau die Parameter übergeben werden, die benötigt werden und keine anderen. Startknoten sollten in den ersten Zeilen einer Pipeline positioniert werden, weil damit die Übersichtlichkeit erhöht wird. Lange Pipelines sind sehr komplex, was die Weiterentwicklung, erschwert. Tabelle 4 Erstellte Pipeline Regeln (Ausschnitt) Durch Einhaltung dieser Regeln kann die Abwärtskompatibilität verbessert und die Migrationsaufwände verringert werden. Das wird erreicht durch: Vermeidung von hoher Komplexität Zwang zu definierten Schnittstellen von Startknoten 4.2. Build-Prozess Die in den Intershop Projekten eingesetzten Apache Ant Build-Skripte sind Intershop Standard Skripte. Jede Cartridge enthält eine build.xml Datei, über die der Clean- und der Build-Prozess gestartet werden. Das Skript der Datei build.xml ruft weitere Ant-Skripte (Subfunktionen) auf. Es gibt etwa 50 solcher Dateien, wovon die Mehrzahl mehrere 100 Zeilen Code umfasst. Für die Ausführung eines kompletten SCOOBOX-Builds (alle Cartridges) gibt es eine weitere Datei mit dem Namen build_all.xml. Das Enthaltene Ant-Skript ruft nacheinander die einzelnen build.xml Skripte in den Cartridges auf. Nachfolgend werden die Maßnahmen beschrieben, mit denen der Build-Prozess beschleunigt wurde. 37

37 Einsatz einer Ram Disk Eine Ramdisk stellt einen Teil des Arbeitsspeichers als Dateisystem zur Verfügung. Aufgrund der hohen Zugriffsgeschwindigkeit ist zu erwarten, dass der Build-Prozess deutlich beschleunigt wird. Dafür wurde im Windows Hostbetriebssystem mithilfe der Software AMD RADEON RAMDisk ein Laufwerk erstellt. Auf diesem Laufwerk wurde anschließend eine virtuelle Festplatte eingerichtet. Diese wurde in die Entwicklungs-VM (virtuelle Maschine) eingebunden. Anschließend wurden das Quell- und Zielverzeichnis auf dieses Laufwerk verschoben. Bei einer Gesamtzeit (komplettes Clean und Build) von etwa 7 Minuten verringerte sich die Zeit durch diese Maßnahme nur um wenige Sekunden. In einem weiteren Versuch wurde die gesamte virtuelle Maschine auf eine Festplatte verschoben. Die Differenz zur Ausführung auf einer SSD betrug nur ca. 15 Sekunden. Daraus lässt sich ableiten, dass das Dateisystem bei einem Standard Build-Prozess keinen signifikanten Einfluss auf die benötigte Zeit hat Einsatz alternativer Task Aufrufe Nach weiterer Recherche [36] konnte festgestellt werden, dass Performanceeinbußen durch das Aufrufen anderer Targets durch ant oder antcall entstehen. Bei jedem dieser Aufrufe erstellt Ant ein neues Build-Environment. Dabei werden sämtliche Daten (Properties) in einen neuen Speicherbereich kopiert. Um das zu verhindern, können die Targets durch Ant Makros ersetzt werden. Eine zweite Variante ist dadurch gegeben, den antcall Aufruf durch einen runtarget (Ant Library: ant-contrib) Befehl zu ersetzen. Aufgrund der Vielzahl solcher Aufrufe in den Skripten wurde er nur beispielhaft implementiert. Jede Ersetzung verringerte die Zeit im Schnitt nur um wenige hundertstel Sekunden. In vielen Fällen ist eine Ersetzung zudem sehr aufwändig. Die Targets definieren einen sogenannten Dependencies-Tag. Darin sind andere Targets enthalten, die vor dem Aufruf automatisch ausgeführt werden. Dadurch entstehen komplexe Abhängigkeiten. In Abbildung 8 sind diese beispielhaft für die build.xml dargestellt. Externe Aufrufe anderer Dateien sind in der Darstellung ausgeblendet. Bei Verwendung des runturget Aufrufs oder Makros müssen Abhängigkeiten manuell aufgelöst werden, weil dabei der Dependencies-Tag nicht verfügbar ist bzw. nicht ausgewertet wird. Das heißt, es muss manuell geprüft werden, welche Targets bzw. Makros bereits ausgeführt wurden. Anschließend müssen entsprechende Aufrufe durchgeführt werden. Es besteht die Möglichkeit, dass die Intershop Build-Skripte bei einem Intershop Update verändert werden. Deshalb sind umfangreiche Modifikationen als problematisch anzusehen und wurden nur in kleinem Maß im Rahmen der Parallelisierung des Build-Prozesses eingesetzt (siehe folgender Absatz). 38

38 Abbildung 8: Schematische Darstellung der Abhängigkeiten in der build.xml (erstellt mit yworks Ant Explorer) Parallelisierung des Build-Prozesses Bei dieser Maßnahme wurde mit dem Clean-Prozess begonnen, weil dabei keine Abhängigkeiten beachtet werden müssen. Zunächst wurde die Datei clean.xml angepasst (siehe Listing 2). <target name="s.c.clean"> <runtarget target= "s.c.clean.init"/> <parallel threadcount="15"> <runtarget target= "s.c.clean.general.share"/> <runtarget target= "s.c.clean.general.cartridge.static"/> <runtarget target= "s.c.clean.general.cartridge.urlrewrite"/> <runtarget target= "s.c.clean.general.cartridge.templates"/> <runtarget target= "s.c.clean.general.cartridge.templates.default"/> <runtarget target= "s.c.clean.general.cartridge.pagelets"/> <runtarget target= "s.c.clean.general.cartridge.pipelines"/> <runtarget target= "s.c.clean.general.cartridge.queries"/> <runtarget target= "s.c.clean.general.cartridge.webforms"/> <runtarget target= "s.c.clean.general.cartridge.localizations"/> <runtarget target= "s.c.clean.general.cartridge.components"/> <runtarget target= "s.c.clean.general.cartridge.webservices"/> <runtarget target= "s.c.clean.general.cartridge.model"/> <runtarget target= "s.c.clean.general.cartridge.edl"/> <runtarget target= "s.c.clean.component"/> </parallel> </target> Listing 2: Ausschnitt(vereinfacht) Clean.xml parallelisiert Die Targets der clean.xml werden während des Build-Prozesses auf jedes einzelne Cartridge angewendet. Die große Anzahl der Threads (threadcount) ist nicht von Nachteil, weil der Zugriff auf das Dateisystem nicht der limitierende Faktor ist (siehe 4.2.1) und auch der Prozessor wenig beansprucht wird. Diese Veränderung verkürzte die Zeit für ein komplettes Clean von ca. 2 Minuten auf ca. 30s. Anschlließend wurde das clean_all Target der build_all.xml so bearbeitet (siehe Listing 3), dass mehrere Cartridges gleichzeitig abgearbeitet werden. Durch diese Maßnahme reduzierte sich die Laufzeit für ein komplettes Clean auf etwa 5 Sekunden. 39

39 <target name="clean_all" > <for list="${build.cartridgelist}" param="cartridgelist" delimiter=" " > <sequential> <for param="component" delimiter=" " parallel="${build.parallel}" threadcount="${build.parallel.threadcount}"> <sequential> <ant target="clean" /> </sequential> </for> </sequential> </for> </target> Listing 3: Ausschnitt(vereinfacht) Build_all.xml parallelisiert Aufgrund des großen Zeitgewinns wurde versucht, diese Technik auch für das Erstellen (Build) der Release Dateien anzuwenden. Aufgrund komplexer Abhängigkeiten in den Intershop Build-Skripten für einzelne Cartridges beschränkte sich die Umsetzung auf die Datei build_all.xml. Damit der Build-Prozess mehrere SCOOBOX Cartridges gleichzeitig verarbeiten kann, müssen Abhängigkeiten zwischen diesen beachtet werden. Anhand der Struktur, die in Abbildung 9 dargestellt ist, wurden die Cartridges in 7 Gruppen eingeteilt. Bei dieser Untergliederung des Build-Prozesses die wurde eine Zeit von 1 Minute und 40 Sekunden (Ausgangswert: 4:50 ohne clean_all) gemessen. Abbildung 9: Abhängigkeiten SCOOBOX Cartridges, schematisch dargestellt, Stand

40 Um den Aufwand der manuellen Analyse der Abhängigkeiten zu beseitigen, wurde eine Java-Klasse erstellt (siehe Anhang Datenträger Verzeichnis), die die Einteilung in Gruppen automatisch durchführt. Das Ergebnis wird in einer Properties Datei gespeichert. Die Java-Klasse kann innerhalb des Build-Prozesses aufgerufen werden (siehe Listing 4). <target name="setparallelbuildproperties" description="modify for parrallel build groups"> <javac srcdir="${is_source}/../misc/sc_build/build_parallel/src" destdir="${is_source}/../misc/sc_build/bin" includeantruntime="false"/> <java classname="com.dotsource.intershop.build.buildlistcreator" classpath="${is_source}/../misc/sc_build/bin" > <arg value="${is_share}/system/cartridges/cartridgelist.properties"/> <arg value="${is_source}"/> </java> </target> Listing 4: Ausschnitt (vereinfacht) Build_all.xml setparallelbuildproperties Mit einer verschachtelten Schleife können die Einträge ausgelesen, und der parallele Build gestartet werden (siehe Listing 5). <target name="build_all_fast"> <for list="${build.cartridgelist.p.combined}" param="cartridgegroups" delimiter="," > <sequential> <for param="cartridge" delimiter=" " parallel="true" threadcount="15"> <sequential> <ant target="build" /> </sequential> </for> </sequential> </for> </target> Listing 5: Ausschnitt(vereinfacht) Build_all.xml build_all_fast 4.3. Datenbankmigration Für die Durchführung von Datenbank Migrationsaufgaben wurden Intershop Basisfunktionen verwendet. Die Intershop Migration wird ähnlich implementiert wie die Initialisierung. Bei Aufruf des Intershop DB-Migrate Programms werden sequenziell alle Java-Klassen (deren migrate-methode) aufgerufen, die in den migration.properties Dateien definiert sind. Zusätzlich benötigte Daten können gegebenenfalls in Properties Dateien gespeichert werden. Der Intershop Standard enthält bereits einige Basisklassen für generelle Migrationsaufgaben, wie z.b. das Hinzufügen eines Jobs. Für speziellere Anforderungen müssen während der Entwicklung neue Klassen angelegt werden oder SQL-Skripte verwendet werden, die ebenfalls über eine Java-Klasse ausführbar sind. 41

41 Um die Datenbankmigration wiederholbar und sicher durchführen zu können, ist es notwendig, zunächst exakt den Ausgangszustand einer initialisierten Datenbank herzustellen. Ein einfache Ausführung des jeweiligen DBInit-Skripts reicht dafür nicht aus, weil sich während der SCOOBOX Entwicklung gleichzeitig die Intershop Version verändern kann. Der Zustand einer Datenbank kann mit Hilfe eines sogenannten Datenbank Dump gesichert werden. Für die Erstellung des Dumps wurde das Oracle Data Pump Kommandozeilenprogramm verwendet. Entsprechend dem beschriebenen Vorgehen wurde ein Ant-Skript (siehe Anhang Datenträger Verzeichnis) erstellt. Der Ablauf des erstellten Ant Skripts ist in Abbildung 10 dargestellt. Clean Database Import Dump Standard Intershop Migrate SCOOBOX Migrate Abbildung 10: Ablauf des erstellten Migrate Skripts 4.4. Automatische Tests XLT (Xceptance Load Test) Tests werden bei dotsource bereits in Kundenprojekten eingesetzt. Mit XLT können Lasttests durchgeführt werden. Diese Lasttests bestehen aus der parallelen Ausführung von funktionalen Tests. XLT Tests können alternativ auch seriell ausgeführt werden. Das ist ausreichend für die SCOOBOX Entwicklung, weil Lasttests innerhalb der Kundenprojekte durchgeführt werden können. Der Vorteil daran ist, dass für die SCOOBOX die kostenfreie Basislizenz verwendet werden kann. Zum aktuellen Zeitpunkt gibt es noch keine XLT-Tests für die SCOOBOX. Deshalb wurden die Möglichkeiten der automatisierten Testausführung am Veritas Projekt ausprobiert. Auf der XLT-Website wird ein Beispielprojekt [37] für die Verwendung von Ant-Skripten angeboten. Damit können die Tests mit JUnit sequenziell ausgeführt werden. Die Skripte wurden so modifiziert, dass die Veritas Tests ausgeführt wurden (siehe Anhang Datenträger Verzeichnis). 42

42 Um den Zeitaufwand zu verringern, wurde versucht, das Testen durch parallele Ant Aufrufe zu beschleunigen. Im Versuch konnten die Tests zwar parallel gestartet werden, sie wurden aber dennoch sequenziell ausgeführt. Sollte diese sequenzielle Ausführung in Zukunft aus Zeitgründen für unzureichend befunden werden, müssen entweder XLT Lizenzen gekauft oder eine andere Testsoftware wie z.b. Selenium eingesetzt werden. Neben den Oberflächen Tests wurde auch die Wiedereinführung von Intershop Unit Tests vorbereitet. Die Installation des Etest Cartridges und des Testrunners auf Intershop 7 wurde im Build-Skript realisiert. Auf Basis des Sonar Skriptes wurde das Verschicken von Testergebnissen über s vorbereitet. 43

43 5. Bewertung 5.1. Realisierungen In diesem Abschnitt werden die Auswirkungen der praktischen Umsetzungen beschrieben und nach den aufgestellten Kriterien aus Abschnitt 1.3 bewertet Sonar Die neue Möglichkeit Isml, Xml und Java Script zu überprüfen wird die Codequalität in der Zukunft maßgeblich erhöhen. Durch die erstellten Regeln werden z.b. eindeutig definierte Schnittstellen erzwungen und die Komplexität einzelner Dateien verringert. Die Entwickler werden durch s auf Regelverstöße hingewiesen. Wenn in Zukunft konsequent daran gearbeitet wird, Regelverstöße zeitnah zu korrigieren sind die laufenden Aufwände gering. Dafür wird ein wesentliches Problem bei der Aktualisierung der SCOOBOX stark abgemindert. Die erstellten Pipeline Regeln können auch in anderen Intershop Projekten eingesetzt werden. Durch die noch ausstehende Einführung von Web und JavaScript Prüfungen, können die gennannten Vorteile auf diese Sprachen ausgeweitet werden. Die Prüfung dieser Web Dateien kann im gesamten Unternehmen erfolgen und muss deshalb noch weitergehend abgestimmt werden Build-Prozess Die verschiedenen Maßnahmen zur Beschleunigung des Build-Prozesses wurden hinsichtlich ihres Zeitgewinns untersucht (siehe Anhang Datenträger Verzeichnis für Details). Die durchgeführten Tests sind in Tabelle 5 dargestellt. Der Build-Prozess wurde jeweils mit unterschiedlichen Konfigurationen der virtuellen Maschine durchgeführt, die in Tabelle 6 zusammengefasst sind. Maßnahme Parallelisierung Clean_all Testnummer Parallelisierung Build_all Standard Parallelisierung s.c.clean Build Parallelisierung s.properties Ausführung in der Konsole Tabelle 5: Testkonfigurationen 44

44 System 1 System 2 System 3 Virtualisierungssoftware VMWare Player VMWare Player VMWare build build- Workstation build Anzahl CPU s Arbeitsspeicher (GByte) Host System Intel Core I7-3770, 16 GB RAM, OCZ Vertex3 SSD Virtuelle Maschine: Intershop SLES Target clean_configure_and_build_all Max Threads 12 Tabelle 6: Build Beschleunigung Testsysteme Die Ergebnisse sind im Diagramm 1 dargestellt. Die Modifikationen des s.properties Targets haben keinen Vorteil erbracht. Die Maßnahmen der Tests 1,2,4 und 5 führten zu signifikanten Zeitgewinnen. Bei Test 5 ist der Prozess etwa um den Faktor 10 schneller als der Standard Build. Aus dem Diagramm wird ersichtlich, dass durch die Variation der Ressourcen der virtuellen Maschine (CPU und RAM) nur sehr geringfügig Zeit gewonnen werden kann (zum Beispiel bei Test 5: t=12 s zwischen System 1 und 3). Zeit in s Testnummer System 1 System 2 System 3 Diagramm 1: Ergebnisse Build Beschleunigung Maßnahmen In einer weiteren Testreihe wurde geprüft, welche Auswirkung die Anzahl der Threads auf die Build Zeit bei Test 5 hat. Die Ergebnisse sind im Diagramm 2 dargestellt. Die benötigte Zeit nimmt bis etwa max_threads=14 ab. Eine weitere Erhöhung dieser Variable verringert die benötigte Zeit nicht. Die Ursache ist in der Gruppeneinteilung der Cartridges 45

45 begründet. Die erste Gruppe enthält z.b. nur 3 Cartridges. Für eine weitere Verringerung der Zeit müssten die Abhängigkeiten zwischen den Cartridges verringert werden. Diese Vorgehensweise ist auch eine wesentliche Entwicklungsrichtung zur Verbesserung der Abwärtskompatibilität (siehe Abschnitt 2.3.1). Bei einem Wechsel von 2 auf 4 Prozessoren kann man einen deutlichen Zeitgewinn feststellen. Der Einsatz von 8 Prozessoren hat keinen weitergehenden Einfluss auf die Build Zeit. Zeit in s Threads max System 1: Zeit in s System 2: Zeit in s System 3: Zeit in s Diagramm 2: Ergebnisse Build Beschleunigung Auswirkung der Thread Anzahl Das parallele build_all Skript wurde erfolgreich in das SCOOBOX Projekt integriert. Mit den verringerten Build Zeiten wird es möglich, die Integration sowohl auf den Systemen der Entwickler als auch auf den Testsystemen schneller und somit häufiger durchzuführen. Außerdem ermöglicht dieser Zeitgewinn die Einführung von automatischen Tests im Deployment-Prozess. Diese Änderungen werden die Softwarequalität der SCOOBOX in Zukunft weiter verbessern. Mit der Integration des schnelleren Skripts wurde bereits begonnen Datenbankmigration Die erstellten Skripte zur automatisierten Durchführung von Datenbankmigrationen können ab dem nächsten Minor Release genutzt werden. Zwar entsteht dadurch ein Mehraufwand bei der Entwicklung, jedoch sind Datenbankmigrationsskripte eine wichtige Voraussetzung für die Aktualisierbarkeit der SCOOBOX. Eine weitere Hilfestellung kann zukünftig der Einsatz eines Datenbank Tools wie Liquibase sein, mit dem strukturelle Unterschiede zwischen einem DBInit- und einem DBMigrate-System erkannt werden können. 46

46 Automatische Tests Die Einführung automatischer Oberflächen Tests mit XLT kann zeitnah erfolgen. Ein Ant-Skript zur automatischen Ausführung ist erstellt worden. Auch die Wiedereinführung von Intershop Unit Tests und deren automatische Ausführung wurden vorbereitet. Es ist anzunehmen, dass sich die im Abschnitt beschriebenen Vorteile einstellen werden Zusammenfassung Aufgrund des begrenzten Umfangs dieser Arbeit war es notwendig, einzelne, der in Kapitel 2 beschriebenen Methoden für die praktische Durchführung auszuwählen. Das geschah nach den Kriterien, die in der Zielsetzung dieser Arbeit festgelegt wurden: Nutzen Initialaufwand laufende Aufwände Einsetzbarkeit in anderen Teams Für das Unternehmen dotsource war es am Bedeutendsten, bei möglichst geringen zusätzlichen laufenden Aufwänden die Abwärtskompatibilität stark zu verbessern. Nach diesen Kriterien waren die günstigsten Realisierungen die Verbesserung der statischen Code Analyse und die Einführung automatischer Tests. Zusätzlich wurde mit Hilfe dieser Umsetzungen und einer verkürzten Build-Zeit der Continuous Integration Prozess optimiert. Diese Verbesserungen des Entwicklungsprozesses erhöhen die Softwarequalität der SCOOBOX in Zukunft, während sie, wie gefordert, nur sehr geringe zusätzliche Aufwände generieren. Des Weiteren wurde, aufgrund ihrer absoluten Notwendigkeit für die Aktualisierbarkeit der SCOOBOX, eine Lösung für die Ausführung von Datenbank-Migrationsskripten entwickelt. Alle erstellten Lösungen können ganz oder partiell in anderen Teams eingesetzt werden. Der verbesserte Build-Prozess und das Skript für die automatisierte Ausführung von Oberflächen Tests finden bereits Anwendungen in anderen Projekten der dotsource GmbH. Zusammenfassend wurden für die umgesetzten und nicht umgesetzten Maßnahmen im Anhang auf Seite 54 f. Übersichten erstellt. 47

47 6. Fazit und Ausblick Im Verlauf der Erstellung dieser Arbeit wurden Techniken und Technologien untersucht, die Softwareentwicklungsprozesse so verbessern, dass die Abwärtskompatibilität erhöht wird. Es war jedoch aus Zeitgründen nicht möglich jede beschriebene Maßnahme in die Produktentwicklung einzuführen. Deshalb wurden die Untersuchungsergebnisse hinsichtlich Nutzen, Initialaufwand, laufende Aufwände und Übertragbarkeit bewertet. Die erfolgversprechendsten Ansätze wurden im Rahmen dieser Arbeit vorbereitet oder umgesetzt. Es wurden neue Prüfungen für die statische Code Analyse eingeführt, die Entwicklung von Datenbankmigrationsskripten wurde technisch ermöglicht und die Einführung von automatischen Tests wurde vorbereitet. Eine Verbesserung der Abwärtskompatibilität durch die genannten Maßnahmen kann erst mittelfristig bewertet werden, wenn neue SCOOBOX Versionen entwickelt wurden und die SCOOBOX in Kundenprojekten anwenderorientiert eingesetzt wird. Die Verbesserungen im Bereich der statischen Code Analyse haben das Potenzial, die Qualität der SCOOBOX maßgeblich zu verbessern. Der nächste logische Schritt ist die Vereinheitlichung der Regeln innerhalb aller Java-Teams. Auch die automatischen Tests werden die Qualität und damit auch die Abwärtskompatibilität verbessern. Die regelmäßige Ausführung der Tests wurde durch die Beschleunigung der Build-Skripte sehr begünstigt. Für die nähere Zukunft ist es interessant, zu überprüfen, inwiefern die angewendeten Optimierungen auch in Projekten mit anderen Basistechnologien wie z.b. Hybris sinnvoll angewendet werden können. Es verbleiben auch noch einige der beschriebenen Prozessoptimierungen, wie zum Beispiel die Einführung eines dezentralen Versionsverwaltungssystems, das eine wichtige Verbesserung für die Zukunft ist. Der wissenschaftlich-technische Fortschritt eröffnet ständig neue Entwicklungsrichtungen hinsichtlich der Optimierung von Softwareentwicklungsprozessen. Daraus erwächst die Notwendigkeit, bestehende Prozesse immer wieder zu hinterfragen und gegebenenfalls zu verbessern. 48

48 V. Glossar Build ist der Prozess, bei dem alle Ressourcen des Quellverzeichnisses so verarbeitet werden, dass als Ergebnis eine ausführbare Software entsteht. Cartridge ist ein Modul, das von einem Intershop Application Server geladen werden kann. Ein Cartridge enthält alle Daten, die zur Konfiguration und Ausführung der jeweiligen Anwendung benötigt werden. Check-in ist ein Vorgang bei der Arbeit mit einem Versionsverwaltungssystem. Es werden veränderte Ressourcen von einem lokalen Verzeichnis (z.b. Workspace) in ein Repository kopiert. Im Repository werden die Änderungen gespeichert und eine Revisionsnummer zugeordnet. Check-out ist ein Vorgang bei der Arbeit mit einem Versionsverwaltungssystem. Es werden Ressourcen einer bestimmten Revision von einem Repository in ein lokales Verzeichnis (z.b. Workspace) kopiert. Commit Synonym für Check-in Dump ist das Abbild einer Datenbank, das in eine Datei Exportiert wurde. Integration ist der Prozess, der das gesamte Softwareprodukt in einer Umgebung, die einem Produktivsystem nahekommt, erstellt. Iteration ist der Zeitraum, für den in einem Entwicklungsprozess eine Planung durchgeführt wird. Kompilieren ist der Prozess, bei dem Quelldateien in ausführbare Dateien übersetzt werden (z.b. java class Datei) Mainline ist der Hauptstrang einer Entwicklung innerhalb eines Versionsverwaltungssystems. Merging Vorgang des Zusammenführens zweier Dateien unterschiedlichen Inhalts. Nightly Build ist ein Build-Prozess, der Nachts durchgeführt wird. Nightly Builds werden eingesetzt, weil Nachts ausreichend Zeit für ausführliche Tests (z.b. Lasttests) zur Verfügung steht. Patch Ist eine Datei, die geänderte Ressourcen (in Bezug auf eine bestimmte Revision des Trunks oder eines Branches) enthält. RAMDisk ist ein virtuelles Laufwerk, das auf Teile des Arbeitsspeichers zurückgreift. Refactoring ist ein Vorgang während der Softwareentwicklung, mit dem Ziel bestehenden Quellcode zu verbessern. Ziel ist es ihn verständlicher und effektiver (Performance) zu machen. Release ist der Prozess des Herausgebens einer Software. Repository ist ein Verzeichnis, in dem eine Versionsverwaltungssoftware Daten ablegt. 49

49 Strict Tag Target (Ant) Trunk Einstellung für Pipelines. Stricten Pipelines müssen alle Parameter übergeben werden, die durch die Startknoten definiert sind. Andernfalls werden sie nicht ausgeführt. ist eine benannte Revision in einem Versionsverwaltungssystem. ist ein Ant Prozedur. Targets können z.b. mit den Befehlen <ant>, <antcall> und <runtarget> aufgerufen werden. Synonym für Mainline 50

50 VI. Anhang 1 Datenträger Verzeichnis Pfad Build/Skripte/build_all/build_all.properties Build/Skripte/build_all/build_all.xmls Build/Skripte/build_all/BuildListCreator.java Build/Skripte/build_all/cartridgelist.properties Build/Skripte/einzelne_Cartridge/cartridge/build.xml Build/Skripte/einzelne_Cartridge/cartridge /clean.xml Build/Skripte/einzelne_Cartridge/properties.xml DBMigrate/Skripte/dbmigrate.properties DBMigrate/Skripte/dbmigrate.xml etest/etestmail/etest-output.html etest/etestmail/merge4.xsl etest/etestmail/report.xml etest/test-ds.xml Sonar/sonarmultimodulskript/sonar-files/javamodule/java-module.xml Sonar/sonarmultimodulskript/sonar-files/jsmodule/js-module.xml Beschreibung Einstellungen für den Build- Prozess Build Skript Klasse zur Analyse von Abhängigkeiten List der Cartridges für den Build Build Datei für ein Cartridge Clean Datei für ein Cartridge Skript, das Umgebungsvariablen sammelt Skript zur Ausführung einer Datenbankmigration Einstellungen für das DB- Migrate Beispiel eines Ergebnisses des XSLT-Skripts XSLT Skript Beispiel eines JUnit Testereports Angepasstes Test Ant-Skript Java Modul Datei mit spezifischen Einstellungen JavaScript Modul Datei mit spezifischen Einstellungen 51

51 Sonar/sonarmultimodulskript/sonar-files/webmodule/web-module.xml Sonar/sonarmultimodulskript/sonar-files/xmlmodule/xml-module.xml Sonar/sonarmultimodulskript/sonarfiles/build.properties Sonar/sonarmultimodulskript/sonarfiles/build.xml Sonar/sonarmultimodulskript/build_zeitmessun gen.xlsx XLTTests/Skripte/build.properties XLTTests/Skripte/build.xml Web Modul Datei mit spezifischen Einstellungen Xml Modul Datei mit spezifischen Einstellungen Sonar Projekteinstellungen Sonar Initialisierungsskript Tabellen und Diagramme zur Auswertung XLT Projekteinstellungen Skript zur automatisierten Testausführung 52

52 2 Beispiel Pipeline 53

53 Multilinguale Sonar Regeln Beschleunigung des Build- Prozesses Entwicklung von Migrationsskripten Automatische Tests 3 Einteilung der durchgeführten Maßnahmen Nutzen/Vorteil -Verbesserung der Codequalität -Verringerung der Komplexität -häufigere Integration auf Entwicklerund Testsystemen -Zeit für automatische Tests und Codeanalyse -Grundvoraussetzung für Aktualisierung der SCOOBOX -Verbesserung der Stabilität -Weniger gegenseitige Störung unter den Entwicklern Initialaufwand (geschätzt) laufende Aufwände (geschätzt) Einsetzbarkeit in anderen Teams Hoch Mittel Pipeline Regeln Intershop Entwicklung Mittel keine muss noch geprüft werden Hoch Hoch Ja, in Intershop Projekten Hoch Mittel Ja -Unit Tests in Intershop Projekten -Oberflächen Tests unternehmensweit weitere Verbesserungsvorschläge -Prüfung von ISML und JavaScript Dateien -Optimierung der SCOOBOX Architektur -automatischer Struktureller Vergleich und Feedback per E- Mail 54

54 4 Einteilung der nicht durchgeführten Maßnahmen Umstellung Entwicklungsmodell Umstellung auf dezentrale Versionsverwaltung Infrastruktur Automatisierung Komponenten und Abhängigkeiten (Architektur) Abhängigkeiten Management (Apache Ivy) Nutzen/Vorteil -je nach Modell -nur einzelne Maßnahmen haben Einfluss auf die Abwärtskompatibilität -Vielfältige Vorteile aber kein Einfluss auf die Abwärtskompatibilität -Verringerung des Installations- und Konfigurations-Aufwandes -bessere Testmöglichkeit verschiedener Releases -gibt es im SCOOBOX Projekt bereits -Einfluss von Bibliotheken auf die Abwärtskompatibilität wird verringert Initialaufwand (geschätzt) Abhängig von der Maßnahme laufende Aufwände (geschätzt) Abhängig von der Maßnahme Hoch Keine Ja Hoch Gering Ja Einsetzbarkeit in anderen Teams Abhängig von der Maßnahme weitere Verbesserungsvorschläge -Paarprogrammierung -Test Driven Development Hoch Hoch Ja -Abhängigkeiten besser definieren -stärkere Begrenzung von Abhängigkeiten Mittel Gering Ja, in Java Teams 55

55 VII. Literaturverzeichnis [1] PM Solutions, Strategies for Project Recovery - A PM SOLUTIONS RESEARCH REPORT, PM Solutions, Glen Mills, [2] Bundesverband Digitale Wirtschaft (BVDW) e.v., 2013 Internetagentur-Ranking BVDW - Internet Online, [Online]. Available: [Zugriff am ]. [3] dotsource GmbH, Referenzen dotsource die E-Commerce Agentur, [Online]. Available: [Zugriff am ]. [4] dotsource GmbH, Unsere E-Commerce Leistungen: Entwicklung für Magento & Intershop, Social Commerce Lösungen, Design. dotsource die E-Commerce Agentur, [Online]. Available: [Zugriff am ]. [5] A. Abran und J. W. Moore, Guide to the Software Engineering Body of Knowledge, IEEE Computer Society, [6] S. Mamoli, Should we choose Iterative or Agile? Nomad8, [Online]. Available: [Zugriff am ]. [7] S. Outi, Outi Salo Enabling Software Process Improvement in Agile Software Development Teams and Organisation, Oulu: VTT PUBLICATIONS, [8] K. Beck, M. Beedle, A. van Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R. C. Martin, S. Mellor, K. Schwaber und J. Sutherland, Manifest für Agile Softwareentwicklung, [Online]. Available: [Zugriff am ]. [9] K. Beck, M. Beedle, A. van Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R. C. Martin, S. Mellor, K. Schwaber und J. Sutherland, Prinzipien hinter dem Agilen Manifest, [Online]. Available: [Zugriff am ]. [10] J. C. Lee, Integrating scenario-based usability engineering and, Blacksburg, VA, [11] M. Gualtieri, Agile Software Is A Cop-Out; Here s What s Next Forrester Blogs, [Online]. Available:

56 agile_software_is_a_cop_out_heres_whats_next. [Zugriff am ]. [12] M. Mainz und F. Bosten, Vergleich verschiedener Verfahren der agilen Softwareentwicklung Winfwiki, [Online]. Available: ung. [Zugriff am ]. [13] K. Schwaber, The Enterprise and Scrum, Redmond: Microsoft Press, [14] Scrum Alliance Inc., it-agile: Scrum, [Online]. Available: [Zugriff am ]. [15] Scrum Alliance Inc., Scrum Alliance - Scrum 101, [Online]. Available: [Zugriff am ]. [16] D. Starr, Elegant Code» Agile is not Scrum, [Online]. Available: [Zugriff am ]. [17] R. Miller und C. Collins, XP distilled, [Online]. Available: [Zugriff am ]. [18] A. Cockburn und L. Williams, The Costs and Benefits of Pair Programming, in extreme Programming and Flexible Processes in Software Engineering, Salt Lake City, [19] J. Shore, James Shore: Kanban Systems, [Online]. Available: [Zugriff am ]. [20] J. Humble und D. Farley, Continuous Delivery : reliable software releases through build, test, and deployment automation, Boston: Addison-Wesley, [21] ThoughtWorks Inc, Continuous delivery, Release software on-demand, not on Red Alert, ThoughtWorks Inc, [22] P. Duvall, Agile DevOps: Continuous software delivery in the cloud, [Online]. Available: [Zugriff am ]. [23] B. Collins-Sussman, B. W. Fitzpatrick und C. M. Pilato, Version Control with Subversion For Subversion 1.5, Creative Commons Attribution License, [24] Google Inc, Tech Talk: Linus Torvalds on git - YouTube, [Online]. Available: [Zugriff am ]. [25] Git, Git - About, [Online]. Available: [Zugriff am ]. [26] M. Bakal, J. Althouse und V. Paridhi, Continuous integration in agile development - 57

57 How agile methods, continuous integration, and test-driven enhance design and development of complex systems, [Online]. Available: [Zugriff am ]. [27] J. Palermo, Speeding up the build ditch the SSD and go for the RAM drive : Jeffrey Palermo (.com), [Online]. Available: [Zugriff am ]. [28] P. Duval, Agile DevOps: Infrastructure automation, [Online]. Available: [Zugriff am ]. [29] ThoughtWorks, technology-radar-october-2012.pdf, [Online]. Available: [Zugriff am ]. [30] Liquibase Database Refactoring home, [Online]. Available: [Zugriff am ]. [31] Liquibase Extensions Portal - LiquiBase Extensions - Confluence, [Online]. Available: [Zugriff am ]. [32] D. Singh, Thought Floor:Schema-less database!!!, [Online]. Available: [Zugriff am ]. [33] M. Fowler, PolyglotPersistence, [Online]. Available: [Zugriff am ]. [34] Projektron GmbH, Projektron BCS - Projektmanagement-Software Projektron BCS, [Online]. Available: [Zugriff am ]. [35] Codehaus, [#SONAR-2602] Make it possible to analyse a multi-modules project whose some modules have different language (sonar.language) - jira.codehaus.org, [Online]. Available: [Zugriff am ]. [36] Ant - Users - Performance of Ant <antcall>, [Online]. Available: [Zugriff am ]. 58

58 [37] Xceptance Software Technologies, XLT - User Manual, [Online]. Available: [Zugriff am ]. 59

59 VIII. Thesen 1. Die Anwendung von Vorgehensmodellen (der Softwaretechnik) unterstützt Unternehmen, in kurzer Zeit qualitativ hochwertige Software zu entwickeln. 2. Die Vorgehensmodelle der Softwareentwicklung weisen alle Vor- und Nachteile auf. Für jedes Projekt muss einzeln geprüft werden, welches Modell oder welche Kombination von Modellen am günstigsten ist. 3. Der Einsatz eines dezentralen Versionsverwaltungssystems hat signifikante Vorteile gegenüber zentralen Lösungen. 4. Statische Code Analyse verbessert die Code- und die Softwarequalität, wenn sinnvolle Regeln erstellt und angewendet werden. Die Einhaltung von Code Standards kann die Architektur von Software verbessern. 5. Der beschleunigte Build-Prozess der SCOOBOX ermöglicht eine häufigere Integration. Die sich anschließenden automatischen Tests können dadurch ebenfalls öfter ausgeführt werden. 6. Ein schneller Build-Prozess ermöglicht häufiges automatisches Testen auf einem Continuous Integration System. 7. Automatische Tests verbessern die Abwärtskompatibilität. 8. Ein schneller Feedbackprozess erhöht die Stabilität der Builds. 9. Die Aktualisierung von Software, die eine umfangreiche Datenbasis besitzt, erfordert die Anwendung von Methoden, die die Bestandsdaten sicher in das neue System integrieren. 10. Eine gute Softwarearchitektur erleichtert Aktualisierungen von Software in Produktivsystemen. 60

60 IX. Selbstständigkeitserklärung Ich erkläre hiermit, dass ich die vorliegende Bachelorarbeit selbstständig und unter Verwendung der angegebenen Quellen und Hilfsmittel angefertigt habe. Diese Arbeit lag in gleicher oder ähnlicher Weise noch keiner Prüfungsbehörde vor und wurde bisher noch nicht veröffentlicht. Jena, den