Konzeption eines Vorgehens für die Durchführung eines Upgrades … · Der Funktionsumfang von TYPO3 kann mittels Erweiterungen, sogenannter Extensions, erhöht werden. Hierfür

2018

Konzeption eines Vorgehens für die

Durchführung eines Upgrades von TYPO3

Autor: Sammy Baghdadi, geboren am 19.12.1987, Radebeul, Deutschland

Matrikelnummer: 458982

Erstprüfer: Prof. Dr. Marcus Birkenkrahe

Zweitprüfer: Sebastian Kreideweiß, M.Sc.

Eingereicht am: 01. Februar 2018

Bachelorarbeit

zur Erlangung des akademischen Grades Bachelor of Science

Hochschule für Wirtschaft und Recht Berlin

Fachbereich 1

Studiengang Wirtschaftsinformatik

Eidesstattliche Erklärung

Hiermit erkläre ich an Eides statt, dass ich die vorliegende Abschlussarbeit

selbstständig und ohne fremde Hilfe verfasst und andere, als die angegebenen Quellen

und Hilfsmittel, nicht benutzt habe. Die den benutzten Quellen wörtlich oder inhaltlich

entnommenen Stellen (direkte oder indirekte Zitate) habe ich unter Benennung des

Autors/der Autorin und der Fundstelle als solche kenntlich gemacht.

Sollte ich die Arbeit anderweitig zu Prüfungszwecken eingereicht haben, sei es

vollständig oder in Teilen, habe ich die Prüfer/innen und den Prüfungsausschuss

hierüber informiert.

Berlin, 01. Februar 2018__________

Ort, Datum Unterschrift

Abstract

Deutsch:

Das Ziel der vorliegenden Bachelorarbeit ist es, zu prüfen wie ein ideales Vorgehen für

das Upgrade einer TYPO3-Installation aussehen kann. TYPO3 ist ein Open Source

Content Management System mit dessen Hilfe Websysteme, vorrangig Webseiten,

entwickelt werden können. Im Verlauf der Arbeit wird das Wort Upgrade definiert und

von einem Update abgegrenzt. Es wird außerdem untersucht, welche Arten von

Qualität für Software eine Rolle spielen. Auf Basis der erarbeiteten theoretischen

Grundlagen wird ein Interviewleitfaden entwickelt, der bei der Befragung von sechs

TYPO3-Experten zum Einsatz kommt. Die Interviews werden ausgewertet und mithilfe

der BPMN wurden einzelne Modelle entworfen und textlich beschrieben. Es wurde am

Rande betrachtet, welche Faktoren für ein Upgrade wichtig sind und wie moderne

Ansätze, wie automatisiertes Deployment oder die Nutzung des Tools „Composer“, in

dieses Vorgehen mit einfließen können. Die Arbeit richtet sich vor allem an Personen,

die bereits grundlegende Erfahrungen mit TYPO3 haben und eine Grundlage bzw. ein

Hilfsmittel für ein Upgrade suchen.

English:

The aim of this bachelor’s thesis is to examine the current best-practices for upgrading

a TYPO3 installation. TYPO3 is an open-source content management system. Using

TYPO3, companies and individuals are able to quickly develop internet information

systems and websites. During the course of this work, the term "upgrade" is defined

and differentiated from the term "update". Additionally, the indicators of quality software

are examined. On the basis of the established theoretical principles, an interview guide

is developed which is used to direct the survey of six TYPO3 experts. Using the

principles of BPMN, individual models are created and recorded. The requirements and

preconditions for an upgrade are briefly considered, including the influence of modern

software transition approaches such as automated deployment, and, additionally, the

use of the dependency management tool "Composer", in order to devise an optimal

upgrade procedure. This work is aimed primarily at individuals who currently retain

basic experience with TYPO3 and who are in need of a guide or toolkit to conduct an

upgrade.

Inhaltsverzeichnis

1 Einleitung ............................................................................................................... 1

1.1 Motivation ...................................................................................................... 1

1.2 Problemstellung und Forschungsfrage .......................................................... 1

1.3 Aufbau der Arbeit .......................................................................................... 1

2 Grundlagen ............................................................................................................ 2

2.1 TYPO3 .......................................................................................................... 2

2.1.1 Verbreitungsgrad und Budget .................................................................... 3

2.1.2 Roadmap ................................................................................................... 4

2.1.3 LTS – Long Term Support ......................................................................... 5

2.1.4 Technische Abhängigkeiten ....................................................................... 6

2.2 Einordnung von Upgrade und Update ........................................................... 7

2.3 Composer...................................................................................................... 8

2.4 Release Management, Integration und Deployment ...................................... 8

2.5 Softwarequalität........................................................................................... 10

2.5.1 Qualitätsmanagement ............................................................................. 11

2.6 Dokumentation ............................................................................................ 12

2.7 Standard- oder Individualsoftware ............................................................... 12

2.8 Der Wartungsprozess .................................................................................. 12

2.9 Technische Gründe für ein Upgrade ............................................................ 13

2.10 Finanzielle Gründe für ein Upgrade ............................................................. 15

2.11 Aktueller Stand in der Literatur .................................................................... 16

3 Forschungsmethode ............................................................................................ 17

3.1 Leitfadengestütztes Experteninterview ........................................................ 18

3.2 Erstellung des Interviewleitfadens ............................................................... 18

3.3 Auswahl der Interviewpartner ...................................................................... 19

3.4 Auswertung der Interviews .......................................................................... 22

4 Ergebnisse .......................................................................................................... 23

4.1 Upgrade und Update aus Sicht der Experten .............................................. 23

4.2 Gründe für ein Upgrade ............................................................................... 24

4.3 TYPO3 und Metriken ................................................................................... 24

4.4 Akteure eines TYPO3-Upgrades ................................................................. 25

4.5 Phasen eines TYPO3-Upgrades ................................................................. 28

4.5.1 Angebotsphase 1 .................................................................................... 29

4.5.2 Analysephase – Upgrade Check ............................................................. 30

4.5.3 Angebotsphase 2 .................................................................................... 36

4.5.4 Vorbereitungsphase ................................................................................ 37

4.5.5 DEV-Phase.............................................................................................. 39

4.5.6 Stage-Rollout-Phase ............................................................................... 43

4.5.7 Testphase / Abnahmephase .................................................................... 45

4.5.8 Live-Rollout-Phase .................................................................................. 47

4.6 Häufige Probleme bei einem Upgrade ......................................................... 48

4.7 Wichtige Tools bei einem Upgrade .............................................................. 48

4.7.1 Fehlende Tools ........................................................................................ 49

4.8 Zukunft von TYPO3 und Konsequenzen für Upgrades ................................ 50

4.9 Diskussion der Ergebnisse .......................................................................... 51

5 Fazit .................................................................................................................... 53

6 Abkürzungsverzeichnis ........................................................................................... I

7 Literaturverzeichnis ................................................................................................ II

8 Abbildungsverzeichnis .......................................................................................... VI

9 Tabellenverzeichnis ............................................................................................. VII

10 Anhang .......................................................................................................... VIII

1

1 Einleitung

1.1 Motivation

Die Motivation diese Arbeit zu erstellen, fußt vor allem auf den bisher gesammelten

Erfahrungen im Umgang mit dem Open Source CMS TYPO3 und den Schwierigkeiten

bei einem Upgrade des Systems. In der bisherigen Arbeit und auch bei Gesprächen,

welche ich während vieler Veranstaltungen (z.B. Barcamps) geführt habe, war dies ein

sehr unbeliebtes Thema und es schien so, als ob jeder seine eigene Strategie für

diesen Prozess parat hat.

1.2 Problemstellung und Forschungsfrage

Da dies ein relativ unbefriedigender Zustand ist, soll der Kern der Arbeit die Frage

beantworten, wie ein ideales Vorgehen für ein TYPO3-Upgrade aussehen kann. Es soll

weiterhin geprüft werden, welche Faktoren ein solches Upgrade beeinflussen und wie

flexibel es gehalten werden muss. Um dies so genau wie möglich darzustellen, müssen

die Begriffe „Upgrade“ und „Update“ definiert und voneinander abgegrenzt werden.

1.3 Aufbau der Arbeit

Zu Beginn findet eine Heranführung an das Thema statt. Es wird dargelegt, was

TYPO3 ist und welche Begriffe im TYPO3-Universum von Bedeutung sind. Zusätzlich

werden Technologien und Programme betrachtet, die für das Upgrade eine Rolle

spielen können und die eventuell auch zusätzliche Thesen bzw. Fragen für die weitere

Bearbeitung im Hauptteil generieren. Es soll auch über die Literatur herausgefunden

werden, ob schon Vorgehensmodelle existieren oder andere Modelle, die

Rückschlüsse auf den zu erstellenden Prozess erlauben.

Im Hauptteil wird auf Basis von geführten Experteninterviews ein Vorgehen für die

Durchführung eines TYPO3-Upgrade entwickelt. Die Visualisierung des Vorgehens soll

mittels der BPMN durchgeführt werden. Die Ergebnisse sollen dargestellt und diskutiert

werden.

Im letzten Teil wird ein Fazit aus den Erkenntnissen gezogen und ein Ausblick

aufgezeigt.

2

2 Grundlagen

Im folgenden Kapitel werden notwendige theoretische Grundlagen vermittelt. Es sollen

Begriffe aus dem TYPO3-Bereich erklärt und für die Arbeit wichtige Erkenntnisse aus

der Literatur aufgezeigt werden. Weiterhin wird durch die Definition von Begriffen auch

eine Abgrenzung von diesen untereinander ermöglicht.

2.1 TYPO3

TYPO3 ist ein Open Source „Content Management System” welches von Kasper

Skårhøj im Jahr 2000 erstmalig als Beta-Version veröffentlich wurde.1 Die

Überlegungen ein eigenes CMS zu entwickeln, reiften bei Kasper Skårhøj schon im

Jahr 1997 als der Begriff CMS noch nicht wirklich weit verbreitet war.2 Zu Beginn wurde

TYPO3 als kommerzielles Produkt für seinen damaligen Arbeitgeber „superfisch.com“

entwickelt. Nach Meinungsverschiedenheiten im Jahr 1999 trennte er sich von seiner

Firma und entwickelte TYPO3 nun selber weiter.

Der Name TYPO3 lässt sich auf den Erfolg der Version 3 zurückführen. Ursprünglich

gab es auch die Version 1, 2 und 2.5. Seit dem Launch der Version 4 stand aber fest,

dass das System von nun an TYPO3 heißen soll.3

TYPO3 wird unter der Open Source Lizenz GNU General Public License (GPL)

veröffentlicht.4 Die GPL Lizenz definiert vier sogenannte Freiheiten. In diesen ist

beschrieben, dass in der Praxis für eine Software unter GPL keine Lizenzgebühren

erhoben werden dürfen, aber Dienstleistungen rund um das Produkt (wie z. B.

Einrichtung, Konfiguration oder Erweiterungen) kommerziell angeboten werden

können.5

Für die Konfiguration von TYPO3 wurde eine eigene Konfigurationssprache mit dem

Namen „TypoScript“ entwickelt. Mittels TypoScript lässt sich beschreiben wie die durch

1 (Meyer & Helmich, 2016, S. 10)


3 (TYPO3 Association, kein Datum-a)

4 (Lobacher & Krell, 2013, S. 10)


3

TYPO3 verwalteten Daten aus der Datenbank in das Ausgabedokument gelangen

sollen.6

Der Funktionsumfang von TYPO3 kann mittels Erweiterungen, sogenannter

Extensions, erhöht werden. Hierfür steht innerhalb des TYPO3 CMS das PHP-

Framework „Extbase“7 und die Templating-Engine „Fluid“8 zur Verfügung. Extbase ist

die API-Schnittstelle, die seit TYPO3 4.3 zum Einsatz kommt, neben der klassischen

pibase-Schnittstelle. Fluid ist eine eigens für TYPO3 entwickelte Templating-Engine,

die den Anforderungen der TYPO3-Entwickler gerecht werden soll9, welche aber auch

im neuen PHP Framework „FLOW“ (ursprünglich „FLOW3“) zum Einsatz kommt.10

Die TYPO3 Association (Dachorganisation hinter TYPO311) bezeichnet TYPO3 selbst

als Enterprise Open Source CMS (was dessen Fokus vermuten lässt) gibt aber auch in

den Key Features an, für kleine bis große Webseiten nutzbar zu sein.12

2.1.1 Verbreitungsgrad und Budget

Laut der Webseite „CMSCrawler“ befindet sich TYPO3 in einem weltweiten Vergleich

der CMS auf Platz fünf der am häufigsten eingesetzten Systeme.13 Schaut man sich

die Verteilung nur innerhalb von Deutschland an, steht TYPO3 sogar an Platz zwei.14

Die Webseite „webkalkulator.com“ attestiert TYPO3 auch einen zweiten Platz hinter

dem CMS „Wordpress“. In dieser Auflistung wird auch das durchschnittliche Budget

eines Webprojektes mit dem jeweiligen CMS gezeigt. Als Bemessungsgrundlage

dienten 42.421 Projekte, davon 25.857 in den letzten zwölf Monaten. Es wurde ein

durchschnittliches Budget für TYPO3-Projekte von insgesamt 5.430 € ermittelt. Im

Vergleich dazu belegen Platz eins Wordpress mit einem Budget von 2.240 € und Platz

drei „Joomla!“ mit durchschnittlich 2.060 €.15


7 (Meyer & Helmich, 2016, S. 293)


9 (Frömken, 2012)

10 (Wikipedia - Flow Framework, 2017)

11 (TYPO3 Association, kein Datum-b)

12 (TYPO3 Association, kein Datum-c)

13 (CMSCrawler, 2017)

14 (CMSCrawler, 2017)

15 (Webkalkulator, 2017)

4

Besonders interessant ist dabei die Abbildung 1 von der Webseite „Webkalkulator“.

Diese Grafik zeigt die jeweiligen Budgetdurchschnittswerte im Verhältnis der

unterschiedlichen Auftragnehmer und Auftraggeber. So zeigt sich, dass bei größeren

Agenturen mit Unternehmen als Kunden der Durchschnittswert bei 20.000 € liegt.

Abbildung 1: Umsatz für Webprojekte nach Marktsegmenten Quelle: (CMSCrawler, 2017)

Da die im späteren Verlauf gewählten Experten für die Interviews, alle einen

Erfahrungsschatz aus dem Bereich der größeren Agenturen haben, wird sich die

Erstellung des Vorgehens an deren Struktur orientieren.

2.1.2 Roadmap

Die Entwicklung von TYPO3 erfolgt anhand einer sogenannten „Roadmap“. Diese

spiegelt die Planung der sogenannten „Sprint-Releases“16 (Versionen zwischen den

LTS-Versionen) wieder. Für den jeweiligen Versionsstrang (in Zukunft also die

Version 9) gibt es eine vorher geplante Abfolge von Releases bis zum Erscheinen der

LTS-Version. Die Abbildung 2 zeigt die geplante Roadmap auf.

16 (TYPO3 YouTube Channel, 2017)

5

Abbildung 2: Roadmap Quelle: (Weiland, 2017)

Statt der offiziellen Grafik der TYPO3-Webseite17 wird die erweiterte des TYPO3-

Hosters „jweiland.net“ hier dargestellt. Diese zeigt zusätzlich zu den Laufzeiten einer

LTS-Version auch die jeweilige Entwicklungszeit und auch die sogenannte „ELTS-

Version“ die einen kostenpflichtigen verlängerten Support durch die TYPO3 GmbH

darstellt.18 Weitere Erklärungen zum Begriff LTS und auch ELTS folgen im nächsten

Kapitel.

2.1.3 LTS – Long Term Support

Aufgrund der Abwärtskompatibilität werden immer mehrere TYPO3-Versionszweige für

eine Dauer von ca. drei Jahren ab Erstveröffentlichung mit Updates versorgt. In jedem

Versionszweig ist die sogenannte LTS-Version die letzte Minor-Version in diesem

Zweig. Ausgehend vom semantischen Versionieren (Semantic Versioning19) ist die

jeweilige Hauptversion die Major-Version (also TYPO3 Version 6 oder TYPO3

Version 7). Die nächste Stelle nach dem Punkt ist die Minor-Version. Die höchste

Nummer bildet hier den LTS-Release (also TYPO3 6.2 oder TYPO3 7.6). Die letzte

Zahl nach dem Punkt gibt die Patch-Version an (also TYPO3 6.2.11 oder TYPO3

7.6.5). Innerhalb einer LTS-Version gibt es einen sogenannten „feature freeze“. Es

kommen keine neuen Funktionen hinzu. Es werden lediglich Bugs und

Sicherheitsprobleme behoben. Für den Betrieb einer Webseite können zwar auch die

17 (TYPO3 Association, kein Datum-d)

18 (TYPO3 GmbH, 2017)

19 (Preston-Werner, 2013)

6

Versionen zwischen einer LTS-Version und der nächsten genutzt werden, es wird aber

empfohlen auf eine LTS-Version zu setzen, da nur für diese offizielle Upgrade-Pfade

zur Verfügung gestellt werden.20

Die im vorherigen Kapitel erwähnte ELTS-Version spielt hier eine gesonderte Rolle.

Die TYPO3 GmbH, gegründet durch die TYPO3 Association21, bietet hier die

Möglichkeit, gegen Zahlung weiterhin mit Sicherheitsupdates versorgt zu werden. Es

gelten weiterhin die Grundsätze des semantischen Versionierens. Dieser zusätzliche

Service wird nach eigenen Aussagen unter anderem angeboten, um den Zeitraum für

eine Migration zu vergrößern oder auch um das System mit alten Softwarebibliotheken

kompatibel zu halten.22

Rückschlüsse über den Verbreitungsgrad der einzelnen LTS-Versionen lässt auch die

Webseite „t3census.info“ zu. Auf dieser Seite werden die Ergebnisse aus einem

automatischen Durchsuchen des Webs (sogenanntes „crawling“) nach den

Versionsnummern von TYPO3-Installationen aufgezeigt. Es zeigt sich, dass wie

empfohlen, hauptsächlich auf LTS-Versionen gesetzt wird.23 Sehr weit verbreitet sind

noch die Versionen 4.5 und 6.2 die jedoch nicht mehr unterstützt werden. Die LTS 7.6

hat hier noch einen recht geringen Anteil.

2.1.4 Technische Abhängigkeiten

Der Code von TYPO3 basiert auf der Open Source Skriptsprache PHP (steht für „PHP:

Hypertext Preprocessor“ als rekursives Akronym) und ist eine Sprache hauptsächlich

für Webanwendungen.24 PHP selbst braucht noch einen Webserver25 wie z. B. Apache

oder Nginx um den interpretierten Code an einen User (meist per HTML26 und per

HTTP27 oder besser HTTPS, also gesichert durch Secure Sockets Layer28) ausliefern

zu können. Im Hintergrund arbeitet eine relationale Datenbank29 wie z. B. MySQL oder

MSSQL um die vom CMS verwalteten Daten zu speichern.

20 (TYPO3 YouTube Channel, 2017)

21 (TYPO3 GmbH, 2017)

22 (TYPO3 GmbH, 2017)

23 (Krause, 2016)

24 (php.net, kein Datum)

25 (Casteleyn, Daniel, Dolog, & Matera, 2009, S. 241)



28 (Thomas, 2001, S. 158)

29 (Abts & Mülder, 2017, S. 169)

7

Für den Betrieb von TYPO3 kommen verschiedenste Betriebssysteme und Webserver

in Frage. Besonders geeignet ist jedoch TYPO3 im Zusammenspiel mit einem Linux-

basierten Betriebssystem. Man spricht hier auch vom Akronym „LAMP“ welches für

„Linux, Apache, MySQL and PHP“ steht.30

Die neuste TYPO3 Version 8.7 gibt folgende technische Abhängigkeiten an:

- PHP Version 7.0 oder größer - MySQL Version größer 5.5 - Webserver wie z. B. Apache oder IIS31

Außerdem sind noch weitere Bibliotheken wie z. B. ImageMagick und Erweiterungen

des Webservers notwendig.32

Da der Server und dessen Komponenten die Basis für die Lauffähigkeit für TYPO3

bilden, sollten sich hier auch Fragen für das Vorgehen ableiten, die in den Interviews

gestellt werden.

2.2 Einordnung von Upgrade und Update

Laut dem Gabler Wirtschaftslexikon handelt es bei einem Update um eine "erweiterte

und/oder verbesserte Version eines Softwareprodukts.“33 Wobei es sich bei einem

Upgrade um eine „Aufrüstung von Hardware oder Software zu höherer

Leistungsfähigkeit, ohne dass ein neues Modell erworben werden muss.“34 handelt.

Beim Update bleibt die Leistungsfähigkeit also gleich und wird lediglich minimal

verbessert, beim Upgrade wird diese deutlich erhöht.

In dem Buch „Softwarewartung“ wird ein Upgrade als eine neue Version einer Software

bezeichnet, die alle Mängelkorrekturen vorausgegangener Updates enthält. Weiterhein

unterliegen Upgrades keiner besonderen Dringlichkeit und können deshalb geplant

werden. Da aber Aufwände aus den Upgrades sehr hoch sein können, werde diese

oftmals lange hinausgezögert.35 Diese Definition veranschaulicht zwar schon besser

den Unterschied zwischen dem Update und dem Upgrade, jedoch ist hier immer noch

Raum für eine genauere Definition der Begriffe. Um für weitere Klarheit zu sorgen und

auch um festzustellen ob die Begriffe im TYPO3-Bereich in andere oder gleicher Form

30 (Abts & Mülder, 2017, S. 63)

31 (TYPO3 Dokumentation, 2017)

32 (TYPO3 Association, kein Datum-e)

33 (Gabler Wirtschaftslexikon, kein Datum-a)

34 (Gabler Wirtschaftslexikon, kein Datum-b)

35 (Bommer, Spindler, & Barr, 2008, S. 84)

8

verwendet werden, sollen auch die Interview-Teilnehmer nach ihrer Ansicht befragt

werden.

2.3 Composer

Das Tool „Composer“ ist ein sogenannter „Dependency Manager“ geschrieben in PHP

für PHP-Applikationen. Komplexe PHP-Applikationen setzen sich in der Regel aus

einer Reihe von Fremdbibliotheken verschiedenster Versionen zusammen. Um diese

Abhängigkeiten nicht manuell pflegen zu müssen, gibt es das oft genutzte Tool

Composer.36

Auch in der TYPO3-Welt hat Composer mittlerweile einen festen Platz. So ist es Teil

des TYPO3-Wiki und TYPO3 und Extensions können dadurch installiert werden.37

Mithilfe von Composer ist es möglich, TYPO3 und seine Extensions automatisiert zu

installieren. Wenn man diese Option anwendet, ist es danach nicht mehr möglich, über

andere Wege TYPO3-Extensions zu installieren.38 Der Vorteil liegt aber darin, dass die

Versionskonfiguration des Projekts über eine Datei (die „composer.json“39)

durchgeführt werden kann. Dies hat den Vorteil, dass die Datei wiederum auch (z. B.

mit Git) versioniert werden kann. Hinsicht dieser Arbeit gilt es herauszufinden,

inwieweit die Nutzung von Composer den Prozess eines Upgrades von TYPO3

beeinflusst.

2.4 Release Management, Integration und Deployment

Unter Integration, versteht man die Zusammenführung von einzelnen Komponenten zu

einer bekannten Konfiguration für ein System. Diese besitzen jeweils eine

Versionsangabe und ihre Wirkungsweise und Schnittstellen sind aufeinander

abgestimmt und führen eine gemeinsame Aufgabe aus.40 Am Beispiel von TYPO3

wären dies unter anderem die Konfiguration mittels TypoScript oder die Konfiguration

von TER-Extensions. Die Zusammensetzung dieser Konfiguration (meist in Dateien)

kann manuell geschehen aber auch Teil eines „automated integration“ oder

36 (Rees, 2016, S. 2)

37 (TYPO3Wiki, 2016)

38 (Meyer & Helmich, 2016, S. 22)

39 (Rees, 2016, S. 18)

40 (Balzert, 2008, S. 431)

9

„continuous integration“ Systems wie z. B. „Jenkins“41 sein. Den Vorgang des

Zusammensetzens selbst nennt man „builden“42

Das Deployment (Ausliefern der gebauten Konfiguration) selbst ist speziell für Web-

Systeme wie TYPO3 ein wichtiges Thema. Da die gebaute Konfiguration meist auf

entfernte Webserver ausgeliefert werden muss, gibt es auch hier ein Interesse diesen

Vorgang zu automatisieren. Man spricht hier von „continuous deployment“43. Auch das

kann ein Jenkins-System leisten.

Mittels einer Frage im Interview soll geklärt werden, an welchen Stellen des Vorgehens

dieser Punkt eine Rolle spielen könnte. Diese Aspekte werden nicht detaillierter

Bestandteil der Arbeit, weil es sich um sehr spezielle Themen handelt. Es erfolgt hier

lediglich eine Randbetrachtung mit der Absicht, die Nachhaltigkeit der zu erstellenden

Modelle zu erhöhen.

Anders verhält es sich mit den Empfehlungen aus ITIL und dem darin definierten

„Release Management“. Auch hier gibt es diese Begriffe („build“ wird synonym

verwendet aber anstatt „integration“ spricht man von „rollout“ bzw. „deploy“44). Hier wird

das ausführliche Testen von sogenannten „Releases“ (Veröffentlichungen)

beschrieben.45 Die Abbildung 3 zeigt eine Unterteilung in Test- und Produktivsystem.

Diese wichtigen Elemente sollen Bestandteil des Interviews sein, um zu klären, wo

diese im Prozess zum Einsatz kommen.

41 (Jenkins Webseite, kein Datum)

42 (Bergman & Priebsch, 2010, S. 377)


44 (Köhler, 2007, S. 252)

45 (Köhler, 2007, S. 102-109)

10

Abbildung 3: Deploy von getesteten Releases auf Test- und Produktivsystem Quelle: (Köhler, 2007, S. 106)

2.5 Softwarequalität

Die Frage nach der Definition von Softwarequalität ist zunächst auch eine Definition

des Begriffes Qualität und abhängig von der Software. Zum einen liegt es sehr nahe,

die Definitionen einiger Normenwerke zu betrachten. Diese Definitionen zieht auch

Balzert in seinem Lehrbuch heran. Sie unterscheiden sich aber durchaus. Er stellt fest,

dass „… selbst in den Normenwerken der Qualitätsbegriff unterschiedlich definiert“46

wird. Er führt die Definition von Qualität dabei auf folgende fünf Ansätze zurück:

▪ Der transzendente Ansatz o Qualität ist universell erkennbar, absolut, einzigartig vollkommen.

▪ Der produktbezogene Ansatz o Qualität ist eine messbare, genau spezifizierte Größe, die das Produkt

beschreibt und durch die man die Qualitätsunterschiede aufzeigen kann. ▪ Der benutzerbezogene Ansatz

o Qualität wird durch den Produktnutzer festgelegt. ▪ Der prozessbezogene Ansatz

o Qualität entsteht durch die richtige Erstellung des Produkts. ▪ Der Kosten/nutzen-bezogene Ansatz

o Qualität ist eine Funktion von Kosten und Nutzen.47

46 (Balzert, 2008, S. 461)

47 (Balzert, 2008, S. 460)

11

Weiterhin folgt er der Definition der ISO/IEC 9126-1 die zwischen einer externen und

internen Qualität für Softwareprodukte unterscheidet.48

Die externe Qualität interessiert vor allem den Kunden bzw. den Nutzer einer

Anwendung. Externe Qualitätsmerkmale sind unter anderem:

▪ Funktionalität ▪ Gebrauchstauglichkeit ▪ Reaktionsfreudigkeit ▪ Sicherheit ▪ Verfügbarkeit ▪ Zuverlässigkeit49

Interne Qualität spiegelt vor allem die Bedürfnisse der Entwickler bzw. Administratoren

wieder. Hier spielen Faktoren wie z. B. die Qualität des Codes, bewertet durch Aspekte

wie z. B. Lesbarkeit, Verständlichkeit, Anpassbarkeit und Erweiterbarkeit, eine wichtige

Rolle.50 Im Verlauf der Arbeit wird untersucht, welche dieser Aspekte durch ein

Upgrade wie beeinflusst werden.

2.5.1 Qualitätsmanagement

Die oben beschriebenen Faktoren für Qualitätsmerkmale sind also Grundlage für die

Bemessung von Qualität. Sollte eines der genannten Merkmale nicht erfüllt sein,

können wir von einer geringeren Qualität ausgehen.51 Mittels dem

Qualitätsmanagement und dem Regelkreis der Qualitätssicherung geht es um die

Einhaltung dieser Merkmale.52 Das Messen von Qualität ist auch über die sogenannten

Metriken möglich. Hierbei wird versucht, Aspekte dieser Merkmale zu quantifizieren.

Ein Beispiel wäre dafür die Anzahl der Codezeilen geteilt durch die Anzahl der

gefundenen Fehler. Vergleicht man nun auch noch den Wert vor und nach einem

Upgrade, kann man daran messen, wie sich dieser verbessert oder verschlechtert hat.

Während der Interviews sollen Fragen formuliert werden, die bei den Experten in

Erfahrung bringen, was für sie geeignete Messwerte sind. Mithilfe der Antworten soll

ergründet werden, inwieweit diese bereits berücksichtigt werden.

48 (Balzert, 2008, S. 462)




52 (Bommer, Spindler, & Barr, 2008, S. 113-115)

12

2.6 Dokumentation

Die Dokumentation ist ein weiterer wichtiger Bereich der Softwarewartung. Es gibt

dabei zwei Blickwinkel: Welche Dokumente existieren bereits und unterstützen die

Wartung? Welche Dokumente müssen gepflegt und aktuell gehalten werden?

Die Dokumentation muss also mit dem Produkt mitwachsen. Da die Motivation dafür

vergleichsweise gering ist, sollte die Pflege dieser, fester Bestandteil des Prozesses

sein.53 Im zu erstellenden Vorgehen wird dies berücksichtigt werden. Es soll außerdem

bei den Experten in Erfahrung gebracht werden, welche Dokumentationen sie

üblicherweise erstellen und pflegen. Anhand der Interviews soll auch herausgefunden

werden, an welchen Stellen im Upgrade-Prozess diese Aktivität am besten

durchgeführt wird.

2.7 Standard- oder Individualsoftware

„Um Standardsoftware handelt es sich, wenn die Software bereits entwickelt worden ist

und nunmehr an einen nicht von vornherein feststehenden Kundenkreis vertrieben

werden soll.“54 Aus der Aussage von Balzert lässt sich ableiten, dass es sich bei

TYPO3 um Standardsoftware handeln muss. Denn die Individualsoftware auf der

anderen Seite ist für einen Auftraggeber speziell entwickelte Software anhand der

gesammelten Anforderungen.55

Dies bedeutet also, dass zwar TYPO3 selbst eine Standardsoftware ist, die

Erweiterungen selber sich aber auch noch einmal in Standard- und Individualsoftware

unterteilen lassen. So sind die Extensions, die sich im TYPO3-TER (TYPO3 Extension

Repository, öffentliches Verzeichnis für freie Extensions)56 befinden, als

Standardsoftware zu sehen. Diese sind bereits entwickelt worden und können von

einem unbestimmten Kundenkreis genutzt werden. Im Umkehrschluss bedeutet dies,

dass die Extensions, die im speziellen Kundenauftrag entwickelt worden sind, eine

Individualsoftware darstellen.

2.8 Der Wartungsprozess

Der Wartungsprozess nach Bommer, Spindler & Baar ist die Grundlage für diese Arbeit

und das Erstellen eines Vorgehens für ein Upgrade von TYPO3. Zu betrachten ist hier


54 (Balzert, 2008, S. 335)

55 (Balzert, 2008, S. 335)

56 (TYPO3 Extension Repository, kein Datum)

13

die Ablauf- und Aufbauorganisation. Die Autoren haben dafür den aus der IEEE1219

stammenden Wartungsprozess angepasst, da sie nur bedingt einen Erfolg

versprechenden Prozess sahen. Sie haben dafür zusätzliche Fragen formuliert, die es

im Rahmen des Prozesses zu beantworten gilt. 57

Weiterhin wurden für diesen Prozess diverse Beteiligte in Form von Rollen definiert.

Diese sind: der Wartungsmanager, Wartungsingenieur/-mitarbeiter,

Testmanager/Verifizierer, Konfigurationsmanager, Qualitätsmanager, Produktmanager

und Validierer.58 Ob und inwieweit diese Rollen beim Upgrade von TYPO3 Anwendung

finden, gilt es zu betrachten. Eine Frage dazu soll im Interview gestellt werden.

2.9 Technische Gründe für ein Upgrade

Einer der Gründe für ein Upgrade von TYPO3 aus technischer Sicht, kann der Abbau

sogenannter „technischer Schulden“ sein. Der erstmals mit Ward Cunningham in

Verbindung gebrachte Begriff (er sagt zwar im Artikel nicht direkt „technical debt“ aber

im Zusammenhang mit dem Begriff „debt“ und „code“ lässt sich dies ableiten)59 wird

auch von anderen Autoren herangezogen, um ein starkes positives Argument

hinsichtlich eines Upgrades zu haben.60

So wird bei technischen Schulden davon ausgegangen, dass für schlechten Code

Zinsen fällig werden. Es kann zwar sinnvoll sein, ein Darlehen (und damit die Zinsen)

in Kauf zu nehmen, damit ein Programm schneller veröffentlicht werden kann, wird

aber das Darlehen nicht rechtzeitig getilgt und damit die Zinslast verringert, kann sich

dies bis zum Konkurs (also dem totalen Ausfall der Software oder des Unternehmers

dahinter) entwickeln. Es gilt hier also durch Programmpflege frühzeitig diese Schulden

abzubauen.

Die Autoren Bommer, Spindler und Barr machen zwar klar, dass Software nicht

verschleißen kann, wie es bei einem Auto der Fall ist, sie zeigen aber auf, welche

Gründe für eine Wartung sprechen. Sie nennen dafür die drei Folgenden:

Entropie ist das Maß der Unordnung und Zufälligkeit eines Systems und erhöht sich,

wenn man ein System sich selbst überlässt oder hat schon einen recht hohen Wert,



59 (Cunningham, 1992)


14

wenn während der Entwicklung von Software Architekturgrundsätze nicht mehr (z. B.

Aufgrund von Zeitdruck) eingehalten wurden. 61

Lack of movement beschreibt, wie die fachliche Umgebung und technische

Umgebung einer Software sich weiterentwickelt, die Software selbst aber stehen bleibt.

Unterlässt man die notwendigen Anpassungen an der Software, welche die

Entwicklungen aus den Umgebungen verlangen, veraltet das System ohne weiteres

Zutun.62

Abbildung 4: Lack of movement Quelle: (Bommer, Spindler, & Barr, 2008, S. 19)

Ignorant surgery ist die Verschlechterung der Architektur und des Designs einer

Software, die aus der Arbeit an dem Code von nicht kompetenten Personen herrührt.

So wird Code verändert oder geschrieben, der durch die ursprünglichen

Programmierer nicht mehr nachvollziehbar ist. Dadurch verschlechtert sich der

allgemeine Zustand der Software.63

Schlussendlich stellen sie fest, dass das Ziel der Softwarewartung nicht der Erhalt des

Originalzustandes einer Software ist, sondern das Herstellen eines neuen Zustands,

damit das System einsetzbar und nützlich bleibt.64





15

2.10 Finanzielle Gründe für ein Upgrade

Die technischen Gründe sind nur eine Art der Betrachtung. Auf der anderen Seite gibt

es natürlich auch die finanziellen Gründe, die die beiden Seiten, also Auftraggeber und

Auftragnehmer, zu einem Upgrade motivieren können.

Wartungskosten werden in der Regel eher als reine Kosten anstatt als Investitionen

verstanden, was sie grundsätzlich schon einmal unbeliebt macht.65 Trotzdem ist es

wichtig zu wissen, welche finanziellen Aspekte ein Upgrade begründen können.

Eine Art der Betrachtung ist die Softwareökonomie, also die Wirtschaftlichkeit eines

Systems. Diese ist nach Balzert anhand folgender Formeln zu ermitteln:

- Wirtschaftlichkeit = Erträge / Aufwendungen - Wirtschaftlichkeit = Leistung / Kosten - Wirtschaftlichkeit = Handlungsergebnisse / Mitteleinsatz

Die Wirtschaftlichkeit kann dabei auf verschiedene Arten verbessert werden. Man kann

das Softwareprodukt schneller entwickeln (Effizienzsteigerung), es so entwickeln das

es einen höheren ROI liefert oder für eine bessere Qualität sorgen.66 Gerade die

letzten beiden Punkte sind, wie oben beschrieben, technische Faktoren für ein

Upgrade. Verbessert sich also das Produkt technisch, hat dies auch positiven Einfluss

auf finanzielle Aspekte.

Ein laufendes System hat natürlich auch einen Wert. Dieser addiert sich über die Jahre

der Nutzung und steigt dementsprechend an. Mehr als 75 % des IT-Budgets von

Großbetrieben fließt dabei in die Erhaltung von Individualsoftware. Die Software bzw.

das System stellen damit einen großen Vermögenswert dar, den es zu sichern gilt. Die

Kosten sollten dabei im Verhältnis zum Vermögenswert stehen. Das Mindeste was ein

Unternehmen dabei jährlich aufbringen sollte, sind 15 % bis 25 % des

Gesamtumsatzes.67

Eine andere Herangehensweise wäre es zu fragen, was die Alternative zu einem

Upgrade ist. Da wäre zum einen die Neuentwicklung. Eine Softwareentwicklung ist

aber ein teures Vorhaben mit einem unbekannten Ausgang.68 Auch erreichen nur 50 %

der Projekte ihr Ziel und weniger als 20 % halten dabei Budget- und Zeitvorgaben

ein.69 Aber auch dies führt wieder zu einem System, welches erhalten werden muss.


66 (Balzert, 2008, S. 198-199)

67 (Sneed, Hasitschka, & Teichmann, 2005, S. 46)

68 (Sneed, Hasitschka, & Teichmann, 2005, S. 44)

69 (Standish Group, nach Sneed, Hasitschka, & Teichmann, 2005, S. 46)

16

Ein weiterer Weg wäre, nichts zu tun. Dies wurde aber bereits im Kapitel zuvor mit der

technischen Notwendigkeit begründet und wird daher nicht weiter betrachtet.

2.11 Aktueller Stand in der Literatur

Die aktuelle Sachlage von Vorgehensbeschreibungen im TYPO3-Bereich ist nicht

zufriedenstellend. Es gibt zwar einigermaßen aktuelle Literatur, jedoch beschränkt sich

diese auf eine sehr oberflächliche Beschreibung der erforderlichen Abläufe.70 Es

werden lediglich die notwendigsten Schritte beschrieben. Eine Betrachtung von

umliegenden Faktoren (Systemkontext) findet nur ungenügend statt. Auch Elemente,

wie in den vorherigen Kapiteln beschrieben, der Dokumentation oder beteiligte Rollen

werden nicht berücksichtigt. Leider ist die Literatur häufig veraltet71 und bezieht sich

auf von der neuesten Version 8.7 sehr abweichende Versionen wie die 4.5. Lediglich

die offizielle TYPO3-Dokumentation scheint etwas detaillierter und auch aktueller und

kann zumindest für die Konzeption in dieser Arbeit als valide Quelle herangezogen

werden.72 Sie ist dabei aber sehr technisch. Eine grafische Aufbereitung oder eine

Modellierung mithilfe einer Modellierungssprache konnte nicht gefunden werden.

70 (Meyer & Helmich, 2016, S. 364)


72 (TYPO3 Documentation Team, 2017)

17

3 Forschungsmethode

Die vorliegende Arbeit nutzt als Datenbasis zum größten Teil die geführten

leitfadengestützten Experteninterviews. Für die Erstellung des Vorgehens werden vor

allem induktive Rückschlüsse aus den Interviews gezogen und in den Prozess

eingearbeitet. Zusätzlich wird auch deduktiv unter Einfluss der Literaturrecherche

breites Wissen zum Themengebiet aufgebaut. Dazu zählen vor allem die TYPO3-

Sachbücher aber auch die Literatur aus den Bereichen Software-Wartung und

Software-Pflege. Aus den Bereichen Requirements Engineering und Web Engineering

werden auch Quellen verwendet. Wie eingangs erwähnt, sind die Interviews die größte

Informationsquelle und aufbauend auf diesen wird mit Hilfe der Modellierung mittels

BPMN 2.0 der Prozess aufbereitet.

Abbildung 5: Methodenspektrum der Wirtschaftsinformatik Quelle: (Hess & Wilde, 2006)

In Abbildung 5 wird das Methodenspektrum der Wirtschaftsinformatik mit Zuordnung in

verschiedene Bereiche abgebildet. Daraus lässt sich schließen, dass sich die Arbeit

eher als Referenzmodellierung verstehen lässt, vom Formalisierungsgrad eher

quantitativ ausgeprägt und das Paradigma von konstruktivistischer Art ist.73

73 (Hess & Wilde, 2006)

18

3.1 Leitfadengestütztes Experteninterview

Im dem Bereich des Requirements Engineering ist das Interview eine der gängigsten

Methoden um die Anforderungen eines Auftraggebers aufzunehmen.74 Die Autoren

Rupp und die Sophisten sagen sogar: „Manchmal kommt es uns so vor, als ob die

Industrie nur das Interview einsetzt.“75 Da für die Erstellung des Vorgehens für ein

Upgrade von TYPO3 eine Kombination aus bestehendem Wissen (in dieser Arbeit aus

der Literaturrecherche) und die sehr wichtigen Erfahrungen der Experten vonnöten

sind, scheinen Interviews hier besonders gut geeignet.

Das Interview selbst teilt sich dabei in drei Phasen. Die Vorbereitung, Durchführung

und Nacharbeit.76 Für die Vorbereitung eines solchen Interviews hat sich der

Interviewleitfaden bewährt.77 Die Autoren Krallmann, Schönherr und Trier

unterscheiden die Interviewmetode in standardisierte, verdeckte, offene und nicht-

standardisierte Interviews.78 Da beim nicht-standardisierten Interview die Reihenfolge

der Fragen beliebig ist, ist die in dieser Arbeit verwendete Methode am ehesten damit

zu vergleichen. Diese Methode kann von einer groben Struktur bis hin zu einem

Fragebogen variiert werden.

Für diese Arbeit wurde ein Leitfaden erstellt, der zum einen konkrete Fragen, zum

anderen Stichpunkte zum Lenken der Gespräche für den Fragensteller enthält (siehe

Anhang).

3.2 Erstellung des Interviewleitfadens

Der für diese Arbeit erstellte Leitfaden wurde dabei in drei Bereiche aufgeteilt

(Einstiegsfragen, Hauptfragen, Abschluss). Es wurden vor allem die Fragen gestellt,

die mittels der Literatur nicht beantwortet werden konnten und die sich auch in ihrer

Beantwortung auf die Erfahrung der Experten beziehen. Weiterhin sollten mittels der

Antworten auch die Erkenntnisse aus der Literaturrecherche bestätigt, wiederlegt oder

ergänzt werden. Am Ende der jeweiligen Kapitel wird erwähnt, welche Fragen in den

Leitfaden aufgenommen werden. Für die Interviews wurde ein Zeitrahmen von dreißig

Minuten angesetzt mit einem Puffer von weiteren dreißig Minuten, sodass ein Interview

maximal eine Stunde dauern sollte.

74 (Rupp & SOPHISTen, 2014, S. 105)




78 (Krallmann, Schönherr, & Trier, 2007, S. 155)

19

Insgesamt wurden für diese Arbeit zwei Leitfäden erstellt. Nach dem Interview der

ersten Person wurde festgestellt, dass die bisherigen Fragen noch nicht zu den

gewünschten Ergebnissen führten und das zusätzliche und auch genauere

Fragestellungen nötig waren. Die zweite Version des Leitfadens wurde dann nicht

mehr verändert. Version 1 des Leitfadens bestand dabei aus 26 Fragen und Version 2

aus 30 Fragen. Für einzelne Fragen wurde kein Zeitlimit festgelegt, um nicht in den

Redefluss der Interviewpartner eingreifen zu müssen.

Für die Art des Interviews wurde das persönliche Interview gewählt, um im Gespräch

flexibel reagieren zu können. Um eine gute Struktur und Identifikation zu

gewährleisten, wurden alle Fragen fortlaufend nummeriert. Im Anhang dieser Arbeit,

befinden sich zwei Versionen des erstellten Interviewleitfadens.

3.3 Auswahl der Interviewpartner

Für die zu führenden Interviews, mussten die richtigen Experten gewählt werden. Hier

stellte sich zunächst die Frage, was eine Person zum Experten macht. Nach Kaiser ist

das Expertenwissen an eine Funktion oder Berufsrolle gebunden.79 Für die Arbeit

bedeutet dies, dass hier vorrangig Personen befragt werden sollen, die TYPO3 aus

beruflichen Gründen benutzen. Die Zuschreibung der Expertenrolle erfolgt aber auch

immer durch den Forscher (in diesem Sinne dem Ersteller dieser Arbeit) selbst.80

Schlussendlich fasst Kaiser zusammen, dass ein Experte zum einen „…im weitesten

Sinne verantwortlich im Prozess der politischen Problemlösung.“ ist oder zum anderen

jemand der aus „…welchen Gründen auch immer – über relevantes Wissen über den

Prozess der politischen Problemlösung verfügt.“81 Diese Aspekte flossen in die

Auswahl der Experten ein. So sind alle Befragten aufgrund ihrer Position aktiv an der

Weiterentwicklung von TYPO3 beteiligt und beeinflussen dessen Entwicklung dadurch

unmittelbar.

Für die Auswahl der Interviewpartner dienten zum einen Gespräche mit dem

Zweitbetreuer dieser Arbeit, Sebastian Kreideweiß, der aufgrund seiner langjährigen

TYPO3-Erfahrungen und fortwährenden Engagements in der Community, einige

Personen benennen konnte, zum anderen aber auch bereits gemachte Erfahrungen im

TYPO3 Bereich und schlussendlich gefundene Autoren bei der Literaturrecherche.

79 (Kaiser, 2014, S. 36)

80 (Kaiser, 2014, S. 39)

81 (Kaiser, 2014, S. 41)

20

Eine besondere Herausforderung war es, die richtige Anzahl an zu befragenden

Experten zu wählen. Nach Kaiser ist vor allem die zeitliche Ressource für die Arbeit ein

wichtiger Faktor.82 Dies lässt aber keine Rückschlüsse auf die eigentliche Anzahl zu,

da hier keine konkrete Zahl genannt wird. Nach Gesprächen mit Herrn Kreideweiß,

schien eine Anzahl von drei bis fünf Personen angemessen für die Zielstellung und

Umfang dieser Arbeit. Die Option mehr als fünf Personen zu befragen wurde aber nicht

ausgeschlossen. Während des Interviewzeitraumes wurde regelmäßig überprüft, wie

sich die Datenlage darstellt und ob weitere als der geplanten Interviews vonnöten sein

würden. Alle Interviews wurden in einem Zeitraum von vier Wochen durchgeführt. Pro

Woche also nicht mehr also ein bis zwei. Um ein möglichst breites Spektrum an

Blickwinkel abzudecken, wurden Experten mit verschiedensten Schwerpunkten

befragt.

Aufgrund einer Absage wurde ein alternativer Interview-Kandidat angefragt der

kurzfristig zu einem Interview bereit stand. Durch terminliche Veränderungen konnte

das abgesagte Interview doch stattfinden. Durch diesen Umstand sind nun statt der

maximal fünf geplanten Personen insgesamt sechs Personen interviewt worden.

82 (Kaiser, 2014, S. 139)

21

Folgende Personen wurden interviewt:

Nr. Name TYPO3-

Erfahrung Funktion Interviewart

1 Nicole Cordes

Ca. 12 Jahre TYPO3-Core Entwicklerin,

Backend-Entwicklerin Persönlich

2 Wolfgang Wagner

Ca. 11 Jahre Integrator Skype

3 Helmut Hummel

Ca. 12 Jahre Freelancer, Backend-

Entwickler, TYPO3-Core Entwickler

Skype

4 Mathias

Schreiber Ca. 15 Jahre

Integrator, CEO TYPO3 GmbH, TYPO3 Product

Owner Skype

5 Thomas

Maroschik Ca. 15 Jahre

Senior TYPO3-Entwickler und Teilhaber DFAU GmbH,

TYPO3-Core Entwickler Slack

6 Philipp

Stranghöner Ca. 7 Jahre

Produktmanager Mittwald CM Service GmbH & Co. KG

Telefon

Tabelle 1: Interviewkandidaten

In der Tabelle 1 werden die sechs interviewten Personen aufgelistet. Hier zeigt sich

sehr klar, dass alle Befragten langjährige Erfahrungen mit TYPO3 vorweisen können.

Nicoles Cordes, Helmut Hummel und Thomas Maroschick sind nicht nur alle Core-

Entwickler mit verschiedenen Schwerpunkten, sondern haben auch alle

unterschiedliche Berufe. So ist Nicole Cordes in Festanstellung bei der CPS-IT GmbH,

wohingegen Helmut Hummel Freelancer ist. Thomas Maroschick ist Teilhaber und

Geschäftsführer. Wolfgang Wagner ist ein sehr erfahrener TYPO3-Integrator der

bereits seit vielen Jahren bei der Firma "jweiland.net“ sehr häufig TYPO3-Upgrades

durchführt. Phillip Stranghöner ist Produktmanager bei der „Mittwald CM Service

GmbH & Co. KG“ die als eine ihrer Kernprodukte ein speziell auf TYPO3 abgestimmtes

Hosting anbietet. Besonders hervorzuheben ist bei den Befragten Mathias Schreiber,

der momentane Product Owner von TYPO3 und Geschäftsführer der TYPO3 GmbH.

Aufgrund seiner Position nimmt er direkt Einfluss auf die Entwicklung von TYPO3 und

stellt somit eine Leitperson in diesem Bereich dar.

22

3.4 Auswertung der Interviews

In diesem Bereich gibt es eine erhebliche Anzahl von Möglichkeiten die sich je nach

wissenschaftlicher Disziplin unterscheiden.83 Für die Auswertung der Interviews wurde

eine qualitative Inhaltsanalyse durchgeführt. Für die qualitative Inhaltsanalyse werden

die aus den Interviews erstellten Texte als Material, in dem Daten enthalten sind,

betrachtet. Aus diesem Material wurden dann, mittels Reduktion, die Kernaussagen

extrahiert und die Daten im Anschluss ausgewertet. Ziel ist es, eine Informationsbasis

zu schaffen, die nur noch die Informationen enthält, die für die Beantwortung der

Forschungsfrage, in dieser Arbeit die Erstellung des Vorgehens für die Durchführung

des Upgrades, notwendig sind.84 Die folgende Abbildung 6 zeigt dieses Prinzip noch

einmal auf.

Abbildung 6: Prinzip der qualitativen Inhaltsanalyse Quelle: (Gläser & Laudel, 2010, S. 200)

Die Interviews wurden jeweils per Audio-Aufnahme aufgezeichnet, sodass ein späteres

Abhören jederzeit möglich war. Zusätzlich wurde während der einzelnen Interviews

jeweils ein Protokoll angefertigt. Die Protokolle wurden mithilfe einer Tabelle auf ihre

Kernaussagen reduziert und dann die Ergebnisse zusammengefasst, analysiert und

interpretiert. Die Tabelle zur Auswertung der gesammelten Daten befindet sich im

Anhang. Die Audio-Dateien befinden sich auf einer CD, als Teil des Anhangs, die

diesem Dokument beiliegt.

83 (Kaiser, 2014, S. 90)

84 (Gläser & Laudel, 2010, S. 199)

23

4 Ergebnisse

Im folgenden Kapitel werden die Ergebnisse aus den gesammelten Daten durch die

Interviews aufgezeigt. Das Vorgehen für ein TYPO3-Upgrade wird anhand von BPMN-

Modellen visualisiert. Erläuterungen dazu erfolgen im Text. Zu Beginn werden einige

Fragen aus den Interviews beleuchtet, die Erkenntnisse zu den Randbereichen des

TYPO3-Upgrades liefern.

4.1 Upgrade und Update aus Sicht der Experten

Innerhalb des Bereiches der Einstiegsfragen im Interviewleitfaden, wurde die Frage

gestellt, wo die Experten den Unterschied zwischen einem Upgrade und einem Update

sehen. Zwar wurde die Frage in den Grundlagen schon einmal theoretisch betrachtet,

es sollte aber herausgefunden werden, ob die Begriffe im TYPO3-Bereich auch so

verwendet werden.

Es stellte sich heraus, dass hier bei den Befragten eine sehr große Übereinstimmung

herrschte. Ein Update ist maximal ein Wechsel zwischen einer Minor-Version eher aber

zwischen einer Patch-Version. Es kommen keine neuen Features hinzu und es sollten

dadurch auch keine Inkompatibilitäten entstehen, da an den API nichts verändert

werden darf. Es werden dabei bekannte Probleme in bestehenden Funktionen

behoben. Im starken Gegenteil dazu steht das Upgrade. Hier ist ein Major-

Versionswechsel gemeint der bei TYPO3 immer ein Wechsel der LTS-Version darstellt.

Hier können API verändert werden, neue Funktionen hinzukommen, alte Funktionen

entfernt werden und sich auch ganze Workflows verändern. Solch ein Upgrade ist also

mit deutlich höheren Aufwänden und Anpassungen verbunden.

24

4.2 Gründe für ein Upgrade

Im Rahmen der Interviews sollte auch noch einmal geklärt werden, aus welchen

Gründen ein Upgrade überhaupt sinnvoll ist. So gab es hier einmal eine technische

sowie eine finanzielle Sicht. Verschiedenen Perspektiven (und damit auch Argumente)

durch Kunde und Agentur (bzw. Freelancer) spielen ebenfalls eine Rolle. Für Nicole

Cordes und Philipp Stranghöner ist ein wichtiger Grund, dass alte Systeme keine

Patches mehr erhalten und damit tendenziell immer unsicherer sind. Dies hat dann

auch negative Auswirkungen auf den Schutz der Daten im System und kann im

schlimmsten Fall in einen Image- und Kostenschaden für den Betreiber der Webseite

münden, z. B. durch einen Diebstahl von Nutzerdaten. Thomas Maroschik sieht hier

auch den Schutz der bisherigen Investitionen in das System. Nicht nur die Ausgaben

für das System selbst sind oft sehr hoch, auch die kontinuierlich anfallenden Kosten für

die Pflege des Contents steigern den Systemwert über die Nutzungsdauer hinweg. Um

diese Summen zu sichern, sollte ein Upgrade in regelmäßigen Abständen erfolgen.

Der Begriff „Technische Schulden“ fiel auch häufig. So ist es klar, sollte das System

nicht regelmäßig gepflegt werden, dass ein Upgrade dadurch in Zukunft nur komplexer

und aufwändiger werden kann. Ein gut gewartetes System, lässt sich einfacher pflegen

und auch dies hat positive Auswirkungen auf die Wartungskosten.

Es gibt jedoch noch näherliegende Konsequenzen aus einer vernachlässigten

Wartung. So erwähnte Wolfgang Wagner, dass die Browser mit denen TYPO3 genutzt

wird, sich ebenfalls weiterentwickeln und es dadurch vorkommen kann, dass das

TYPO3-Backend zum Pflegen der Seite nicht mehr genutzt werden kann, da ein

Problem mit der neuen Browser-Version auftritt.

4.3 TYPO3 und Metriken

Im Bereich der Softwarequalität und der Messung dessen, sind die Metriken wichtig. Es

sollte in den Interviews geklärt werden, inwieweit diese eine Rolle bei TYPO3 spielen

und welche Kennzahlen ob und wie in Betracht gezogen werden müssen.

Grundsätzlich wird dieser Bereich leider sehr vernachlässigt. Lediglich Helmut Hummel

konnte Aussagen dazu treffen. So gibt es ein Tool namens „SonarQube“ (OpenSource)

welches durch ihn Verwendung findet. Es wird zwar auch der TYPO3-Core gescannt,

laut Helmut Hummel werden die dort ermittelten Zahlen jedoch aktuell nicht

ausgewertet und spielen keine Rolle innerhalb der Entwicklung. Für seine Extensions,

25

z. B. die TYPO3Console, führt er aber regelmäßig Scans durch und optimiert seine

Programmierung auf Basis der Zahlen.

Abbildung 7: SonarQube Bericht für TYPO3-Core Quelle: (SonarQube, 2017)

Mathias Schreiber erwähnte Metriken jedoch auch als Motivationsmittel für die

Entwickler in seinem Team. So ist es z. B. mit der „time to fix“-Kennzahl möglich, eine

Motivation zu erzeugen hier der Schnellste zu sein.

Die anderen Befragten gaben an, keine Metriken zum Feststellen der Code-Qualität zu

nutzen. Thomas Maroschik erklärte dies damit, dass die Kunden noch nicht genug

geschult für den Umgang mit diesen Zahlen wären und es somit unnötig wäre, diese

aufzubereiten, da sie dann keine Verwendung fänden.

4.4 Akteure eines TYPO3-Upgrades

Bei einem Upgrade sind verschiedenen Personengruppen bzw. Akteure beteiligt. Im

Wartungsprozess nach Bommer, Spindler & Baar werden diese bereits beschrieben

und werden in der nachfolgenden Tabelle 2 aufgeführt. Es soll nun festgestellt werden,

wie diese Akteure im TYPO3-Umfeld benannt werden und welche Funktionen ihnen

zukommen. Die Aussagen der Experten hinsichtlich der beteiligten Rollen glichen sich

häufig. So sehen alle einen Kunden bzw. Nutzer des Systems (Redakteur). Die

Projektleitung kann hier auch eine spezielle technische Leitung sein oder einfach der

Kundenbetreuer. Dies hängt sehr von der Größe des Projektes und die personelle

26

Konstellation ab. Weiterhin beteiligt sind Integratoren, die einen Großteil der Aufgaben

während eines Upgrades übernehmen und in den Modellen häufig auftauchen. Der

Entwickler ist hauptsächlich für das Anpassen der Individual-Extensions zuständig,

kann aber auch Aufgaben der Integratoren übernehmen. Die Administration spielt vor

allem bei einem selbst gehosteten TYPO3-System eine Rolle, kann aber entfallen bei

der Nutzung eines externen Anbieters.

Über die TYPO3 Association ist es aktuell möglich, vier verschiedene Zertifikate zu

erlangen. Um eines der Zertifikate zu erhalten, ist es notwendig eine von der

Association organisierte Prüfung abzulegen. Für die verschiedenen Zertifizierungen

gibt es jeweils spezielle Prüfungen, die wissen aus dem jeweiligen Fachbereich

abfragen. 85

Aktuell sind folgende Zertifizierungen möglich:

- TYPO3 CMS Certified Editor (TCCE)86 - TYPO3 CMS Certified Integrator (TCCI)87 - TYPO3 CMS Certified Developer88 - TYPO3 CMS Certified Consultant89

In der folgenden Tabelle werden die Bezeichnungen von Bommer, Spindler & Baar den

Bezeichnungen der interviewten Experten und die der TYPO3 Association zugeordnet.

Bezeichnung nach Bommer,

Spindler & Baar

Bezeichnung der

Experten

Bezeichnung der

TYPO3 Association

Verifizierer, Validierer Kunde, Redakteur Certified Editor

Wartungsmanager,

Testmanager/Verifizierer,

Produktmanager, Validierer

Projektleitung /

Technische Leitung,

Kundenbetreuung

Certified Consultant

Wartungsingenieur/-mitarbeiter,

Konfigurationsmanager, Validierer

Integrator Certified Integrator

Wartungsingenieur/-mitarbeiter Entwickler,

Administrator

Certified Developer

Tabelle 2: Zuordnung der Rollen

85 (TYPO3 Association, kein Datum-f)

86 (TYPO3 Association, kein Datum-g)

87 (TYPO3 Association, kein Datum-h)

88 (TYPO3 Association, kein Datum-i)

89 (TYPO3 Association, kein Datum-j)

27

Es ist zu erkennen, dass im TYPO3-Bereich einige Akteure mehrfach belegt sind. Nach

Aussagen der Experten, erscheinen die in der zweiten Spalte aufgezeigten Rollen

jedoch als ausreichend um ein erfolgreiches Upgrade durchzuführen. Ganz

ausgelassen wurde hier der Qualitätsmanager. Eine gesonderte Rolle, welche für die

Einhaltung von Richtlinien oder anderen Qualitätsmerkmalen Sorge tragen könnte,

wurde von keinem Experten genannt. Die Fragen hinsichtlich der Code-Qualität

wurden zwar beantwortet, aber hier verlässt man sich auf Tools die bereits vorab für

eine erhöhte Code-Qualität sorgen. Einige dieser Tools werden im weiteren Verlauf

dieser Arbeit erwähnt und sind zum Teil in den erstellen Modellen wiederzufinden.

28

4.5 Phasen eines TYPO3-Upgrades

Abbildung 8: Phasenübersicht Quelle: Eigene Darstellung

Zu Beginn sollten die zu durchlaufenden Phasen eines TYPO3-Upgrades visualisiert werden. Die Aussagen der Experten wurden hierfür kombiniert

und das in Abbildung 8 gezeigte Phasenmodell konnte dadurch erstellt werden. Auffällig ist hier zu Beginn die zweimalige Angebotsphase. In der

Angebotsphase eins wird dabei ein Angebot für die Analysephase erstellt, die von Wolfgang Wagner auch als „Upgrade Check“ bezeichnet wird. Hier

soll bereits frühzeitig ermittelt werden, ob und wie ein Upgrade des TYPO3-Systems möglich ist. Die Erkenntnisse aus dieser Phase münden in

einem schlussendlichen Angebot für das Upgrade. Dieses wird innerhalb der Angebotsphase 2 erstellt.

Darauf folgt eine Vorbereitungsphase, um das bisherige TYPO3-System dann in die DEV-Phase und damit zum eigentlichen Upgrade zu führen.

Bereits hier lässt sich die Anwendung der Trennung der diversen Umgebungen erkennen, wie sie bereits vorab beim Release Management nach ITIL

empfohlen wurde. Hier wird zusätzlich zu den Umgebungen „Stage“ (häufig auch Test- oder QS-System) und Live (häufig auch „Production“) eine

DEV-Umgebung (DEV für „Development“) für die die jeweilig beteiligten Integratoren und Entwickler aufgezeigt. Es entsteht also ein Dreiklang aus

DEV-, Stage- und dem Livesystem. Das Letztere existiert dabei in der Regel nur einmal, wobei die DEV- und Stage-Systeme mehrfach existieren

29

können. Es folgen dann im Verlauf Rollout-Phasen und eine Abnahmephase, die das Vorgehen vollenden. In den nächsten Kapiteln werden die

einzelnen Phasen genauer beleuchtet und im Detail erläutert.

4.5.1 Angebotsphase 1

Abbildung 9: Angebotsphase 1 Quelle: Eigene Darstellung

Die erste Phase des Vorgehens ist die Angebotsphase 1. Am Ende dieser Phase soll die Agentur bzw. der Freelancer mit dem Kunden ein Angebot

und einen Zeitplan für eine Analysephase erstellt und abgestimmt haben. Eine Besonderheit stellt hierbei der Erstkontakt dar. So kann der Kunde aus

eigener Initiative heraus in Kontakt mit der Agentur oder dem Freelancer treten oder es kann auch andersherum der Erstkontakt aufgebaut werden. In

30

jedem Fall ist der Wille des Kunden notwendig, ein Upgrade seines Systems durchzuführen. Die in den vorherigen Kapiteln gesammelten Argumente

für solch ein Upgrade, liefern hierbei eine Hilfestellung. Im Verlauf der weiteren Diagramme wurden einheitliche Bezeichnungen für die Lanes

(einzelnen Bahnen) gewählt, sodass hier eine Wiedererkennung innerhalb der Arbeit gewährleistet wird.

4.5.2 Analysephase – Upgrade Check

Abbildung 10: Analysephase - Upgrade Check Quelle: Eigene Darstellung

31

Eine der wichtigsten Phasen ist die Analysephase. Wolfgang Wagner nennt dies auch

einen „Upgrade-Check“. Hier gilt es, gerade bei unbekannten Systemen, den

allgemeinen Systemzustand zu erfassen, um schon frühzeitig Probleme zu erkennen

um mit dem Kunden schon über Alternativen sprechen zu können.

Für die Befragten ist die Phase wegweisend. Einen Radikal anderen Weg geht hier

lediglich Mathias Schreiber. Er gibt an, bei den Aufwandsschätzzungen mit einer

pauschalen Kalkulation zu arbeiten. Pro im System aktiver Extension, ausgenommen

der System-Extensions, wird pauschal ein Aufwand von genau einem Manntag (acht

Stunden) veranschlagt. Er erläutert, dass dies eine Mischkalkulation sei und natürlich

auch ein Risiko darstellt, er aber aus seiner Erfahrung damit gut arbeiten konnte.

Bereits früh sollten die Zugänge zum System organisiert werden, damit eine

Bestandsaufnahme möglich ist. Viele einzelne Aktivitäten führen hier am Ende zu

einem Analysebericht, der auf der einen Seite die Grundlage für das Angebot des

Upgrades ist, aber auch schon eine Art Bauplan für das Upgrade selbst darstellt.

Innerhalb dieser Analyse kann auch ein Ergebnis sein, dass ein Upgrade nicht möglich

ist und ein anderer Weg für diese TYPO3-Installation eingeschlagen werden muss.

Dies könnte zum Beispiel eine Neuentwicklung mit der Migration der alten Daten sein.

In jedem Fall wird aber am Ende der Kunde über den Zustand des Systems informiert

und es wird bestimmt, was die notwendigen Schritte in der DEV-Phase sind. Der

Subprozess „TYPO3 analysieren“ wird im Folgenden noch einmal detaillierter

dargestellt.

32

Abbildung 11: TYPO3 analysieren Quelle: Eigene Darstellung

Abbildung 11 stellt den Subprozess „TYPO3 analysieren“ dar. Dieser ist ein Teilprozess der Analysephase. Hier zu sehen sind die vier notwendigen

Schritte um eine Aussage über den Zustand und dessen Upgrade-Fähigkeit tätigen zu können. Die bisherigen Dokumentationen sollten hierbei

Grundlage für diese Analyse sein und können wichtige Hinweise liefern. Im Folgenden werden die Teilprozesse „Extensions prüfen“, „TypoScript

prüfen“ und „Template-Konfiguration prüfen“ erläutert und auch als Modelle visualisiert. In dieser Grafik wie auch im allgemeinen Vorgehen wird

davon ausgegangen, dass der TYPO3-Kern, also alle Dateien die zur Lauffähigkeit von TYPO3 notwendig sind, nicht verändert wurden.

33

Abbildung 12: Extension prüfen Quelle: Eigene Darstellung

Als besondere Herausforderungen stellen sich im Upgrade-Verfahren, laut Aussage der Experten, immer die Extensions heraus. Im späteren Verlauf

dieses Kapitels, wird noch einmal erläutert, warum dies so ist, welche Extensions besonders häufig Probleme machen und was bewährte Methoden

zum Lösen dieser sind. In der Analysephase gilt es aber zunächst, die Probleme zu erkennen und schon Strategien zu entwickeln, um diese im

späteren Verlauf zu lösen. Grundsätzlich sollte zuerst geprüft werden, ob es inaktive Extensions gibt und ob alle aktiven Extensions auch wirklich

verwendet werden. Diese Extensions müssen dann natürlich nicht aktualisiert werden. Dies spart Zeit und Kosten. Ist die Extension dann daraufhin

geprüft, gilt es zu ermitteln, ob diese aktualisiert werden können, also ob kompatible Versionen für die geplante LTS-Version schon zu Verfügung

stehen. Ist dies nicht möglich, wäre eine alternative Extension zu ermitteln. Ist selbst dies nicht möglich, sollte hier Kontakt mit der Projektleitung

34

aufgenommen werden. Diese muss dann mit dem Kunden abstimmen, was getan werden kann. Für die Ermittlung der Aufwände helfen hier vor

allem sogenannte „RST-Dateien“ die Veränderungen am Core von TYPO3 dokumentieren und vom Core-Team seit Version 7.6 zur Verfügung

gestellt werden. Bisherige Changelogs sollten auch zu Rate gezogen werden um hier schlussendlich die Aufwandschätzung in den Bericht einfließen

lassen zu können.

Abbildung 13: TypoScript prüfen Quelle: Eigene Darstellung

Die Abbildung 12 zeigt den Teilprozess „TypoScript prüfen“ innerhalb der Analysephase. Die TypoScript-Konfiguration einer Installation sehen die

Experten als eher unproblematisch. Hier gab es in den letzten Jahren und somit auch in den letzten LTS-Versionen nur wenige Änderungen. Die

reine Systemkonfiguration per TypoScript kann in der Regel mit wenigen Anpassungen in das aktualisierte System überführt werden. Auch helfen

hier die TYPO3-Changelogs bei der Analyse.

35

Abbildung 14: Template prüfen Quelle: Eigene Darstellung

Das BPMN-Modell in Abbildung 14 zeigt den Teilprozess „Template-Konfiguration prüfen“ innerhalb der Analysephase. Besonders in diesem Bereich

hat sich, laut der Befragten, in den letzten Jahren doch einiges getan. Die Experten wurden hier expliziert gefragt, wie sie mit der Konfiguration in der

Datenbank umgehen, ob ein Umbau auf eine sogenannte Sitepackage-Extension oder Fluid Styled Content ratsam ist. Um für die Zukunft keine

technischen Schulden anzuhäufen sind die Aussagen der Interviewten doch recht ähnlich. Die Konfiguration aus der Datenbank sollte möglichst

versioniert werden. Ein Auslagern der Konfiguration auf Dateiebene wird ebenfalls empfohlen. Zu diesem Zweck nennen alle Befragten das VCS-Tool

„Git“. Auch eine sitepackage-Extension90, in der die gesamte Konfiguration eine Webseite gekapselt wird, ist laut der Interviewten ratsam. Da das alte

CSS Styled Content (###-Marker in Templates) bereits seit Version 6 deprecated, also veraltet, ist und auch aus dem Core entfernt wurde (wird nur

90 (Kott, 2015)

36

noch als Extension angeboten aber nicht mehr gepflegt), sollte dies auf das moderne und zukunftsfähige Fluid Styled Content umgebaut werde. Die

Aufwände hierfür, sollte in diesem Schritt eingeschätzt werden. Mit dieser Maßnahme sind die TYPO3-Analyse und somit auch die Analysephase

abgeschlossen.

4.5.3 Angebotsphase 2

Abbildung 15: Angebotsphase 2 Quelle: Eigene Darstellung

37

Die Abbildung 15 zeigt die Angebotsphase 2. Mithilfe des Analyseberichts der

vorherigen Phase kann dem Kunden nun mitgeteilt werden, in welchem Kosten und

Zeitrahmen das Upgrade durchgeführt werden kann. Wichtig ist, in diesem Schritt

schon einen sogenannten „Redaktionsstop“ (von Philipp Stranghöner und Helmut

Hummel auch „Content Freeze“ genannt) zu vereinbaren. Dort wird ein Zeitraum

definiert, in dem der Kunde (oder seine Redakteure) keine Veränderungen mehr am

Content vornehmen, damit ein Upgrade mit aktuellsten Daten durchgeführt werden

kann. Alternativ ist es laut Thomas Maroschik zwar auch möglich, die Daten von einem

definierten Zeitpunkt an nachzupflegen oder parallel zwei Systeme zu pflegen, dies ist

jedoch deutlich aufwändiger. Da das schlussendliche Einrichten auf dem Live-Server

deutlich schneller als die DEV- und Stage-Instanz ablaufen sollte, können diese

Zeiträume geringgehalten werden. Stimmt der Kunde dem Angebot und Zeitplan zu,

geht es in die Vorbereitungsphase.

4.5.4 Vorbereitungsphase

Abbildung 16: Vorbereitungsphase Quelle: Eigene Darstellung

In der Vorbereitungsphase aus Abbildung 16, soll das System eingerichtet und soweit

wie möglich von Altlasten gesäubert werden. Besonders Wolfgang Wagner legt auf die

Phase Wert und äußert sich umfangreich. Zu Beginn muss eine lauffähige Version des

Systems ermöglicht werden. Dafür ist es notwendig einen Datenbank- und

Dateisystemabzug des gesamten TYPO3-Sytems zu organisieren. Dafür muss

entweder die interne Administration oder der externe Anbieter angesprochen werden.

Sind die Daten da, ist es Aufgabe der Integration ein lauffähiges System zu

ermöglichen. Um eine effiziente DEV-Phase zu ermöglichen, sollte die Installation nun

zunächst bereinigt werden. Dies wird im folgenden Teilprozess „TYPO3-cleaning

durchführen“ erläutert.

38

Abbildung 17: TYPO3-cleaning durchführen Quelle: Eigene Darstellung

Die obige Abbildung 17 zeigt den vor die DEV-Phase gelagerten Teilprozess „TYPO3-cleaning durchführen“ im Detail. Zunächst sollte einmal

sichergestellt werden, dass alle unwichtigen Extensions für den Upgrade-Prozess deaktiviert und entfernt worden sind. Je weniger, desto einfacher

werden die nächsten Schritte. Der sogenannte Referenzindex des FAL (File Abstraction Layer) des TYPO3-System, der die Metainformationen von

Dateien in der Datenbank organsiert, sollte hier zunächst einmal gesäubert werden. Relationen könnten über die Nutzungsdauer des Systems

hinweg verwaist sein. Auch die Log-Einträge in der Sys-Historie werden nicht mehr benötigt. Grundsätzlich werden in TYPO3 keine Daten gelöscht,

sondern zunächst als gelöscht in der Datenbank markiert. Diese markierten Daten können aber nun final gelöscht werden. Auch wichtig ist hier zu

überprüfen, ob die Datenbank bereits UTF-8-konform ist. Ältere TYPO3-Installationen sind noch häufig in latin_swedish_ci. Dies könnte zu

Problemen mit Umlauten führen. Die Vorbereitungen sind nun abgeschlossen und es beginnt nun, in der nächsten Phase, das eigentliche Upgrade.

39

4.5.5 DEV-Phase

Abbildung 18: DEV-Phase Quelle: Eigene Darstellung

40

Die Kernphase, das Upgrade in DEV-Umgebung, zeigt die Abbildung 17. In dieser

Phase wird innerhalb einer DEV-Instanz (lokale Kopie der Integration oder

Entwicklung) das Upgrade auf technischer Ebene durchgeführt. Zunächst sollten hier

alle Extensions deaktiviert werden, um Konflikte zu vermeiden. Die TER-Extension, die

Extension, die also keine Individual-Entwicklungen darstellen, sollten von der

Integration aktualisiert werden.

Der aufgeklappte Teilprozess „TER-Extension aktualisieren“ verdeutlicht dies.

Individual-Extensions müssen von der Entwicklung angepasst werden, da hierfür in der

Regel Programmierkenntnisse vonnöten sind. Nach der Aktualisierung der Extensions

kann der Systemkern durch einen neuen ersetzt werden und die nachfolgenden

Schritte im InstallTool durchgeführt werden.

Hier kann auch mithilfe von Composer oder der Extension „TYPO3-Console“ gearbeitet

werden. Dazu mehr im Bereich „Wichtige Tools bei einem Upgrade“ in einem

folgenden Kapitel dieses Dokumentes. Diese Schritte werden nun so lange

durchlaufen, bis die aktuellste bzw. die gewünschte TYPO3-LTS-Version erreicht ist.

Wichtig danach ist, entweder eine vorhandene Dokumentation zu aktualisieren oder

eine neue zu erstellen. Oftmals wird hier aber laut der Interviewten leider darauf

verzichtet. Wenn jedoch die Dokumentation gut gepflegt ist, erleichtert dies ein

zukünftiges Upgrade.

Die beiden Teilprozesse „Konfiguration anpassen“ und „Individual-Extension

aktualisieren“ werden im weiteren Verlauf der Arbeit erläutert. Besonders die

Aktualisierung der Individual-Extension stellt eine Herausforderung während eines

solchen Upgrades dar und ist auch laut Aussagen der Experten, der häufigste Grund

für Verzögerungen im Prozess und kann zum Teil mit hohen Kosten für den Kunden

verbunden sein.

41

Abbildung 19: Konfiguration anpassen Quelle: Eigene Darstellung

Der Teilprozess aus Abbildung 19 läuft innerhalb der DEV-Upgrade-Phase. Die zuvor in der Analysephase ermittelten Informationen bilden hier die

Grundlage für das weitere Vorgehen. Wie bereits vorher beschrieben, sollte hier das System auf eine sitepackage-Extension und auf Fluid Styled

Content umgebaut werden. Auch die eventuell vorhandene Konfiguration aus der Datenbank sollte ihren Weg in das Dateisystem finden und auch

sogleich in ein VCS (Version Control System) wie GIT hinzugefügt werden, um eine Historie der Konfigurationsdaten zu ermöglichen. Alle befragten

Experten sind große Befürworter und Anwender von GIT und empfehlen hier den Einsatz.

42

Abbildung 20: Individual Extension aktualisieren Quelle: Eigene Darstellung

Ein großer Anteil der Arbeit bei einem Upgrade von TYPO3 kommt der Entwicklung zu, wie in Abbildung 20 als Teilprozess der DEV-Phase,

aufgezeigt. Die Befragten empfehlen hier zunächst eine Umstellung auf das mittlerweile sehr weit verbreitete Extbase-Framework im Gegensatz zu

dem älteren pibase. Neue Entwicklungsparadigmen und ein zukunftsfähigerer Ansatz sind hier gute Argumente. Nicole Cordes weist aber an dieser

Stelle darauf hin, dass dies kein Zwang ist, da auch pibase basierte Extensions weiterhin funktionieren können. Aus der Perspektive der technischen

Schulden sollte dies jedoch vermieden werden. Besonders die Deprecations (als veraltet markierte Funktionen) sollten nun gelöst werden. Im

nächsten Schritt kann mithilfe von RST-Files und der IDE „PhpStorm“ ein Scan mit den RST-Files vorgenommen werden. Auch der darauffolgende

Schritt wird mit PhpStorm und einem Plugin bewältigt. Am Ende sollte auch hier die vorhandene Dokumentation aktualisiert oder eine neue erstellt

werden.

43

4.5.6 Stage-Rollout-Phase

Abbildung 21: Stage-Rollout-Phase Quelle: Eigene Darstellung

44

Durch die Trennung in eine Stage- und Liveinstanz ist ein zweimaliger Rollout des in

der DEV-Umgebung gebauten Upgrades notwendig. Den Rollout auf die Stage-Instanz

beschreibt die Abbildung 21. Hier kommt nun eine weitere wichtige Komponente ins

Spiel, der Systemkontext, also der Server bzw. das Hosting der Installation. Da auch

hier Upgrades der Software durchgeführt werden müssen (LTS-Versionen haben

unterschiedliche Anforderung an diese) ist ein rechtzeitiges Beauftragen bzw.

Durchführen notwendig. Je nachdem ob self-hosted oder ein Dienstleister genutzt wird.

Bereits in der Analysephase sollte geklärt worden sein, wie dies möglich ist.

Das Gateway „Server bereits aktualisiert?“ hat einen Pflichtpfad auf der Lane

„Integration“, sodass, auch wenn der Server bereits aktualisiert wurde, die Aktivitäten

ab „Release erstellen“ notwendig werden. Die Aktivitäten nach dem komplexen

Gateway sind Kandidaten für eine Automatisierung durch Deployment-Systeme.

Während der Interviews sollte auch ermittelt werden, an welchen Stellen dies möglich

ist.

Besonders die Befragten Mathias Schreiber und Helmut Hummel nutzen bereits

intensiv solche Systeme und empfehlen deren Verwendung. Phillip Stranghöner teilte

mit, des weniger als 1 % der Hosting-Kunden von Mittwald CM Service GmbH & Co.

KG Composer nutzen und auch sehr wenige automatisiertes Deployment. Sollte dies

aber zum Einsatz kommen, würde das Tool „Capistrano“ genutzt werden. Nach dem

Hochladen und Aktivieren folgt als nächstes die Testphase / Abnahmephase.

45

4.5.7 Testphase / Abnahmephase

Abbildung 22: Testphase / Abnahmephase Quelle: Eigene Darstellung

46

Die Benennung dieser Phase ist bewusst so gewählt, spiegelt sie nur so die Aussagen

der befragten Experten am besten wieder. In Abbildung 22 wird der Prozess des

Testens und Abnehmens der Arbeiten vom Kunden gezeigt. Da der Kunde sein

System am besten kennen sollte, gehen die Befragten davon aus, dass auch nur

dieser hier für einen vollständigen Test des Systems sorgen kann. Zwar wird erwähnt,

dass natürlich in den vorherigen Phasen auch schon diverse Test der Programmierung

erfolgen sollten, aber das inhaltliche Zusammenspiel kann am besten derjenige

bewerten, der das System regelmäßig nutzt. Diese Tests stellen nun zeitgleich auch

die Abnahme und somit die Freigabe der Änderungen dar. Sollten hier nun Fehler

auftreten, läuft der Sequenzfluss zurück in die DEV-Phase, wo diese in der Regel

behoben werden müssen.

Wolfgang Wagner weist hier darauf hin, dass geprüft werden muss, ob ein gemeldeter

Fehler tatsächlich ein Bug oder eher eine Änderung bzw. eine Neuerung („Feature

Request“) ist. Hier kommt nun auch noch einmal in Vorbereitung auf die „Live-Rollout-

Phase“ die genaue Absprache für einen Redaktionsstopp zum Tragen. Denn nun muss

dieser genau fixiert werden und auch ein Termin für den Live-Rollout muss gefunden

werden. Für den Live-Rollout gibt es dabei verschiedene Strategien.

Thomas Maroschik erwähnte die Möglichkeit, dass bereits aktualisierte Stage-System

zum neuen Live-System zu konfigurieren. Dies ermöglicht einen schnellen Wechsel

und kann so mit wenig Risiko vollzogen werden. Dies ist aber nicht immer technisch

möglich. Der häufigere Weg wird, nach Aussage der Experten, der sein, dass auch

noch einmal ein Rollout und eine Einrichtung auf dem Live-Server vollzogen werden.

47

4.5.8 Live-Rollout-Phase

Abbildung 23: Live-Rollout-Phase Quelle: Eigene Darstellung

48

Die nun letzte Phase des Vorgehens ist mit der Live-Rollout-Phase in Abbildung 23

erreicht. Gleich zu Beginn muss nun der vereinbarte Redaktionsstopp durchgeführt

werden. Ähnlich wie in der Stage-Rollout-Phase muss sich nun zunächst um den

Server bzw. das Hosting gekümmert werden. Auch hier ist der Pflichtweg der über die

Integration und die Erstellung und Aktivierung des Release. Am Ende des Prozesses

findet die letzte Abnahme durch den Kunden statt und das System ist nun

vereinbarungsgemäß aktualisiert worden.

4.6 Häufige Probleme bei einem Upgrade

Während der Interviews stellte sich heraus, dass die Individual-Extensions während

eines Upgrades am häufigsten die Ursache für Probleme sind. So kommt es vor, dass

diese nicht dokumentiert sind oder während ihrer Nutzungsdauer im System nicht

gepflegt worden sind. Wolfgang Wagner stellt fest, dass ein System deutlich einfacher

zu aktualisieren ist, wenn dort wenige Extensions dieser Art genutzt werden.

Trotzdem geben die Experten auch an, dass auch die TER-Extension durchaus

potential für Probleme bieten. So nennt auch hier Wolfgang Wagner als Beispiel die

Extensions „ws_flexslider“91 und „Templavoila!“92. Erstgenannte wird genutzt um einen

Bilder-Slider auf der Webseite darzustellen. So berichtet er, dass anscheinend bei

dieser Extension der Upgrade-Pfad nicht sauber implementiert wurde, sodass bei

einem Upgrade oftmals die vorher konfigurierten Bilder verloren gehen und diese dann

manuell nachgepflegt werden müssen. Thomas Maroschik nennt bei dieser Frage die

Extension Templavoila. So wurde die für neue TYPO3-Versionen nur schlecht gepflegt

und es gab aus seiner Erfahrung heraus häufig Schwierigkeiten damit. Er fasste

zusammen, dass jede Extension, die keinen modernen Entwicklungsparadigmen folgt,

früher oder später zu einem Problem werden wird.

4.7 Wichtige Tools bei einem Upgrade

Während der Interviews war es besonders interessant zu klären, welche Tools wie und

wofür eingesetzt werden, um einen Upgrade-Prozess zu vereinfachen bzw. überhaupt

zu ermöglichen.

So konnte hier ganz klar an der Spitze die IDE „PhpStorm“ von Jetbrains genannt

werden, die von jedem der Befragten eingesetzt wird. Durch ihre Vielseitigkeit und die

einfache Erweiterung mithilfe von Plugins, scheint diese aktuell der beliebteste IDE zu

91 (Wappler, 2017)

92 (TYPO3 Release Team, 2015)

49

sein. Innerhalb dieser IDE kommen dann die Plugins der Firma „sgalinski Internet

Services“ zum Einsatz. So entwickelt diese Firma ein Fluid-Plugin welches Features

wie eine Autovervollständigung, Fehlererkennung und Syntax-Highlighting für die

Templating-Sprache Fluid mit sich bringt. Das zweite Plugin ist das TypoScript-Plugin,

welches ähnliche Features für die Nutzung von TypoScript ermöglicht.

Mathias Schreiber nennt hier auch noch das Plugin „Php Inspections (EA Extended)“

welches ermöglicht, den PHP-Code von Individual-Extensions zu analysieren um

dadurch die Qualität des geschriebenen Codes zu erhöhen.

Von allen eingesetzt wird auch die Versionsverwaltung mithilfe von GIT. Das

Versionieren von Code und Konfiguration wird hier auch von den Experten empfohlen.

Besonders für Philipp Stranghöner ist die TYPO3-Extension „TYPO3Console“ wichtig.

Die von Helmut Hummel entwickelte Extension, ermöglicht es, diverse Aufgaben die in

TYPO3 anfallen, per Konsole (bzw. Terminal) auszuführen und ist damit die Grundlage

für eine Automatisierung. Er berichtet, dass diese Extension unter anderem dafür

eingesetzt wird, bei einem Upgrade bestimmte Steps im InstallTool auszuführen. In

dem BPMN-Modell aus Abbildung 18 wurde mittels Kommentaren kenntlich gemacht,

wo diese Extension im Vorgehen eingesetzt werden kann.

4.7.1 Fehlende Tools

Um auch eine Erkenntnis zu liefern, wo noch Bedarf für weitere Tools zur Hilfe bei

einem Upgrade benötigt wird, wurden die Experten dahingehend befragt. Die häufig

erwähnten RST-Files helfen zwar zu erkennen, an welchen Stellen es bei einem

Upgrade zu Problemen kommen kann, jedoch ist das Lösen dieser immer noch

Aufgabe der Entwickler. So wünschen sich hier Philip Stranghöner und Mathias

Schreiber eine Anwendung, die hier gleich auch Lösungsvorschläge bietet oder besser

noch, diese gleich anwendet. Da viele der Aufgaben mechanischer Natur sind, wäre

zumindest ein Teil davon durch Programme lösbar.

Thomas Maroschik beschreibt den Wunsch, nach einer abstrakten Sprache mit deren

Hilfe man ein Upgrade beschreiben kann. Sodass z. B., ähnlich wie bei „Gherkin

Language“, Prozesse mit natürlicher Sprache beschrieben werden können.

Eine Lücke kann hier aber schon die kommende Version 9 füllen. So ist für diese laut

Mathias Schreiber einen sogenannter „extension scanner“ für das InstallTool

umgesetzt worden, welches ein automatisches Abgleichen der Extension im System

50

mit den schon seit Version 7 gepflegten RST-Files ermöglicht. Laut Roadmap erscheint

die finale Version des 9er-Zweigs am 2. Oktober 2018.93

4.8 Zukunft von TYPO3 und Konsequenzen für Upgrades

Um eine Idee davon zu bekommen, wo die Entwicklung mit dem CMS TYPO3

hingehen kann und was auf diesem Weg beachtet werden sollte, wurde als Letztes

jeder der Experten befragt, was er sich von TYPO3 für die Zukunft wünscht. Die Frage

wurde im Interview offen formuliert. Die Idee war jedoch, festzustellen ob sich über die

Zukunftswünsche der Befragten, Richtungen und damit auch Konsequenzen für

zukünftige Upgrade-Prozesse ergeben. Da alle Befragten direkten Einfluss auf die

Entwicklung von TYPO3 nehmen, können über diese Aussagen Entwicklungen

abgeleitet werden. Dies diente dem Zweck, der Erhöhung der Nachhaltig dieser Arbeit.

Im Folgenden werden die Aussagen aufgezeigt und am Ende der Absätze werden

daraus Konsequenzen abgeleitet.

Als Entwicklerin wünscht sich Nicole Cordes einen gewissenhafteren Umgang mit den

Versionsnummern nach Maßgabe der semantischen Versionierung. Dies wurde in der

Vergangenheit vom Core-Team nicht immer eingehalten und es gab auch Breaking-

Changes innerhalb von Minor-Versionen. Sollte sich also dieser Wunsch durchsetzen

würde dies besonders für Updates, eine Verringerung der Komplikationen mit sich

bringen.

Für Wolfgang Wagner ist es besonders wichtig, dass die stark verwendete Extension

„realurl“ (ermöglicht sprechende-URLs) in den TYPO3-Core aufgenommen wird und

dadurch besser gepflegt wird. Mit der Extension „mask“ (ermöglicht das Generieren

von Custom-Content-Elementen) sieht er es ebenso. Er möchte auch betonen, dass

bei aller Professionalisierung wichtig ist, die TYPO3-Anfänger nicht zu vergessen. Eine

weitere Aufnahme von aktuell gesonderten Extensions in den TYPO3-Core scheint bei

den beiden genannten sinnvoll. Zu beachten ist aber auch, mit Steigerung der

Basisfunktionalitäten könnten auch zukünftige Upgrade-Prozesse komplizierter

werden.

Helmut Hummel empfiehlt einen stärkeren Fokus auf Systemstabilität zu legen aber

auch das User-Interface von TYPO3 sukzessive zu verbessern. Auch das bisherige

Fremdsprachenhandling sieht er als Handicap. Redakteuren sollte die Nutzung so weit

wie möglich weiter vereinfacht werden.

93 (TYPO3 Association, kein Datum-d)

51

Mathias Schreiber legt hier den Fokus auf die Professionalisierung des Produktes

TYPO3 aber auch der Community. Er sieht hier nicht die Notwendigkeit mit dem

Blogsystem „Wordpress“ zu konkurrieren. Er sieht TYPO3 als ehrliches Produkt und

möchte dies auch so fortführen.

Thomas Maroschik wünscht sich für das Core-Team mehr Entwickler. Aber auch er

sieht die Notwendigkeit sich weiter zu professionalisieren. Die Fokussierung von

Helmut Hummel auf Stabilität und die von Mathias Schreiber und Thomas Maroschik

auf Professionalität lassen zwar keine direkten Rückschlüsse zu, aber hier liegt die

Vermutung nahe, dass auch diese Ausrichtungen eher positive Einflüsse auf zukünftige

Upgrades haben werden.

Philipp Stranghöner ist sehr zufrieden mit der bisherigen Arbeit der TYPO3 GmbH und

wünscht sich eine Fortsetzung des eLTS-Programmes (kostenpflichtiger verlängerte

Support für ältere LTS-Versionen). Der Service im TYPO3-Bereich sollte weiter

verbessert werden. Die Verlängerung der ELTS-Versionen für 6.2 und 7.6 ist schon

bekannt (siehe Abbildung 2). Für den eigentlichen Upgrade-Prozess hat dies keine

direkten Auswirkungen.

4.9 Diskussion der Ergebnisse

Die durchgeführten Interviews mit den Experten, erwiesen sich als eine gute Quelle,

um ein Vorgehen für ein Upgrade zu entwickeln und entsprachen daher größtenteils

den Erwartungen. Im Zusammenspiel mit den gesammelten Erkenntnissen aus dem

Bereich der theoretischen Grundlagen, und hier vor allem die Erkenntnisse aus der

ITIL und dem Wartungsprozess nach Bommer, Spindler und Barr, konnten detaillierte

Modelle erstellt werden. Auch die Phasen, die vor dem eigentlichen Upgrade stehen,

konnten mithilfe der Schilderungen modelliert werden. Es zeigt sich doch, wie

umfangreich ein Upgrade sein kann und wie viele verschiedene Rollen an diesem

beteiligt sind. Ein Upgrade spielt somit eine wichtige Rolle, innerhalb des

Softwarelebenszyklus einer Applikation und sollte nicht unterschätzt werden.

Bemerkenswert ist der noch sehr geringe Einsatz von Automatisierungswerkzeugen.

Die Annahme war hier, dass diese Tools bei den Befragten bereits eine viel wichtigere

Rolle spielen. Lediglich Helmut Hummel und Mathias Schreiber sprachen von einer

regelmäßigen Anwendung. Warum dies so ist, blieb leider ungeklärt, es könnte aber

die Vorlage für eine weitere Untersuchung sein.

Ein größerer Teil der theoretischen Grundlagen beschäftigte sich mit der Qualität von

Software. Auch dies war Teil der Interviews. Leider stellte sich hier heraus, dass wenig

52

mit Softwaremetriken und Tools zu Erfassung dieser, bei den Experten gearbeitet wird.

Die Absicht war, aufzuklären welche der beschriebenen Qualitätsmerkmale aus dem

Kapitel Softwarequalität hier wie beeinflusst werden. Es wird durch die Experten zwar

häufig erklärt, dass die Erhöhung bzw. Verbesserung der Qualität ein wichtiger Aspekt

eines Upgrades ist, aber es blieb offen, wie dies genau festgestellt wird. Es scheint nun

zwar klar, dass mit dem Upgrade des TYPO3-System eine Erhöhung der Qualität

einhergeht, an welchen Stellen, blieb aber größtenteils unklar. Die gewählte

Forschungsmethode scheint hier auch nicht die geeignetste zu sein. Eine mögliche

Untersuchung wäre hier, für die verschiedenen TYPO3 LTS-Versionen mit Hilfe eines

Tools wie z. B. SonarQube unterschiedliche Kennzahlen zu erfassen und diese

gegenüber zu stellen. Diese Kennzahlen könnten dann den jeweiligen Qualitätsarten

zugeordnet werden und es könnte schlussendlich eine Aussage getroffen werden, ob

und wie sich die Qualität von TYPO3 verbessert oder auch verschlechtert hat.

Ein weiterer Kritikpunkt sind die Akteure bzw. Rollen eines Upgrades. Zwar herrschte

bei den Befragten doch eine relativ große Einigkeit über die zum Einsatz kommenden

Personen aber es liegt die Vermutung nahe, dass man zwar Begriffe wie Integrator und

Entwickler nutzt, diese jedoch teilweise unterschiedlich verstanden werden. Eine erste

Hilfe stellt hier die gemachte Gegenüberstellung in der Tabelle 2 im Kapitel Akteure

eines TYPO3-Upgrades dar. In den Modellen resultiert aber daraus eine gewisse

Unschärfe bei den Bezeichnungen der einzelnen Lanes ohne Zuhilfenahme dieser

Tabelle. Besonders in Abbildung 12 wird dies deutlich. So wird hier die Einschätzung

des Aufwandes für Individual-Extension, nach Befragung der Experten, durch einen

Integrator vorgenommen. Nach aktueller Definition der TYPO3 Association scheint hier

der Developer (Entwickler) dafür besser geeignet, da dieser ein umfangreiches

Verständnis für geschriebenen Code mitbringen muss. Eine Einschätzung von einem

Entwickler würde hier demnach belastbarer sein.

Auch die Aussagen hinsichtlich der Nutzung von Dokumentationen sind entgegen der

Annahme, dass diese ein wichtiges und häufig genutztes Hilfsmittel sind. Hoffnung

macht aber, dass zumindest alle Befragten erkennen lassen, zumindest zum Teil, dies

häufiger einzusetzen. Für eine Person, die nun unmittelbar vor einem solchen Upgrade

steht, liefern die erstellten Modelle eine gute Hilfestellung. Es muss hierbei jedoch klar

gesagt werden, dass zwar in den Modellen teilweise Abbruchbedingungen

berücksichtigt wurden, es jedoch bei einem solchen Vorhaben zu einer Vielzahl von

weiteren Problemen kommen kann. Insofern können die Modelle nur einen Teil der

Wirklichkeit abbilden und stellen hier das ideale Vorgehen dar.

53

5 Fazit

Die vorliegende Arbeit befasste sich mit der Frage, wie ein Vorgehen für das Upgrade

von TYPO3 aussehen kann. Es lässt sich erkennen, dass ein solches Vorgehen

entwickelt und somit die Forschungsfrage beantwortet wurde.

Im ersten Kapitel geht es um die grundlegende Motivation und was zu gestellten

Forschungsfrage führte. Auch der Aufbau der Arbeit und die zu erwartende Struktur

wird hier aufgezeigt.

In Kapitel 2 wurden die theoretischen Grundlagen für die Auseinandersetzung mit dem

Thema geschaffen. Zu Beginn wird hier definiert was TYPO3 ist und es wird

aufgezeigt, wie hoch der Verbreitungsgrad ist. Es wird weiterhin darüber Auskunft

gegeben, welche Budgetgrößen bei einem TYPO3-Projekt erwartet werden können.

Auch die Begriffe LTS und ELTS werden besprochen und zuletzt wird dargelegt,

welche weitere Software für den Betrieb von TYPO3 notwendig ist. Um für Klarheit und

eine Einordnung für die Begriffe Update und Upgrade zu sorgen, wurde versucht dies

über die vorhandene Literatur zu beantworten. Es zeigte sich, dass dies nicht

ausreicht. Zu Beginn der Recherche, nach vorhandenen Vorgehensbeschreibungen für

ein Upgrade für TYPO3, stellte sich schnell heraus, dass diese meist sehr einfach

gehalten sind und auch keine Hilfestellung bei auftretenden Problem bieten.

Im weiteren Verlauf des Kapitels 2 wurde das durch die ITIL definierte Release

Management dargestellt. Auch die Definition von Qualität und dann genauer auch der

Softwarequalität wurde durchgeführt. Anschließend wurde der grundlegende

Wartungsprozess nach Bommer, Spindler, & Barr aufgezeigt und außerdem wurde

klargemacht, welche Konsequenzen eine vernachlässigte Wartung nach sich zieht. Am

Ende des Kapitels wurde einmal aus technischer und einmal aus finanzieller Sicht

begründet, warum eine regelmäßige Wartung und damit auch ein Upgrade notwendig

ist.

Kapitel 3 ordnet die Arbeit im Methodenspektrum der Wirtschaftsinformatik ein und

klärt darüber auf, dass das leitfadengestützte Experteninterview die Datengrundlage für

die spätere Erstellung von geplanten grafischen Modellen bildet. Für die Auswertung

der Interviews wird sich der qualitativen Inhaltsanalyse bedient. Es wird auch

aufgezeigt, wie der verwendete Interviewleitfaden erstellt wurde und wie die Wahl auf

die befragten Experten fiel. Aus den Interviews sollten dann Erkenntnisse extrahiert

werden, die es ermöglichen, ein Vorgehen zu entwickeln.

54

Das vierte Kapitel widmet sich der Darstellung der Forschungsergebnisse. Das

Vorgehen selbst, wurde mithilfe der BPMN modelliert und visualisiert. Es sind dabei

sechzehn Modelle erstellt worden, die zusammen das komplette Vorgehen

beschreiben. Das erste Modell aus Abbildung 8 zeigt dabei auf, welche grundlegenden

acht Phasen im Prozess zu erwarten sind. Im nächsten Schritt, von Abbildung 9 bis

Abbildung 23, werden die einzelnen Modelle mit ihren Prozessen und Teilprozessen

aufgezeigt. Die Modelle wurden weiterhin textlich beschrieben um hier für so wenig wie

möglich Missverständnisse zu sorgen. Zuletzt sollte auch noch aufgezeigt werden,

welche Tools ein Upgrade unterstützen können und wo Bedarf für weitere besteht. Die

bestehenden Tools waren:

- PhpStorm mit weiteren Plugins - Git - Die Extension „TYPO3console“

Weiterhin war es wichtig, zu beleuchten aus welchen Gründen ein Upgrade zu

empfehlen ist und was die Konsequenzen aus einem vernachlässigten System sind. Es

wurde aufgezeigt, dass eine vernachlässigte Wartung zur Anhäufung von sogenannten

technischen Schulden führt und auch das negative Auswirkungen auf Sicherheit und

Funktionsweise zu erwarten sind. Auch die Kostenfrage und somit die finanzielle Sicht

wurde betrachtet. Das Anwenden des Vorgehens sollte unabhängig von der

zugrundeliegenden TYPO3-Version ermöglicht werden. Auch sollte hier der

Systemkontext, bestehend aus dem Server-System, betrachtet und berücksichtigt

werden.

Auch zu welchem Zeitpunkt im Prozess, welcher Akteur eine Rolle spielt wurde

aufgezeigt. Die nach Bommer, Spindler, & Barr benannten und definierten Akteure

wurden den Rollenbeschreibungen der Experten und der offiziellen Definition der

TYPO3 Association zugeordnet.

Schwierig war es, die unterschiedlichen Perspektiven der Experten für die Modelle in

Einklang zu bringen. Aufgrund der verschiedenen Nutzungsweisen von TYPO3

entstehen hier natürlich auch unterschiedliche Perspektiven. Mithilfe der strukturierten

Auswertung konnten die verschiedenen Kernaussagen aber gut zusammengeführt

werden.

Durch das Befragen der Experten, welche Tools bzw. Programme sie für ein Upgrade

nutzen, konnten weitere nützliche Erkenntnisse in die Modelle einfließen. So wird vor

allem auch die Unterteilung in DEV-, Stage- und Live-System berücksichtigt und

gezeigt, wie diese im Vorgehen eine Rolle spielen. Auch Hilfsmittel wie die

55

TYPO3Console oder auch die RST-Files des Core-Teams werden beschrieben und

wurden in die Modelle integriert.

Im letzten Teil des vierten Kapitels wurden die Experten nach den Zukunftswünschen

für TYPO3 befragt. Es wurde dabei auch untersucht, ob sich aus diesen Aussagen

eine Relevanz für den Upgrade-Prozess ableiten lässt. Am Ende wurden die

Ergebnisse noch einmal diskutiert und kritisch betrachtet.

Die Empfehlung für eine zukünftige wissenschaftliche Arbeit lautet, dass vorliegende

Vorgehen innerhalb eines Upgrade-Prozesses anzuwenden um dieses zu überprüfen

und gegebenenfalls zu verbessern. Die Konfiguration und die Kombination aus TYPO3,

Extension und Server unterliegen einer so starken Schwankung, dass hier nicht

sichergestellt werden kann, dass alle Installationen nach diesem Vorgehen

aktualisierbar sind.

I

6 Abkürzungsverzeichnis

API. Application Programming Interface

BPMN. Business Process Model and Notation

CMS. Content Management System

CSS. Cascading Style Sheets

DEV. Development

FAL. File Abstraction Layer

GNU. GNU’s Not Unix

IEEE. Institute of Electrical and Electronics Engineers

ITIL. IT-Service-Management

LAMP. Linux, Apache, MySQL, PHP

LTS. Long Term Support

PHP. PHP: Hypertext Preprocessor

RST. reStructuredText

TER. TYPO3 Extension Repository

VCS. Version Control System

II

7 Literaturverzeichnis

Abts, D., & Mülder, W. (2017). Grundkurs Wirtschaftsinformatik. Wiesbaden: Springer

Fachmedien.

Balzert, H. (2008). Lehrbuch der Softwaretechnik: Softwaremanagement (2 Ausg.).

Heidelberg: Spektrum Akademischer Verlag.

Bergman, S., & Priebsch, S. (2010). Softwarequalitat in PHP-Projekten [Digg - eZ

Components - studiVZ - swoodoo - symfony - TYPO3 - Zend Framework.

München: Hanser.

Bommer, C., Spindler, M., & Barr, V. (2008). Softwarewartung Grundlagen,

Management und Wartungstechniken (1 Ausg.). Heidelberg: dpunkt.Verlag

GmbH.

Casteleyn, S., Daniel, F., Dolog, P., & Matera, M. (2009). Engineering Web

Applications. New York: Springer.

CMSCrawler. (17. Oktober 2017). CMSCrawler. Abgerufen am 17. Oktober 2017 von

http://www.cmscrawler.com/tool/

CMSCrawler. (17. Oktober 2017). CMSCrawler. Abgerufen am 17. Oktober 2017 von

http://www.cmscrawler.com/country/DE

Cunningham, W. (26. März 1992). The WyCash portfolio management system.

Abgerufen am 20. Oktober 2017 von http://c2.com/doc/oopsla92.html

Frömken, S. (30. April 2012). Abgerufen am 17. Oktober 2017 von TYPO3Wiki:

https://wiki.typo3.org/De:Fluid

Gabler Wirtschaftslexikon. (kein Datum-a). Update. (S. G. Verlag, Herausgeber)

Abgerufen am 20. Oktober 2017 von Gabler Wirtschaftslexikon:

http://wirtschaftslexikon.gabler.de/Archiv/76911/update-v10.html

Gabler Wirtschaftslexikon. (kein Datum-b). Update. Abgerufen am 20. Oktober 2017

von Gabler Wirtschaftslexikon:

http://wirtschaftslexikon.gabler.de/Archiv/76927/upgrade-v9.html

Gläser, J., & Laudel, G. (2010). Experteninterviews und qualitative Inhaltsanalyse : als

Instrumente rekonstruierender Untersuchungen (3 Ausg.). Wiesbaden: VS

Verlag für Sozialwissenschaften.

III

Hess, T., & Wilde, T. (2006). Methodenspektrum der Wirtschaftsinformatik: Überblick

und Portfoliobildung. München: Institut für Wirtschaftsinformatik und Neue

Medien der Ludwig-Maximilians-Universität München.

Jenkins Webseite. (kein Datum). Jenkins User Documentation. Abgerufen am 24.

Oktober 2017 von https://jenkins.io/doc/

Kaiser, R. (2014). Qualitative Experteninterviews Konzeptionelle Grundlagen und

praktische Durchfuhrung. Wiesbaden: Springer VS.

Köhler, P. (2007). ITIL (Bd. 2). Heidelberg: Springer.

Kott, B. (09. Mai 2015). The Anatomy of TYPO3 Sitepackages. Abgerufen am 05.

Januar 2018 von speakerdeck.com: https://speakerdeck.com/benjaminkott/the-

anatomy-of-typo3-sitepackages

Krallmann, H., Schönherr, M., & Trier, M. (2007). Systemanalyse im Unternehmen (5

Ausg.). München: Oldenbourg Wissenschaftsverlag GmbH.

Krause, M. (17. Dezember 2016). T3census : TYPO3 census. Abgerufen am 17.

Oktober 2017 von http://t3census.info

Lobacher, P., & Krell, V. (2013). 100 Tipps für TYPO3 CMS. München: Open Source

Press.

Meyer, R., & Helmich, M. (2016). Praxiswissen TYPO3 CMS7 LTS. Heidelberg:

O'Reilly.

php.net. (kein Datum). Abgerufen am 17. Oktober 2017 von

http://php.net/manual/de/preface.php

Preston-Werner, T. (18. Juni 2013). Abgerufen am 17. Oktober 2017 von semver.org:

http://semver.org/

Rees, D. (2016). PHP: Composer. Wales, England: Leanpub.

Rupp, C., & SOPHISTen. (2014). Requirements-Engineering und - Management - Aus

der Praxis von klassisch bis agil (6. Ausg.). Carl Hanser Verlag.

Sneed, H. M., Hasitschka, M., & Teichmann, M.-T. (2005). Software-Management (1

Ausg.). Heidelberg: dpunkt.verlag GmbH.

IV

SonarQube. (23. November 2017). Abgerufen am 24. November 2017 von

https://sonarcloud.io/dashboard?id=typo3

Thomas, S. (2001). HTTP essentials : protocols for secure, scaleable, Web sites. New

York: Wiley.

TYPO3 Association. (kein Datum-a). About the name. Abgerufen am 17. Oktober 2017

von typo3.org: https://typo3.org/about/the-brand/about-the-name/

TYPO3 Association. (kein Datum-b). Association. Abgerufen am 17. Oktober 2017 von

typo3.org: https://typo3.org/association/

TYPO3 Association. (kein Datum-c). Key Features. Abgerufen am 27. Oktober 2017

von typo3.org: https://typo3.org/typo3-cms/key-features/

TYPO3 Association. (kein Datum-d). Roadmap. Abgerufen am 05. Januar 2018 von

typo3.org: https://typo3.org/typo3-cms/roadmap/

TYPO3 Association. (kein Datum-e). System Requirements. Abgerufen am 17. Oktober

2017 von typo3.org: https://typo3.org/typo3-cms/overview/requirements/

TYPO3 Association. (kein Datum-f). About the certification. Abgerufen am 12. Januar

2018 von typo3.org: https://typo3.org/certification/about-the-certification/

TYPO3 Association. (kein Datum-g). TYPO3 CMS Certified Editor (TCCE). Abgerufen

am 12. Januar 2018 von typo3.org: https://typo3.org/certification/certified-editor/

TYPO3 Association. (kein Datum-h). TYPO3 CMS Certified Integrator (TCCI).

Abgerufen am 12. Januar 2018 von typo3.org:

https://typo3.org/certification/certified-integrator/

TYPO3 Association. (kein Datum-i). TYPO3 CMS Certified Developer. Abgerufen am

12. Januar 2018 von typo3.org: https://typo3.org/certification/certified-

developer/

TYPO3 Association. (kein Datum-j). TYPO3 CMS Certified Consultant. Abgerufen am

12. Januar 2018 von typo3.org: https://typo3.org/certification/certified-

consultant/

TYPO3 Documentation Team. (23. Oktober 2017). Abgerufen am 27. Oktober 2017

von typo3.org - Installation and Upgrade Guide:

https://docs.typo3.org/typo3cms/InstallationGuide/

V

TYPO3 Dokumentation. (24. August 2017). Abgerufen am 17. Oktober 2017 von

https://docs.typo3.org/typo3cms/InstallationGuide/latest/In-

depth/SystemRequirements/

TYPO3 Extension Repository. (kein Datum). TYPO3 Extension Repository. Abgerufen

am 20. Oktober 2017 von https://extensions.typo3.org/

TYPO3 GmbH. (09. August 2017). Abgerufen am 05. Januar 2018 von typo3.com:

https://typo3.com/services/extended-support/

TYPO3 GmbH. (21. August 2017). Abgerufen am 05. Januar 2018 von typo3.com:

https://typo3.com/company/

TYPO3 Release Team. (20. Juni 2015). TemplaVoila! Abgerufen am 05. Januar 2018

von TYPO3-TER: https://extensions.typo3.org/extension/templavoila/

TYPO3 YouTube Channel. (28. Juli 2017). YouTube - Interview - Release

Management Benni Mack, Benjamin Kott. Abgerufen am 17. Oktober 217 von

https://www.youtube.com/watch?v=Aadd-L1D7po

TYPO3Wiki. (25. Oktober 2016). Composer. Abgerufen am 05. Januar 2008 von

TYPO3Wiki: https://wiki.typo3.org/Composer

Wappler, S. (02. Oktober 2017). Flexslider. Abgerufen am 05. Januar 2018 von

TYPO3-TER: https://extensions.typo3.org/extension/ws_flexslider/

Webkalkulator. (17. Oktober 2017). CMS Vergleich. Abgerufen am 17. Oktober 2017

von http://www.webkalkulator.com/cmsvergleich

Weiland, J. (2017). Versionen und Updates. jweiland.net. Abgerufen am 25. Oktober

2017 von https://jweiland.net/typo3/versionen-und-updates.html

Wikipedia - Flow Framework. (12. Mai 2017). Flow Framework. Abgerufen am 17.

Oktober 2017 von https://de.wikipedia.org/wiki/Flow_Framework

VI

8 Abbildungsverzeichnis

Abbildung 1: Umsatz für Webprojekte nach Marktsegmenten 4

Abbildung 2: Roadmap 5

Abbildung 3: Deploy von getesteten Releases auf Test- und Produktivsystem 10

Abbildung 4: Lack of movement 14

Abbildung 5: Methodenspektrum der Wirtschaftsinformatik 17

Abbildung 6: Prinzip der qualitativen Inhaltsanalyse 22

Abbildung 7: SonarQube Bericht für TYPO3-Core 25

Abbildung 8: Phasenübersicht 28

Abbildung 9: Angebotsphase 1 29

Abbildung 10: Analysephase - Upgrade Check 30

Abbildung 11: TYPO3 analysieren 32

Abbildung 12: Extension prüfen 33

Abbildung 13: TypoScript prüfen 34

Abbildung 14: Template prüfen 35

Abbildung 15: Angebotsphase 2 36

Abbildung 16: Vorbereitungsphase 37

Abbildung 17: TYPO3-cleaning durchführen 38

Abbildung 18: DEV-Phase 39

Abbildung 19: Konfiguration anpassen 41

Abbildung 20: Individual Extension aktualisieren 42

Abbildung 21: Stage-Rollout-Phase 43

Abbildung 22: Testphase / Abnahmephase 45

Abbildung 23: Live-Rollout-Phase 47

VII

9 Tabellenverzeichnis

Tabelle 1: Interviewkandidaten 21

Tabelle 2: Zuordnung der Rollen 26

VIII

10 Anhang

- Interviewleitfaden 1

- Interviewleitfaden 2

- Interview 1 bis 6

- Kernaussagen aus Interview mit Interviewleitfaden 1

- Kernaussagen aus Interviews mit Interviewleitfaden 2

- Gemeinsamkeiten und Interpretationen aus Interviews

Anhang

i

Interviewleitfaden 1

Einstiegsfragen

1. Seit wann arbeitest du mit TYPO3? 2. Warum arbeitest du mit TYPO3? 3. Was machst du hauptsächlich mit TYPO3? (Entwickler, Integrator, …)? 4. Beschreibe bitte kurz deine berufliche Karriere. 5. Wo siehst du den Unterschied zwischen einem Update und einem Upgrade?

Hauptfragen

6. Warum sollte man sein TYPO3-System regelmäßig upgraden? • 6a: Finanzielle Gründe? • 6b: Technische Gründe? • 6c: Aus Sicht der Kunden und Agenturen?

7. Hast du schon selbst ein Upgrade durchgeführt oder warst daran beteiligt? (Wenn ja wie oft?) 8. Was genau hast du dabei gemacht? 9. Wie würdest du bei einem Upgrade vorgehen bzw. gehst du vor?

• 9a Fragen zum Server-Upgrade • 9b: Fragen zu Problemen mit Extensions? (Häufige Probleme und wie man

diese lösen kann) • 9c: Fragen zu Problemen mit der Konfiguration • 9d: Fragen zu Konfiguration in der Datenbank (Immer auslagern?) • 9e: Fragen zu Stage-, Dev- und Live-System (Immer notwendig? Idealzu-

stand?) • 9f: Was ist auf Kundenseite zu beachten? (Redaktionsstop) • 9g: Was ist auf Agenturseite zu beachten?

10. Was hältst du bei einem Upgrade für besonders schwierig? (Was für besonders einfach?) 11. Wie beurteilst du den Einfluss auf ein Upgrade durch neue Ansätze wie Composer und automatisierten Deployment? 12. Welche Tools unterstützen dich bei einem Upgrade?

• 12a: Gibt es noch Bedarf für weitere Tools? • 12b: Wie könnten diese aussehen?

Abschlussfragen

13. Gibt es noch etwas, was vergessen wurde anzusprechen? 14. Was wünschst du für die Zukunft von TYPO3?

Anhang

ii

Interviewleitfaden 2

Länge: 30min (+30min Puffer) Personen: 3 - 5 Informationen

• Kurze Vorstellung • Zielsetzung erklären

• Forschungsfrage: Wie kann ein ideales Vorgehen für ein TYPO3 Up-grade aussehen?

• Bisherige Erkenntnisse erklären • Upgrades meist im Sinne von “Tausche Core aus, gehe in das

InstallTool” • Wozu dient dieses Interview (Beantwortung der Forschungsfrage, schreiben der

BA)

Einstiegsfragen

1. Seit wann arbeitest du mit TYPO3? 2. Warum arbeitest du mit TYPO3? 3. Was machst du hauptsächlich mit TYPO3? (Entwickler, Integrator, …)? 4. Beschreibe bitte kurz deine berufliche Karriere. 5. Wo siehst du den Unterschied zwischen einem Update und einem Upgrade?

Hauptfragen

6. Warum sollte man sein TYPO3-System regelmäßig upgraden? • 6a: Finanzielle Gründe? • 6b: Technische Gründe? • 6c: Aus Sicht der Kunden und Agenturen?

7. An welchen Zahlen könnte man belegen, dass ein Upgrade sinnvoll ist? (Metriken) 8. Hast du schon selbst ein Upgrade durchgeführt oder warst daran beteiligt? (Wenn ja wie oft?) 9. Was genau hast du dabei gemacht? 10. Siehst du dabei verschiedene Phasen ablaufen? 11. Wie würdest du bei einem Upgrade vorgehen bzw. gehst du vor?

• 11a Fragen zum Server-Upgrade • 11b: Fragen zu Problemen mit Extensions (Häufige Probleme und wie man

diese lösen kann) • 11c: Fragen zu Problemen mit der Konfiguration • 11d: Fragen zu Konfiguration in der Datenbank (Immer auslagern?) • 11e: Fragen zu Stage-, Dev- und Live-System (Immer notwendig? Idealzu-

stand?) • 11f: Was ist auf Kundenseite zu beachten? (Redaktionsstop) • 11g: Was ist auf Agenturseite zu beachten?

12. Was hältst du bei einem Upgrade für besonders schwierig? (Was für besonders einfach?) 13. Wie unterstützen dich bei einem Upgrade vorhandene Dokumente und wo im Pro-zess spielen diese für dich eine Rolle? (Aktualisierung von Dokumenten) 14. Welche Akteure bzw. Rollen siehst du an so einem Upgrade beteiligt? 15. Wie beurteilst du den Einfluss auf ein Upgrade durch neue Ansätze wie Composer und automatisierten Deployment? 16. Welche Tools unterstützen dich bei einem Upgrade?

• 16a: Gibt es noch Bedarf für weitere Tools?

Anhang

iii

• 16b: Wie könnten diese aussehen?

Abschlussfragen

17. Gibt es noch etwas, was vergessen wurde anzusprechen? 18. Was wünschst du für die Zukunft von TYPO3?

Anhang

iv

Interview 1

Länge: 45 Min.

Anwesende Personen: Sammy Baghdadi, Nicole Cordes

Einstiegsfragen

1. Seit wann arbeitest du mit TYPO3?

Seit zwölf Jahren, durchgehend, seit der Ausbildung

2. Warum arbeitest du mit TYPO3?

Der Ausbilder hat es eingesetzt, aktueller Arbeitgeber

3. Was machst du hauptsächlich mit TYPO3? (Entwickler, Integrator, …)?

Backend-entwicklung, extensions, core

4. Beschreibe bitte kurz deine berufliche Karriere.

Ausbildung, ein Jahr Malta, durchgehend bei CPS

5. Wo siehst du den Unterschied zwischen einem Update und einem Upgrade?

- Update, Veränderung in minor oder bugfix version

- Upgrade auf die Major-Version

Hauptfragen

6. Warum sollte man sein TYPO3-System regelmäßig upgraden?

● 6a: Finanzielle Gründe?

○ Verlieren nur Geld dadurch

○ Verursachen Kosten beim Kunden durch Anpassungen

● 6b: Technische Gründe?

○ Sicherheit -> TYPO3-Framework -> Konzepte

○ Core-Api wird robuster

○ Sicherheit des Datenschutzes erhöht -> Session, Verschlüsselung

● 6c: Aus Sicht der Kunden und Agenturen?

○ […]

7. Hast du schon selbst ein Upgrade durchgeführt oder warst daran beteiligt?

(Wenn ja wie oft?)

Ja

Anhang

v

8. Was genau hast du dabei gemacht?

Mehrere Aspekte, für die Firma

- Genutzte Extension aktualisieren

- Privat alles

9. Wie würdest du bei einem Upgrade vorgehen bzw. gehst du vor?

● 9a: Fragen zum Server-Upgrade

○ Hängt davon ab was man kann

○ Managed-Server, je nachdem welche Rechte da sind

○ Die PHP-Version aktualisieren, Apache dann gleich

○ Muss ich jemanden damit beauftragen? Provider machen das von sich

aus

○ Pakete aktualisieren wie ImageMagick

○ Aktualisierung nicht notwendig, seit 4.5

● 9b: Fragen zu Problemen mit Extensions? (Häufige Probleme und wie

man diese lösen kann)

○ Mittlerweile sehr gering, Core-Team, zwischen den Versionen räumen

wir die API grundlegend auf

○ TYPO3-Funktionen ändern sich

○ TCA-Optionen angepasst

○ pibase nach wie vor verwendbar

○ Was hat sich geändert

■ RST-Dateien für die groben Veränderungen (deprecated)

■ docs.typo3.org -> changelog

○ Extension in ein neues Projekt packen, zum herausfinden

● 9c: Fragen zu Problemen mit der Konfiguration

○ TypoScript bleibt gleich

○ neue Sachen kommen hinzu

○ Aktuelle Projektform wichtig -> Aktualisierung auf neue Standards

durchführen

● 9d: Fragen zu Konfiguration in der Datenbank (Immer auslagern?)

○ Beides gleich

○ Vorteil auf Dateiebene -> kann in Versionskontrolle

○ Performanter in der Datenbank

○ Template Extension trotzdem sinnvoll, nicht zu klein splitten

● 9e: Fragen zu Stage-, Dev- und Live-System (Immer notwendig? Idealzu-

stand?)

○ Keines der beiden Systeme

○ In lokaler Kopie das Upgrade durchspielen

○ Lokale Umgebung -> Erfolg -> Stage

○ Stage aktualisieren -> Kunde kann abnehmen

■ Kopie von Live anlegen

■ Server tauschen

Anhang

vi

○ Kunde arbeitet Live weiter -> Redaktionsstop -> TYPO3 nicht mehr zu-

gänglich machen

● 9f: Was ist auf Kundenseite zu beachten? (Redaktionsstop)

○ Kunde dafür zuständig

● 9g: Was ist auf Agenturseite zu beachten?

○ Falsche Kalkulation

○ Man muss nur unterscheiden ob man nur Upgrade verkauft

○ Relaunch kann denn Zeitplan beeinflussen

○ Budget aufgebraucht

10. Was hältst du bei einem Upgrade für besonders schwierig? (Was für

besonders einfach?)

- Aufwändige Projekte mit Minor-Version anfangen, wenn nicht LTS

- Große Struktur

- Viel Konfigurationsaufwand

- Extension -> form engine grundlegend geändert -> tca

11. Wie beurteilst du den Einfluss auf ein Upgrade durch neue Ansätze wie

Composer und Automatisierten Deployment?

- Man kann auch auf Kommandozeile aktualisieren

- Eigenentwicklungen bleiben kompliziert

- Einfach nur ein anderer Weg

12. Welche Tools unterstützen dich bei einem Upgrade?

- PhpStorm zum analysieren

- Depecration Log

- Extension-Scanner in der 9er Version

- Analyse vorm aktualisieren wichtig

- Upgrade Wizard

- Sammelt einzelne Wizards zusammen

- Database analyser

- Neue Felder, neue Indexe, Typ Änderung

- Migrierung

- Wizards kommen vom Core

● 12a: Gibt es noch Bedarf für weitere Tools?

○ Vorschau auf die nächste Version aus dem Tool

○ Fehler der Reihe nach beheben

○ Analyse = Upgrade-Prozess

○ Funktionsscan mit PhpStorm

○ Analyse während des Upgrades

● 12b: Wie könnten diese aussehen?

○ […]

Anhang

vii

Abschlussfragen

13. Gibt es noch etwas, was vergessen wurde anzusprechen?

- Nur der Anfang ist individuell

- Du weißt was da ist

- Dokumentation immer wichtig zwischen den Steps, was hat man wann und wie

gemacht

- Templates könne sich verändert haben

- Fluid templates

- Ausgabe anpassen

- Css styled content, kein fluid

- Css styled content auf fluid styles

- Viel über TypoScript

- Fluid styled content

- Css styled content noch verwendbar

- Kommt aus dem Core raus -> depecrated

- Eigentlich willst du migrieren -> Umstellen von css_sty-

led_content auf fluid_style_content ratsam

- Da muss man an die Datenbank, Inhaltselemente

haben sich geändert

- CompatibilityLayer Extension

- In 4.6 zu 6 wuden Klassen genamspaced

- Klassen wurden gealiased

- ist mit 7.6 rausgeflogen

- Damit würde es gehen

- Problem als Betreiber entweder hast du ext (und nutzt alles) oder nicht

- Dann macht sie alles

- Kommt drauf an was in der Extension steckt

- Bootstrap von TYPO3 hat sich geändert

- Zusätzliches Angebot um Aufwand zu sparen

- Oftmals braucht man nur ein feature aus der ext

- Andere Extensions wissen nicht das der da ist

- Lieber die Migration

14. Was wünschst du für die Zukunft von TYPO3?

- Besserer Umgang mit den Versionsnummern

- Minor releases die breaking sind

- 9.0 ist breaking

- Eigentlich nur Update zwischen den Versionen

Anhang

viii

Interview 2

Länge: 60 Min.

Anwesende Personen: Sammy Baghdadi, Helmut Hummel

Einstiegsfragen


10 Jahre seit Core-Liste, 12 Jahre


Anderes OpenSource Projekt -> floppyisdn4linux für Router

Über das Projekt das erste CMS was ihn überzeugte

Kompliziert aber Cool


5 Jahre Freelancer, Trainings & Workshops, Backend-Entwicklung mit PHP für TYPO3


Quereinsteiger bei Bitmotion angestellt


- Update: Bugfix -> einfach

- Upgrade: Major-Version, Minor -> komplexer

- TYPO3-Team definiert es so

Hauptfragen


- Allgemeiner fassen -> Warum Software upgraden

- Webplattform sieht er gleich mit Software


○ Hack protection

○ Image Schaden oder Finanziellen Schaden präventieren


○ Neue Features

Anhang

ix

○ Es wird besser

○ Bestimmte Versionen der Software werden nicht mehr supported


○ Stressfreier und günstiger Upgrades regelmäßig machen

○ Kommt auf die Wichtigkeit der Webseite an

7. An welchen Zahlen könnte man belegen, dass ein Upgrade sinnvoll ist?

(Metriken)

- (Sonar)Qube erstellt Metriken für PHP und JS

- Wurde eingerichtet (Christian Travold)

- Wurde für TYPO3 wieder gestartet typo3.sonarqube.io

- Konsequente Auswertung findet noch nicht statt

- Er macht es für seine Extension

- Müsste in CI-Worklfow integriert werden (Gerrit) (violation)


(Wenn ja wie oft?)

- Ja, regelmäßig

- Ist schon etwas länger her, zur Agenturzeiten, es steht eines an

- 4.5 auf 6.2 für einen größeren Kunden, da steht 6.2 auf 8.7


- Überblick verschafften, Aufbau der Installation

- Alles was nicht gebraucht wird rausschmeißen

- Alle nicht aktiven Extensions wegwerfen

- Aktive Extensions auch prüfen ob diese genutzt werden

- Als zweites, was könnte noch Probleme machen

- Entwickler Komponenten entfernen

- Wie viele Template-Datensätze sind da

- Reduzieren und in Dateien auslagern

- Checkliste wäre sinnvoll

- Weitergehen reindex, deleted löschen, history löschen -> alle redundanten und

“”” Daten löschen -> cli kommandos

10. Siehst du dabei verschiedene Phasen ablaufen?

- Statusaufnahme - Ist

- Aufräumen

- Abzug vom Stand in Testumgebung (Code Migration)

- Aufsetzen in alter Version

- Dann upgrade durchführen (Core austauschen)

- Alle Extensions soweit aktualisieren wie möglich

Anhang

x

- Upgrade wizards -> schauen was kaputt ist

- Schritt für Schritt Extension aktivieren

- Fehler beheben

- Alternative:

- Tools die einem sagen was kaputtgehen wird

- Testsystem

- Alle Dateien in Versionskontrolle

- Ein Tool was weiß was sich zwischen den Versionen geändert

hat -> PHPCode scannen

- 4.5 smooth migration wizard -> Backend und CLI

- Datenmigration (Datenbank)

- Konfigurationsupgrade



○ Eventuell kennt der Betreiber nicht die Requirements von TYPO3

○ Zuerst Infrastruktur Upgrade (also Server)

○ Von der 4.5 muss man immer auf die 6.2

○ Da ändert sich die PHP-Plattform nicht

○ 6.2 auf 7.6 kann noch mit PHP 7 (6.2 geht nicht mit 7)

○ Ab 7.6 hat man nicht mehr das Plattform Problem

○ 7.6 wird auch mit PHP 7.2 laufen

○ Besser von 6.2 auf die 8



○ Private API Extension bekommen Probleme

■ Was ist PrivateAPI? Unterschiedlich

○ Xclasses sind immer ein Problem

■ Ich kann auf PHP-Ebene Klassen von TYPO3 austauschen

■ Parentclass wird definiert überschreibt einen von TYPO3

■ Methoden können überschrieben werden

■ Wenn sich Methoden stark geändert haben wird es schwierig

■ Ungeplante Erweiterbarkeit

■ Technische Schuld


○ […]


○ Kommt auf die Zeit an

○ Wird immer empfohlen

○ Kann man auch schon in der alten Installation machen

○ Man hat den Vorteil das man es versionieren kann

○ Was habe ich in welchen Schritten geändert


stand?)

○ Dev-System -> lokale Kopie auf dem System des Entwicklers

○ Geshared des Dev-System hält er nicht viel

Anhang

xi

○ Staging oder Integrationsystem -> Neue Projektstände teilbar machen

■ PL und Kunde

■ Davon vielleicht sogar mehrere

■ Ist auch ein Abnahmesystem idealerweise

○ Ohne weitere Änderungen vom Stage auf Live


○ “Betreuende Partei” die den Kunden unterstützt

○ Kosten und Zeit müssen eingeplant werden

■ Budget muss da sein

■ Arbeitskraft muss da sein

■ Entscheidungen müssen getroffen werden

■ Hoster bzw. IT muss auch angewiesen werden

■ Es entstehen immer Aufwände

○ Es besteht dann aber auch immer die Chance interne Prozesse zu ver-

bessern (Aufräumphase)

○ Timing muss stimmen

○ Welcher Stand wir migriert (Datenbank)

■ Content Freeze (Redaktionstopp) vereinbaren


○ […]


besonders einfach?)

[…]

13. Wie unterstützen dich bei einem Upgrade vorhandene Dokumente und wo im

Prozess spielen diese für dich eine Rolle? (Aktualisierung von Dokumenten)

- Da könnte mehr sein (wenig Dokumente)

- Seit der Phase 7 wurde im TYPO3 eine sinnvolle Art eingeführt -> RST Up-

grade Dateien -> Feature, Change oder Deprecation Beschreibung

- Aus der kann abgeleitet werden was mich in meinem Projekt betreffen kann

- Tools sollen diese auslesen, Version 9 wird gegen diese Dateien vergleichen

- Auch da kann man verbessern verfügbar machen für alte Versionen

- Vorfiltern von Dokumenten wäre wichtig

- Dokumentation nicht wichtig, wenn nicht auf Toolebene auswertbar

14. Welche Akteure bzw. Rollen siehst du an so einem Upgrade beteiligt?

- Entwickler (machen die Arbeit)

- Projektverantwortlichen (ergreifen die Initiative)

- Agentur

- Kunde der Agentur

- IT-Leitung

- Administration

Anhang

xii

- IT Hosting

- Redakteure



- Jegliche Form der Automatisierung würde er bevorzugen

- Auch wichtig für Upgrade-Prozess

- Composer macht viel einfacher

- Aus einigen Befehlen wird der Rest automatisch durchgeführt

- Weitere Automatisierungs-Tools wie z. B. die TYPO3Console

- Console hilft bei dem Aufspielen auf das Livesystem

- Upgrade Wizards kann die Console automatisch durchlaufen

- Spart Zeit


- GIT - Versionskontrolle ist das zentrale Tool

- Soviel wie mögliche Dokumentieren mit Commits

- Composer erleichtert das Upgrade

- TYPO3Console -> Kommandozeilen Tools

- PhpStorm -> mit den sgalinsiki Plugins

-


○ Ja


○ TYPO3 University Days -> Franz Kugelmann

■ Github Repo -> sammelt einige Tools

■ Shell-Skripte

○ Schade das Upgrade-Tool nur in 9er Version, nur über Browser erreich-

bar und nach dem Switchen der Sourcen

■ Oliver Hader baut ein CLI-Tool

■ Noch mehr Scanner Definitionen dahinter legen

■ Auch für ältere Versionen verfügbar machen

■ Hilft bei Codebasis-Auswertung

○ Autofix von „smooth migration wizard“ mit Autofix-Versionen

■ Namespacing austauschen von t3lib

○ Jedes Tool was automatisiert Dinge tun kann ist gut

Abschlussfragen


[…]

Anhang

xiii


- Größerer Fokus auf Stabilität in jeglicher Hinsicht

- Geht unter bei dem vielen Aufräumen und Aufhübschen

- Kern von Leuten soll priorisiert Dinge angehen

- Sprachprobleme bei TYPO3-Installationen lösen

- UI-Geschichten

- Mehr Leute die sich um UI kümmern

- Benjamin Kott ist da allein auf weiter Front

- Mehr Unterstützung

- Kleinigkeiten machen die den Redakteuren sehr viel Arbeit erspart

- Weniger Klicks

- Aufwand geringer als andere Tasks (FormEngine)

- Mehr Spaß am Bedienen von TYPO3

- Entwickler Focus kommt sowieso

Anhang

xiv

Interview 3

Länge: 60 Min.

Anwesende Personen: Sammy Baghdadi, Wolfgang Wagner

Einstiegsfragen


2006, seit 3.8 Version


Neugier, weil gut. Viele andere CMS, getestet. 5 - 6 Jahren. Flexibilität, wichtig.


Jweiland, Hosting und Projekte. Integrator


Krankenpfleger, 20 Jahre. 1996 -> 2012


- Update nur Minor

- LTS Wechsel

Hauptfragen



○ Finanzielles Problem bei Ausfall der Seite, Angestellte die bezahlt für

Pflege, Workflow wird einfacher spart Zeit und Geld


○ Sicherheit, Technische Basis, Technische Abhängigkeiten, Browser In-

kompatibilität


○ […]

Anhang

xv


(Metriken)-

[…]


(Wenn ja wie oft?)

Ja ziemlich viel, 300


- Seiten die wir hosten aber nicht selber entwickelt haben, Fremdprojekte

- Durchführung des Upgrades, TypoScript, Fluid


- Analyse (Upgrade check)

- Ist möglich

- Kein Upgrade wenn

- Keine Anpassungen an Extensions

- rg_smooth_gallerie -> bestimmte Extension

- Inkompatible Extension

- Keine alternativen vorhanden oder möglich

- Bei individual Extension nicht möglich

- Angebot

- Auftrag erteilt

- Termin vereinbaren

- Redaktionsstop

- Kunde müsste doppelt pflegen

- Upgrade an der Kopie

- Kunde testet danach

- Dann live


- Nacktes Typo3

- TYPO3script anschauen

- TSConfig

- Referenzindex aktualisieren

- Datenbank auf utf8 migrieren

- mit „smooth migration“-Extension

- Symlink austauschen auf höhere LTS

- InstallTool

- Upgrade wizard

Anhang

xvi

- Database compare

- Letzte kompatible Version für die Version einspielen bei Extensions

- Front noch egal

- Backen soll funktionieren

- Nochmal refindex aktualisieren

- Ab 8 könnte es aufwendiger werden

- Css_styled_content -> fluid_styled_content

- Css anpassungen notwendig

- Cke editor Wechsel? ja oder nein?


○ Spielt keine Rolle, da Hosting bei Jweiland bereits für TYPO3 optimiert



○ Flux, Fluidcontent,

○ ws_flexslider -> Bilder entfallen


○ Bei TypoScript selber relative wenig

○ Wechsel von css_styled_content auf fluid_styled_content

■ Wenn per TypoScript viel an css_styled_content verändert

○ Ab 9 muss man es machen

○ Special-menu war vorher einfacher


○ Kann in der Datenbank bleiben, wenn es da ist

○ Bei eigenen Projekten, ändern wir es aber

○ Sitepackage Extension -> Umstellen

○ So wenig wie möglich in der Datenbank


stand?)

○ DEV-Server

○ Staging / Test

○ Live

○ Bei großen Kunden

○ Bei kleinen Kunden auf einem System was nachher live wird


○ […]


○ […]


besonders einfach?)

- Einfach -> keine Fremd-Extensions, gut gepflegt

- kann auch sehr einfach

- Extensions sind immer am schwierig

- Notwendige Schritte

- Jede Version einzeln

Anhang

xvii



- Dokumentation meist kaum vorhanden

- Extension wichtig , Changelog -> in der Analysephase wichtig

- Kaum Dokumentation

- Link zur Doku

- Schulung per TeamViewer


- Integrator macht auch Test

- Administrator der durchführt

- Entwickler Anpassungen an Extensions

- Redakteure oder Kunden -> als Tester



- Aktuell kein Composer im Einsatz

- Bisher noch kein Projekt

- In Zukunft mehr nutzen

- Auch Deployment

- Eher für Profis


- Typo3 Konsole interessant

- Shell -> Terminal

- Editor ->

- Bei kleinen Projekten mit kleinem Editor

- Bei großen Projekte PhpStorm

- Sgalanski Plugins Fluid


○ […]


○ […]

Abschlussfragen


[…]

Anhang

xviii


- Funktionalität

- Real URL in den Core

- Mask in den Core für eigene Content Elemente

- Wert auf die Einsteiger legen, Einsteiger nicht vergessen

- Gerade bei Composer

- Alternative für Einsteiger

- Auch drauf hören

- Auch bei neuen Usern zuhören

Anhang

xix

Interview 4

Länge: 86 Min.

Anwesende Personen: Sammy Baghdadi, Mathias Schreiber

Einstiegsfragen


2002


War sein Job


Mädchen für alles, Integrator


- Musikinstrumente, Computer und Technik, Mitte der 90er angefangen ->

TYPO3 Bude

- TYPO3 hat ihn überzeugt

- Musste “Open Source” machen -> Netfielders

- Helfen macht sichtbar

- War kritisch gegenüber bisheriger Entscheidungen

- Mittwald-Büttenrede

- Marketing Team

- 2 Jahre Gehalt bekommen aber nicht für die Firma arbeiten

- Product Owner Ship - Kommerzielle Interessen hinter TYPO3 packen

- Die kaufmännische Ausbildung hilft sehr dabei

- 1,8 Mio € -> aus 6.2 eLTS


Update -> Entspannt, Verhalten

Upgrade -> Code ändert sich heftig

Hauptfragen


Anhang

xx


○ Shiny new Stuff verkaufen

○ Neuerungen müssen überzeugen


○ […]


○ Optik muss sich ändern

○ Design und Technologie


(Metriken)

- Bauchgefühl

- Open vs. closes Graph -> steigert die Motivationssteigerung

- Gamification

- Time to Fix ->


(Wenn ja wie oft?)

Ja, 40 zwischen verschiedenen LTS Versionen


[…]


- 2 Extreme wie ein Upgrade ablieferbar

- Technische Schulden

- Weg des minimalen Aufwands heute fahren

- Später werden die Upgrades einfacher

- Oder später fahren

- Die Gewinne für die Agenturen können höher ausfallen

- Alle Deprecations weg -> weil in nächster Version kommt es auf jeden Fall

- Migration als Mischkalkulation -> Wartungsvertrag hinten raus um aufzuräumen



○ Analyse ob Requirements erfüllt werden

○ Organisationsfrage

■ 1und1 & Host-Europe hatten lange Zeit kein PHP7

■ 2 Manntage

Anhang

xxi

○ Vorher alle Ext deaktivieren und dann step by step eine aktivieren und

fixen



○ Extensions sind ein Problem

○ Blindes verlassen auf “third party kram”

○ Gibt es Errors kann man die fixen

○ Reines Integrator-Team ist unmöglich

○ Komplexität hat sich weiterentwickelt ->

■ Know How Level passt of einfach nicht zur Anforderung


○ TypoScript nicht -> bzw. nicht hart

○ CSS_styled_content -> auf fluid_styled_content war nicht gut


○ Auf keinen Fall noch machen (Empfehlung)

○ Für Hotfixes vorbei am Deployment

○ Bleibt aber im Core


stand?)

○ Dev, Stage und Prod

○ Dev ist lokal , so oft wie Entwickler, Shell script von Stage auf Dev, und

auf von Stage auf Prod


○ […]


○ […]


besonders einfach?)

Keines



- Neue entstehen keine

- RTS- Files

- RTS von Sprints, Core-Team im Channel


Dev, Integrator, Kunde, PM

Anhang

xxii



- Kombinationsbusiness

- Frühjahrsputz denke -> zu viel auf einmal vorgenommen

- Lieber in kleine Pakete unterteilen

- No Brainer, keine valide Entschuldigung für nicht Nutzung


- PhpStorm -> Php Inspections (EA Extended) scanner -> Grün machen

- Keine Klasse hat je länger als 2 Stunden gedauert (außer tt_news pi1)

- RST Files extension Scanner


○ Explosion driven durch die Updates

○ Fußschalter für Reload

○ Das was der Ext-Scanner findet und auch gleich fixed (lolli hat da was

vorbereitet)


○ […]

Abschlussfragen


Kalkulation von Upgrades

- Ein Manntag pro Extension

- Das Ergebnis ist unscharf und auch Projekte wo man draufzahlt

- Keine Analyse Phase

- Plus etwas Kontextkosten

- Bauchgefühl

- Kalkulation muss nicht belegt werden

- Die Masse ist hier wichtig

- Man profitiert von vorhanden

- Mischkalkulation

- Wir sind die schnellsten beim Angebot

- Trustvorteil

- Man transportiert nach außen unglaubliche Kompetenz


- Mehr Professionalisierung

- Im Core ziehen wir durch

- Es bleiben Leute auf der Strecke die sich anpassen wollen

Anhang

xxiii

- Wir wollen nicht mit Wordpress konkurrieren

- TYPO3 wird ein Profi-Tool

- Microsoft scharrt mit den Hufen, die wollen TYPO3

- Mein Markt kann das nicht abfangen

- Da rufen nicht Leute den du Deployment verkaufen musst -> das ist das

normal

- Backup & Desaster Strategie muss dabei sein

- Ehrliches Produkt

Anhang

xxiv

Interview 5

Länge: 63 Min.

Anwesende Personen: Sammy Baghdadi, Thomas Maroschick

Einstiegsfragen


15 Jahren


CMS für eine Freundin erstellt, über die LK Erdkunde


Generalist


- 10 Klasse Abgang Gymnasium, nach 2 Jahren selbstständig. Ausbildung als

Mediengestalter. 2008 auf den Dev-Days erstmalig. Vor 3 Jahren wurde er

Core-Teammember.

- Namespacing change in 6.0 begleitet. Teilhaber Technischer Leiter.


- Update: Bestehenden Funktionsumfang verbessern (innerhalb)

- Upgrade: Neue Features, eine Stufe mehr (LTS zu LTS)

Hauptfragen


Ja es ist absolut notwendig.


○ Schutz der Investition

○ Technische Schulden werden mehr mit jedem ausgelassenen Upgrade

○ Macht auch einen besseren Eindruck gegenüber von Interessengruppen

○ Die Investition in Content ist enorm

○ Content kann einfach migriert

Anhang

xxv

○ Erstellen des Systems bringt sie in der Rolle eines Software-Entwick-

lers. Denn auf Basis der Anforderungen wird von einem Dienstleister

eine Software entwickelt. Der Kunde sieht es aber immer nur Produkt.


○ Wenn sich am Ökosystem nichts ändert. (Client sind bekannt) -> dann

nicht notwendig


○ Wenn man Teil des Webs ist, ist es notwendig. Damit auch die Wahlfrei-

heit der Browser erhalten bleibt.


(Metriken)

Keine wirklichen Zahlen vorhanden, Ohlo (Metrik), Die Kunden sind nicht affin genug

dafür


(Wenn ja wie oft?)

Ja, 50


Alles


- Klassischer Verkauf (Pilotkunde bei neuen LTS-Versionen)

- Entwicklungsphase (relative lange)

- Auf den Dev-Maschinen Upgrade durchgespielt

- Dann Production auf Stage-System spiegeln und dort wird geprobt

- Abnahme von Kunde

- Testing(Phase)

- Live Upgrade oder Spiegelung der Installation und Switch (Rollout)

- Es kommt immer eine Bugfixing-Phase

- Es gibt Seiten-Effekte und “Maulwurf-Seiten”



○ Kurz vor der Testing-Phase, da auf DEV-Maschinen schon aktuelle Bib-

liotheken laufen

○ Aus dem Testing kommen die Anforderungen an den Server

○ Knapp überdacht

Anhang

xxvi



○ Extensions verursachen den größten Aufwand

○ Das Kernsystem hat einen guten Upgrade-Pfad

○ Anpassen auf neue Apis macht Hauptaufwand

○ Recherche nach alternativen

○ Alarm-Extension:

■ Alle Ext die keinen modernen Entwicklungsparadigmen folgen

(TemplaVoila). Reines Upgrade zwar machbar man verbessert

aber nicht die Code-Basis

■ RealURL

■ PowerMail (Die Versionen ohne Wizards schwierig)

■ Individual-Extension nicht häufig das Problem bei Ihm da bereits

sauber geschrieben wird

■ Sich schnell bewegende Extensions


○ Kommt drauf an, fluid_styled_content zu css_styled_content von Typo-

Script rendering auf fluid-rendering -> ist aufwändig

○ Man kann auch das alte Rendering behalten

○ Da kann auch nicht viel kaputtgehen, da dumpfes Array


○ Grundsätzlich Config wie Code behandeln und Code gehört versioniert

○ Ob DB oder File egal, Hauptsache versioniert

○ Auslagern von Config in Dateien nur dann besser, wenn Versionierung

genutzt wird! (GIT)

■ Bewährter Prozess

○ Sie lagern


stand?)

○ DEV (Lokale Instanzen)

○ Stage/Testing (bisher nur ein Kunde der dies nutzt)

○ Production


○ Resultat muss selbst geprüft werden

■ Nur er kennt das System in Gänze

○ Entscheidungen müssen getroffen werden

■ Besonders bei nicht mehr kompatiblen third-party-extension

○ Redaktionsstop muss der Kunde beachten, während eines Upgrades

■ Pflegen von zwei Systemen auch eine Möglichkeit

○ Bezahlen


○ […]

Anhang

xxvii


besonders einfach?)

- Ja, große Extensions die nicht selbst Entwickelt wurden

- Wenn eine Extension eine weitere Framework-Extension braucht dann

gefährlich

- Autoren dann oftmals überfordert mit ihrer Extension ohne das Frame-

work



RST-Files, hilft sehr


- Kunden

- Vertrieb / Kundenbetreuung

- Konzeptions-Team (Kunde, Kundenbetreuer, Entwickler)

- Sammeln der Anforderungen und Prioritäten

- Entwicklung

- Lead-Entwickler in der Regel

- Testing / Kunde / Kundenbetreuer



- Composer wird seit einigen Jahren genutzt

- Macht viele Dinge einfacher

- Reduziertes Interface macht Aktionen einfach

- Komplexität wird verringert

- Automatisches Deployment noch recht neu

- Vereinfacht auch sehr gut

- Skripte sind gut vorhersehbar

- Wir eine immer wichtigere Rolle spielen


- PhpStorm

- SQLClients

- Webbrowser

- Kommandozeilen

Anhang

xxviii


○ Abstrakte Sprache (Domain Specific Language) die Updates beschrei-

ben kann

■ Updates am Content, die Updates durch Core ermöglichen

■ Ändere Content Element von x nach y


○ […]

Abschlussfragen


- Grundsätzlich sind Upgrades schwierig

- Als erfahrener Entwickler nicht kompliziert aber viel Arbeit

- Sehr mechanische Arbeit

- Für unerfahrene Entwickler die Hölle

- Dort gibt es keine Unterstützung

- Die Upgrades müssen gute Entwickler machen, obwohl die oft nicht zur Verfü-

gung stehen

- Dadurch kann das Upgrade auch noch schlechteren Code liefern

- Immer weniger Third-Party-Extension einsetzen, da diese das größte Risiko tra-

gen

18. Was wünschst du dir für die Zukunft von TYPO3?

- Frage der Entwicklung

- Mehr Entwickler die mit TYPO3 arbeiten, Professionalisierung der Community

- Über Junior hinaus

Anhang

xxix

Interview 6

Länge: 35 Min.

Anwesende Personen: Sammy Baghdadi, Philipp Stranghöner

Einstiegsfragen


Seit 2011


- Arbeitgeber Mittwald, Hauptsystem bei Mittwald

- Eigene Webseiten


Integrator, kein Entwickler


- 2011, Mediengestalter gelernt, Werbeagentur -> Webbereich betreut

- Produktmanager bei Mittwald, Für Softwarebereich


- Update: Minor TYPO3 Update, Bugfix, kleine (winzige) Funktionen

- Upgrade: Aufwändiger, komplett neues System was leer ist mit Migration, LTS-

Versionen

Hauptfragen



○ […]


○ Sollte aktuell gehalten werden

○ Sicherheitslücken

■ Auch in Bezug auf Extensions

○ Neue Funktionen


○ Kunden kann etwas verkaufen

Anhang

xxx


(Metriken)

Keine Nutzung von Metriken für Upgrades


(Wenn ja wie oft?)

Ja, schon mehrere Upgrades durchgeführt. Privat und bei Mittwald.


- Testen

- Analyse

- Durchführung (mit TYPO3console)


- Relaunch (Ist-Aufnahme)

- Konzept

- Upgrade-Phase an Kopie

- Sourcen austauschen

- InstallTool oder TYPO3Console

- Redaktionsstop, Content-Freeze



○ Vorher prüfen ob möglich

○ PHP-Version Upgraden

○ in Durchführungsphase -> Keine Komplettes Upgrade des System

● 11b: Fragen zu Problemen mit Extension? (Häufige Probleme und wie


○ Gridelements -> Ist nicht kompatibel mit Version 8

■ Ist in dem Template von Mittwald enthalten

○ Hat sich in den letzten Jahren in der Community zum positiven Entwi-

ckelt bei großen Extensions

○ Mittwald finanziert


○ MenuProccesor in Version 8, gab es vorher noch nichts

○ Mit Extensions meist einfacher


○ Immer Empfehlen auszulagern auf Dateiebene wenig in der Datenbank

○ Template-Extension ist empfohlen (sitepackage)

■ Häufig

Anhang

xxxi


stand?)

○ DEV

○ Stage / QS-System

○ Live

○ QS / Stage ist Optional


○ Redaktionsstop

○ Umstellung der Prozesse bei Redaktion


○ […]


besonders einfach?)

- Die Extensions die benutzt wurden sind

- Wenn diese Extensions nicht mehr weiterentwickelt wurde

- Mittlerweile besser



- Durch die Erfahrung wenig relevant

- Changelogs sind wichtig

- Fragen ob es Dokumentation gibt und nutzen wenn vorhanden

- Dokumentation wird immer erstellt

- Mittlerweile währendessen

- Automatisiertes erzeugen von Dokumentation durch Tools


- Kunde / Testen und Abnahme

- Kundenberater und Projektmanager

- Integrator und Entwickler



- Wird noch nicht genutzt, aber sehr interessant

- In Agenturen wird es zwar benutzt aber noch nicht überall

- Weniger als 1 % der Agenturen nutzen, halbes Jahr

- Kein Automatisiertes Deployment

- Agenturen nutzen Capistrano

Anhang

xxxii


- Terminal

- Extension TYPO3console

- Update über Terminal

- Inkompatible Extensions werden direkt deaktiviert

- PhpStorm -> Sgalinski


○ Extension - Scanner

■ Auswertung der Extensions, Alternativen vorschlagen


○ […]

Abschlussfragen


[…]


- Der Weg mit der TYPO3 GmbH super, so weiter machen

- Entwicklung ist flexibler

- Der Service wird besser, eLTS ist Super

Anhang

xxxiii

Kernaussagen aus Interview mit Interviewleitfaden 1

Nr. Kernaussagen • Nicole Cordes

1 • 12 Jahre

2 • Ausbildung, aktueller Arbeitgeber

3 • Backend, Extension, TYPO3Core

4 • Durchgehend bei CPS seit Ausbildung

5 • Update -> Minor, Bugfix • Upgrade -> Major

6 •

6a • Kunden verlieren Geld • Höhere bei Anpassungen an alte Versionen

6b • Sicherheit • Robusteres System • Besseres Datenschutz

6c •

7 • Ja

8 • Extensions aktualisiert

9 •

9a • Hängt von ab, was für Hosting • PHP aktualisieren, Webserver auch • Abhängige Pakete aktualisieren (ImageMagick)

9b • Bei neuen TYPO3-Versionen weniger Probleme • TCA-Anpassen • pibase weiter verwendbar • Changelog vorher prüfen • Bei T3•Version 9 mittels RST-Dateien prüfen • Extension in eine frisches T3 installieren und testen

9c • TypoScript verändert sich kaum • Es kommt meist nur hinzu • Aktualisierung auf neue Standards durchführen (sitepackage)

9d • Beides OK • DB ist performanter • Versionskontroller auf Dateiebene • Sitepackage sinnvoll

9e • Keins der Systeme notwendig • In lokaler Kopie (DEV) Upgrade durchführen • Nach Erfolg auf Stage • Kunde testet und nimmt auf Stage ab • Kopie von Live anlegen und upgrade • Dann Server tauschen • Redaktionsstop notwendig, TYPO3 sperren

9f • Kunde muss Redaktionsstop planen

9g • Kalkulation häufig falsch • Verkauft man "nur" Upgrade oder doch mehr? • Relaunch (Frontend) während des Upgrades kann Zeitplan beeinflussen • Was passiert wenn Budget aufgebraucht

Anhang

xxxiv

Nr. Kernaussagen • Nicole Cordes

10 • Große Strukturen • Viel Konfiguration • Extension • Form Engine • TCA

11 • Man kann auch auf CLI aktualisieren • Individualextension bleiben kompliziert • Einfach nur ein andere Weg bisherige Dinge zu tun

12 • PhpStorm IDE zum Analysieren • Deprecation-Log von TYPO3 • Extension Scanner in kommender Version 9 • Upgrade Wizard im InstallTool • Database-Analyser im InstallTool

12a • Vorschau aus alten InstallTool in neue T3•Version • Funktions-Scan mit PhpStorm

12b •

13 • Dokumentation zwischen den Steps wichtig • Templates können sich verändern • Css_styled_content ist deprecated -> Umstellung auf fluid_styled_content • TYPO3 compatibility•Extension können helfen beim Upgrade • Bringt aber auch vieles nicht benötigte

14 • Besserer Umgang mit Versionsnummern -> Kein Breaking bei Minor-Versionen

Anhang

xxxv

Kernaussagen aus Interviews mit Interviewleitfaden 2

Frage

Kernaussagen • Wolf-gang Wagner

Kernaussagen • Helmut Hummel

Kernaussagen • Mathias Schreiber

Kernaussagen - Thomas Maroschick

Kernaussagen - Philipp Stranghöner

1 • seit 2008 • 12 Jahre • seit 2002 • seit 2002 • seit 2011

2 • Flexibilität, bestes CMS • Das erste CMS was über-zeugte

• Aufgrund seines Arbeitsge-bers

• Privat für einen Erdkunde-Kurs CMS erstellt

• Wegen Arbeitgeber

3 • Integrator • 5 Jahre Freelancer • Backendentwickler

• Integrator • Universalist

• Generalist • Integrator

4 • 20 Jahre Krankenpfleger • Seit 2012 Beruflich nur T3

• Quereinsteiger • Verkauf von Musikinstru-menten • Kaufmännische Ausbildung

• Ausbildung als Medienge-stalter • Core-Team seit 2008 • Aktuell Teilhaber und tech-nischer Leiter

• 2011 Ausbildung zum Mediengestalter • Webbereich betreut in Agentur • Produktmanager bei Mittwald

5 • Update -> Minor • Upgrade -> LTS

• Update -> Bugfix, einfach • Upgrade -> Major, komplex

• Update -> Einfach, keine bis minimale Verhaltensän-derung • Upgrade -> Major, Viele Codeänderungen

• Update: Bestehende Funktionen verbessern (in-nerhalb von LTS) • Upgrade: Neue Features, von LTS zu LTS

• Update: Minor, Bugfixes, kleine (winzige) neue Funktionen • Upgrade: Aufwändiger, LTS-Version

6 • • Sieht Webplattform als Soft-ware

• • Ja ist absolut notwendig •

6a • Umsatzausfälle bei Aus-fall des Systems möglich • Unnötige Personalkosten für Redakteure bei Ausfall des Systems • Workflow wird in neuen Versionen besser -> Spart Kosten

• Hack protection • Image Schaden oder finanzi-elle Schaden präventieren

• Neues Design • Schutz der bisherigen In-vestition • Technische Schulden häu-fen sich mit jedem ausge-lassenen Update und somit die Upgrade kosten insge-samt • Investition in Content si-chern • Erstellen lassen von Soft-

•

Anhang

xxxvi

Frage






ware bringt den Kunden au-tomatisch in die Position eines Software-Entwicklers mit outgesourctem Team (Agentur / Freelancer)

6b • Sicherheit • Bessere technische Basis • Browser-Probleme im Ba-ckend möglich mit neuen Browser-Versionen

• Neue Features • Es wird allgemein besser • Alter Versionen werden nicht mehr supported

• Neue Technologien • Wenn sich am Ökosystem nichts ändert muss auch kein Upgrade sein -> aber extrem unwahrscheinlich (Browser Teil des Ökosys-tems)

• Sollte aktuell gehalten werden • Sicherheitslücken ver-meiden • Neue Funktionen

6c • • Es wird stressfreier und güns-tiger wenn man regelmäßig Upgrades durchführt

• • Wenn man Teil des Webs sein möchte sind Upgrades notwendig • Gepflegtes System mach guten Eindruck

• Agentur kann dem Kun-den etwas verkaufen

7 • • TYPO3 nutzt SonarQube • https://sonarcloud.io/project/ • Konsequente Auswertung fin-det noch nicht statt

• Open vs. Closes Tickets • Gamification • Time to fix • Metriken als Motivation-steigerung für DEVs

• Kunden sind dafür nicht affin genug -> keine Nut-zung von Metriken

• Keine Nutzung von Met-riken

8 • ca. 300 • Ja Ja, ca. 40 • Ja, ca. 50 • Ja, schon mehrere Up-grades durchgeführt

9 • Durchführung des Upgra-des • Meist an nicht selbst ent-wickelten Seiten • TypoScript und Fluid

• • • Alles • Testen • Analyse • Durchführen (mit TYPO3console)

10 • Analyse (Upgrade Check) • Entscheidung ob möglich oder nicht

Inhalt gehört zu Frage 11 • • Verkaufsphase • Entwicklung / Durchfüh-rung • Switch bzw. Roll-out

• Ist-Aufnahme • Konzept • Upgrade an Kopie • Sourcen austauschen

Anhang

xxxvii

Frage






• Alternative Extensions su-chen • Inkompatible Extensions erkennen • Angebot erstellen • Auftrag wird erteilt • Termin mit Kunde verein-baren • Redaktionsstop • Upgrade an Kopie durch-führen • Kunde nimmt ab und tes-tet • Dann live schalten

• Bugfixing-Phase durch Seiten-Effekte und "Maul-wurf-Seiten"

• InstallTool oder TYPO3console • Redaktionsstop, Content Freeze

11 • Upgrade für jede LTS ein-zeln • Nacktes TYPO3 aufset-zen • TypoScript prüfen • TSConfig • Referenzindex prüfen / aktualisieren • Datenbank auf UTF8 mig-rieren (mit „smooth migra-tion“ Extension) • Symlink austauschen • InstallTool • Upgrade Wizard • Database compare • TER•Extension aktualisie-ren • Frontend ist hier noch un-wichtig

Inhalt aus Frage 10 • Überblick verschaffen • Alles was nicht gebraucht wird rauswerfen • Alle nicht aktiven Extensions entfernen • Aktive Extensions prüfen ob diese genutzt werden • Entwickler Extensions (PHPu-nit, PHPmyAdmin) entfernen • Template•Datensätze analy-sieren • Wenn möglich reduzieren und in Dateien auslagern (sitepack-age) • Checkliste wäre wünschens-wert • Refindex aktualisieren • History und als gelöscht mar-

• Analyse (Überblick ver-schaffen) • Alle Ext. deaktivieren und Stück für Stück aktivieren und fixen • Deprecations entfernen

• •

Anhang

xxxviii

Frage






• Noch einmal Referenzin-dex prüfen • Css_styled_conent durch fuid_styled_content aus-tauschen (schwierig) • RTE durch CKE ersetzen

kierte Datenbankeinträge lö-schen • Alles redundante entfernen Inhalt aus 11 direkt: • Statusaufnahme (Istzustand) • Aufräumen • Abzug von Live in Testumge-bung erstellen (Migration) • Aufsetzen in alter Version • Upgrade durchführen -> siehe 11 • Datenmigration (aktueller Li-vestand) • Alternative: • Vorhersagesysteme (ab Ver-sion 9)

11a • Hosting nur bei jwei-land.net -> Umstellen der Config per Klick, TYPO3 optimiert

• Hoster informieren • Zuerst Server upgraden • Wenn 4.5 dann zuerst auf 6.2 • Ab 6.2 kann man direkt auf 8.7 • Ab 7.6 weniger Plattformprob-leme

• Analyse • Kontakt mit Hoster aufneh-men • 2 Manntage bei eigenem Hosting

• Dev-Maschinen aktualisie-ren • Aus dem Testing kommen die Anforderungen für den Server

• Vorher prüfen ob mög-lich • PHP-Version upgraden • In der Durchführungs-phase • Upgrade des Betriebs-system nicht empfohlen, dies nur auf neuem Ser-ver

11b • Flux, Fluidcontent • Bestimmte Extensions

• Xclasses sind ein Problem • Wenn sich überschrieben Me-thode verändert hat, muss diese auch angepasst werden

• Extensions sind ein Prob-lem

• Extensions verursachen größten Aufwand • Kernsystem hat guten Up-grade-Pfad • Anpassen an neue APIs macht den Hauptaufwand • Schwierige Extensions:

• Gridelements -> noch nicht kompatibel mit Ver-sion 8 • Ist aber in Standard-Template von Mittwald enthalten

Anhang

xxxix

Frage






• Alle Extensions die keinen modernen Entwicklungspa-radigmen folgen • TemplaVoila • PowerMail (wird aber bes-ser) • Individual-Extensions die selbst geschrieben wurden sind gut Upgradebar • Sich schnell bewegende Extensions sind auch schwierig

• Ist in den letzten Jahren aber besser geworden

11c • TypoScript macht wenig Probleme • Wechsel von css_sty-led_content zu fluid_sty-led_content • Special-menu muss an-gepasst werden

• • TypoScript macht wenig Probleme • Css_styled_content -> fluid_styled_content

• TypoScript macht wenig Probleme • Änderung von css_sty-led_content auf fluid_sty-led_content schwierig

• Wenig Probleme mit Ty-poScript • MenuProcessor neu in Version 8 • Extension besser als Ty-poScript

11d • Kann auch in der DB blei-ben • Wird aber immer aus der Datenbank geholt • Sitepackage erstellen • So wenig wie möglich in der DB

• Kommt auf die Zeit an, wird aber Empfohlen • Kann man auch schon vor dem Upgrade machen -> ver-einfacht dieses • Dann auch direkt in Versions-kontrolle • Dokumentation und Nachvoll-ziehbarkeit durch GIT

• Keine Speicherung in der Datenbank empfohlen • Für Hotfixes OK • Feature wird aber nicht aus dem Core entfernt

• Grundsätzliche Config wie Code behandeln und gehört deshalb in das VCS (Git) • Aber ob DB oder Files egal Hauptsache versioniert • Empfehlung: Auslagern

• Immer empfohlen auszu-lagern -> so wenig wie möglich in Datenbank • Template Extension (si-tepackage) sehr empfoh-len

11e • DEV -> Lokal • Stage / Test • Live • Nur bei großen Kunden

• DEV -> lokal • Stage zum Testen und Teilen • Abnahme durch Kunde • Live

• DEV -> Lokal, n mal • Stage -> Abnahme-System • Live ->

• DEV (lokal) • Stage/Testing • Production/Live

• DEV - Lokal • Stage / QS-System • Live

Anhang

xl

Frage






11f • • Eventuell wird dieser von ei-ner Agentur unterstützt • Kosten und Zeit müssen ein-geplant werden • Entscheidungen müssen ge-troffen werden • Chance auf Verbesserung der internen Prozesse besteht • Content Freeze (Redaktions-stop) notwendig

• • Resultat muss geprüft werden, nur er kennt das System in Gänze • Entscheidungen müssen getroffen werden • Nicht mehr kompatible Third-Party-Extension • Redaktionsstop oder Pfle-gen von zwei Systemen

• Redaktionsstop • Umstellung der Pro-zesse beim Kunden

11g • • • • •

12 • Einfach -> wenn wenig In-dividual-Extensions • Extension immer am schwierigsten

• • Nichts • Große Extensions die nicht selbst entwickelt wur-den

• Wenn benutzte Extensi-ons nicht mehr weiterent-wickelt werden • Wird aber besser

13 • Dokumentation kaum vor-handen • Changelog bei TER-Ex-tension • Doku wird nicht geschrie-ben • Schulung per TeamVie-wer

• Wenig Dokumente vorhanden • RST-Dateien von TYPO3 wichtig • Dokumentation nur Sinnvoll wenn auf Toolebene auswert-bar

• RST-Files • Changelogs und Ergebnis-dokumente von Sprints

• RST-Files • Durch Erfahrung weniger relevant • Changelogs und RTS-Fi-les sind wichtig • Vorhandene Dokumen-tation wichtig • Dokumentation wird im-mer erstellt • Früher nach der Ent-wicklung • Heute während • Erzeugung aus Code wird genutzt

14 • Integrator für das Up-grade und Tests • Administrator für Server • Entwickler für Extensions

• Entwickler (machen die Ar-beit) • Projektverantwortliche • Agentur vom Kunden

• DEV (Entwickler) • Integrator • Kunde • PM

• Kunde • Vertrieb / Kundenbetreu-ung / PL • Konzeptions-Team

• Kunde -> Test und Ab-nahme • PL

Anhang

xli

Frage






• Redakteure bzw. Kunde für Test und Abnahme

• Kunde • IT-Leitung • Administration • IT und Hosting • Redakteure

(Kunde, PL, Entwickler) -> Sammeln von Anforderun-gen • Entwicklung

• Integrator • Entwickler

15 • Aktuell keine Composer im Einsatz • In Zukunft mehr nutzen • Auch Deployment auto-matisieren • Eher für Profis

• Jegliche Form von Automati-sierung ist gut • Composer macht viele einfa-cher • Aus einigen kurzen Befehlen entsteht eine Abfolge von Akti-onen • TYPO3Console hilfe • UpgradeWizard laufen auto-matisch durch -> spart Zeit

• Da composer•Nutzung ein "no brainer" gibt es keine Entschuldigung für die nicht Nutzung • Deployment wird genutzt

• Composer wird seit eini-gen Jahren genutzt • Macht viele Dinger einfa-cher, danke reduziertem In-terface und verringerter Komplexität • Automatisches Deploy-ment noch recht neu • Aber vereinfacht auch • Wird immer wichtiger

• Wird noch nicht genutzt aber interessant • Weniger als 1 % der Kunden von Mittwald nut-zen Composer • Wenig Automatisierung, wenn dann Capistrano

16 • TYPO3•console ist inte-ressant • Terminal • PhpStorm mit sgalinski Plugins

• GIT•Versionskontrolle • Composer • TYPO3console • PhpStorm mit sgalinski Plugins

• PHP•Storm -> PHP Inspec-tion Plugin

• PhpStorm • SQLclients • Webbrowser

• Terminal • Extension TYPO3con-sole • Update über Terminal • Inkompatible Extension werden automatisch deak-tiviert • PhpStorm mit

16a • • Ja • Automatischen fixen • Abstrakte Sprache mit der man Upgrades beschreiben kann

• Extension Scanner mit automatischer Auswer-tung und alternativ Vor-schlägen

16b • • Franz Kugelmann Toolsamm-lung • 9er Upgrade-Auswertung auch für ältere TYPO3•Versio-nen verfügbar machen

• • •

Anhang

xlii

Frage






17 • • Beim Angebot keine Analy-sephase • Pauschale Abrechnung ( 1 MT pro Extension) • Schnell sein bringt Vertrau-ensbonus beim Kunden -> Man transportiert hohe Kom-petenz

• Grundsätzliche sind Up-grades schwierig • Als erfahrener Entwickler nicht schwierig aber viel mechanische Arbeit • Für unerfahrene Entwick-ler die Hölle -> es gibt we-nig Unterstützung • Upgrades sollten gute Ent-wickler machen obwohl diese häufig zu Verfügung stehen • Dadurch kann beim Up-grade schlechterer Code als vorher entstehen • Je weniger Extension, desto einfacher das Up-grade

•

18 • RealURL in den Core • Mask in den Core (eigene Content-Elemente) • Wieder mehr Wert auf Einsteiger legen • Auch Kritik annehmen (auch bei neuen Usern)

• Größerer Fokus auf Stabilität in jeglicher Hinsicht • Sprachprobleme lösen • Mehr Fokus auf UI • Redakteure das Leben ver-einfachen -> Mehr Spaß am Bedienen

• Mehr Professionalisierung • Wir wollen nicht mit Word-press konkurrieren • TYPO3 als ehrliches Pro-dukt

• Mehr Entwickler und Pro-fessionalisierung der Com-munity

• TYPO3 GmbH super, weiter so • eLTS gut • Service weiter verbes-sern

Anhang

xliii

Gemeinsamkeiten und Interpretationen aus Interviews

Nr. Gemeinsamkeiten / Interpretation

1 • Mehrjährige Anwendung

2 • Arbeitgeber

3 • Unterschiedlich

4 • Quereinstieg

5 • Update -> Einfach, Minor • Upgrade -> Komplex Major, LTS

6 • Upgrades wichtig

6a • Umsatz/Gewinnverlust bei Kunde • Reduktion der Personalkosten • Image Schäden präventieren • Schutz bisheriger Investitionen • Technische Schulden häufen sich an

6b • Sicherheit • Datenschutz • Robustheit • Neue Features • Alte Versionen werden nicht mehr supported • Browser-Probleme im Backend möglich • Wenn sich am Ökosystem nichts ändert muss auch kein Upgrade sein -> aber extrem unwahrscheinlich (Browser ist Teil des Ökosystems)

6c • Je häufiger das Upgrade, desto günstige und simpler weiter Upgrades • Man ist Teil des Webs und Upgrades deswegen notwendig

7 • SonarQube als Tool • Gamification-Ansatz motiviert • Time to fix, open vs. closes als Beispiel • Keine konsequente Nutzung • Kunden dafür nicht affin genug

8 • Alle beteiligt

9 • Meist in Frage 10 beantwortet

10 • Analyse • Angebot erstellen • Termin vereinbaren • Redaktionsstop • Upgrade an Kopie • Abnahme und Test durch Kunde • Live Schaltung

Anhang

xliv


11 TYPO3 • Überblick verschaffen / Analyse / Ist-Aufnahme • Extensions auf Upgrade-Fähigkeit prüfen • Alternativen Recherchieren • TypoScript prüfen • Template Datensätze prüfen • Prüfen ob aktive Extensions auch genutzt werden • Abgleich der Extensions mit Changelog und RST-Dateien • Vorhanden Dokumentationen prüfen • Vorbereitung (in DEV) • Aktuelle Datenbank besorgen • Entwickler Extensions entfernen • Referenzindex prüfen & aktualisieren • Datenbank auf UTF•8 migrieren wenn nötig • History und gelöschte Datensätze löschen • Redundanzen löschen • Durchführung (in DEV) • Alle Extensions deaktivieren • Extrahieren der Konfiguration aus Datenbank • Erstellung einer Template•Extension (Sitepackage) • Aktualisierung der Extensions auf max. Version per Ext.Man. oder Composer • Kerne austauschen / Symlink tauschen • InstallTool oder TYPO3Console • Database Compare durchführen • Upgrade Wizard durchlaufen • Aktualisierung der Ext auf max. Version per Ext.Man. oder Composer • Steps für jeden Kern (LTS zu LTS) wiederholen • (Optional aber Empfohlen) css_styled_content auf fluid_styled_content • (Optional aber Empfohlen) RTE durch CKE ersetzen • Extensions aktivieren TER • Auftretende Fehler beheben • Extension Individual • (Optional) Umstellung von pibase auf Extbase • Scan per PhpStorm und RST-Files auf bekannte Probleme • Probleme beheben • Scan per PhpStorm und Plugin PHP Inspections auf Probleme • Probleme beheben • Deprecations entfernen • Dokumentationen aktualisieren • Test (in DEV) • Test Frontend durch DEV • Test Backend durch DEV • Fehler beheben • Deploy auf Stage (Optional) • Test und Abnahme durch Kunden • Auftretende Fehler beheben • Deploy auf Live • Finale Test und Abnahme Systemkontext / Server • Anbieter mit Update der Infrastruktur beauftragen vor Durchführung oder • Update selber durchführen • Betriebssystem aktualisieren • Programme aktualisieren • Konfigurationen der Programme aktualisieren • Test und Fehler beheben Kunde • Beauftragung der Analyse durch Kunde

11a

11b

11c

11d

11e

11f

11g

Anhang

xlv


• Übergabe der Analyse und Kostenschätzung des Upgrades • Abbruch durch Kunde oder • Beauftragung durch Kunde • Redaktionsstop und Zeitplan abstimmen • Test und Abnahme durch Kunde • Schulung und Übergabe der Dokumentation

12 • Individual Extensions

13 • Changelog • RST-Files • Wenig Dokumentation bei Individual Extensions • Dokumentation nur sinnvoll, wenn durch Tools auswertbar • Je mehr Erfahrung desto weniger relevant

14 • Kunde • Projektleitung • Integrator • Entwickler • Administrator

15 • Empfehlung Composer nutzen • Empfehlung automatisiertes Deployment nutzen • Weniger als 1 % der Mittwald-Kunden nutzen den Composer-Modus • Wenig Automatisierung, wenn dann aber Capistrano

16 • PhpStorm mit den Plugins • TypoScript support for PhpStorm • Fluid support for PhpStorm • Php Inspections (EA Extended) • TYPO3Console (Besonders wichtig für Mittwald) • Composer • GIT

16a • Automatisches Lösen der durch Scanner gefundenen Probleme • Vorschlagen von neuen Extensions, wenn alte inkompatibel • Abstrakte Upgrade-Sprache

16b • Tool Sammlung Franz Kugelmann

17 • Schnell sein bringt Vertrauensbonus

18 • Keine Gemeinsamkeiten -> Einzelauswertung

Documents

Konzeption eines Vorgehens für die Durchführung eines Upgrades … · Der Funktionsumfang von TYPO3 kann mittels Erweiterungen, sogenannter Extensions, erhöht werden. Hierfür