Würdest du dich und deinen Verantwortungsbereich innerhalb der Universität in Ulm kurz vorstellen?
Hallo zusammen, mein Name ist Klaus Fumy. Ich arbeite als technischer Angestellter an der Uni Ulm und bin dort in der zentralen Betriebseinrichtung “kiz” (Kommunikations- und Informationszentrum) Abteilung Medien tätig. In dieser Abteilung wird unter anderem das TYPO3-System mitverwaltet, das ich schon seit 2006 mitverantworten darf. Wir haben schon etliche Iterationen und sehr viele Updates von TYPO3 erlebt. In den ersten Jahren haben wir das alles in-house gemacht. Seit 2016, mit dem letzten großen visuellen Relaunch, haben wir in2code mit ins Boot geholt.
Ich bin dafür zuständig, dass TYPO3 läuft. Für die Webserver ist mein Kollege in der anderen Abteilung verantwortlich. Ich bin die Kommunikationsschnittstelle zwischen allen Bedürfnissen der Uni an die Website, dem System, den Systemverwaltern und den Systembedienern, sprich Redakteuren. Wir haben fast 1000 Redakteure, die ich mitbetreue. Das Arbeiten ist sehr verteilt. Es gibt kaum Universitäten, die eine zentrale Redaktion haben, die dann für alle Inhalte verantwortlich ist. So auch bei uns nicht.
Was war der Hintergrund dafür, dass sich die Uni in diesem Jahr an in2code gewandt hat?
Wir haben seit 2016, also seit dem Relaunch, einen Supportvertrag mit in2code, weshalb wir auch in dauerndem Austausch mit in2code stehen. Seitdem gehen wir laufend sowohl Fehlerbeseitigungen als auch Weiterentwicklungsschritte gemeinsam an.
Da in2code auch unsere Deployment mitverantwortet und uns in allen Entwicklungs-Angelegenheiten unterstützt (bis auf ein paar wenige Konfigurationen, die ich selbst vornehme), ist in2code mit uns so verbunden, dass es für eine andere Agentur sehr schwer wäre, in unser Deployment System sinnvoll einzugreifen.
Wir sind rechtlich auch dazu verpflichtet, immer aktuelle Software-Versionen für die Uni einzusetzen. Wir waren zuletzt auf Version 9 und da gab es keine Aktualisierungen mehr, es sei denn, man hätte einen Extended Support oder Ähnliches erworben. Das hätte aber nur eine Verzögerung dargestellt. Deswegen sind wir fast jedes Jahr oder jedes zweite Jahr dazu angehalten, eine Hauptversion zu aktualisieren.
Zunächst war geplant, von Version 9 auf 10 umzusteigen. Dann haben wir aber festgestellt, dass die 11er Version bereits soweit fertig und schon in vielen Iterationen draußen ist, sodass man sie auch aus universitärer Sicht als stabil und einsatzfähig bezeichnen kann. Deswegen haben wir gleich den Schritt zur 11er Version gewagt und 10 übersprungen. An einigen Stellen hat das aber auch zu Schwierigkeiten und längeren Entwicklungszeiten geführt.
Apropos Schwierigkeiten, welche Herausforderungen hat das Update genau nach sich gezogen?
Die größte Herausforderung war gar nicht unbedingt TYPO3 an sich, sondern die Umstellung des ganzen Deployment Systems und der Serverarchitektur. Im Zuge des Updates haben wir an der Uni ein eigenes Git Repository aufgesetzt. Das frühere Repository inkl. Deployment Tool wurde zusammen mit neuen Server bei uns im Haus modernisiert. Diese ganzen technischen Umstellungen waren für uns als Uni, insbesondere unter dem Aspekt des Personalmangels, eine große Herausforderung. Das hat auch zu Verzögerungen geführt, weil wir nicht so schnell und so stabil online waren, wie es wünschenswert gewesen wäre.
Eine weitere Herausforderung lag in teilweise essentiellen Extensions, die für TYPO3 noch nicht öffentlich zur Verfügung standen. Durch etwas Kreativität haben wir dann doch gemeinsam eine Lösung gefunden, um beispielsweise wieder ein Grid-System für Seiteninhalte zu ermöglichen.
Eine weitere Herausforderung besteht in dem Testen von neuen Seiten. Wenn das System umgestellt wird, versucht man natürlich, über Tests viel herauszufinden. Was funktioniert und was ggf. nicht. Da das Testen sehr händisch ist, ist es irgendwie auch unstrukturiert. Das System ist komplex. Man hat so viele Möglichkeiten, zumindest in unserem System, Inhalte, Plugins usw. in verschiedenen Konstellationen einzusetzen oder auch von Formularen Gebrauch zu machen. Das alles zu testen und dabei auch in einer systematischen Weise vorzugehen, dafür haben wir bisher noch keine gute Lösung gefunden, weil es uns unter anderem auch an Manpower fehlt.
Automatisiert kann man zwar technische Tests laufen lassen, so wie es auch eine Extension prinzipiell tut, aber ob es im speziellen Kontext dann auch genauso abläuft wie erwartet, das war dann doch sehr viel “Trial and Error”. Teilweise haben wir Dinge live ausgespielt, die dann unsere Redakteure bemängelt haben. Anschließend mussten diese Fehler beseitigt werden.
Mit der Migration haben wir nicht viele Probleme gehabt. Das liegt hauptsächlich daran, dass wir nur wenig migrieren mussten - also von einer Version zur nächsten. Bei ein paar Extensions war das schon der Fall. Aber das war keine Komplettmigration, in dem Sinne, dass man neue Templates oder ein neues Design gehabt hat. Das war nur eine technische Herausforderung.
Wie wurden die Probleme bzw. Herausforderungen letztendlich gelöst?
Die meisten Lösungen hängen im gesamten Prozess an den jeweiligen Personen. Auf in2code Seite waren es, soweit ich es mitgekriegt habe, insgesamt 4 Personen. Auf Uni Seite waren es nur 2. Mein Kollege, der die Server betreut, und ich.
Uns ist es am besten gelungen, indem wir miteinander kommunizierten. Das haben wir in der Regel sehr gut geschafft. Die Abwicklung über das Ticketsystem und Trello hat dabei besonders geholfen. Hervorzuheben ist die sehr strukturierte Arbeitsweise von Marcus Schwemer, der Teil des in2code Hochschulteams ist. Die Tickets wurden von ihm aufgesetzt und dann nach und nach abgearbeitet. Wenn es Probleme bzgl. spezieller Extensions ging, hat er sich Hilfe von seinen Kollegen geholt. Die Kommunikation über Trello und das Ticketsystem fand fast täglich statt. Ich konnte so alles mitlesen, den aktuellen Stand der Dinge verfolgen, sehen, wo es Probleme gibt und ob Rückmeldung von unserer Seite aus benötigt wird, wenn ein Kollege nicht weiterkommt.
Gab es vorab bestimmte Anforderungen von Seiten der Uni Ulm?
Wichtig war, eine Systemarchitektur aufzubauen, um eine Übergangszeit für die Redakteure, die sich mit dem neuen System vertraut machen konnten, sicherzustellen. Als wir im Prinzip in der Lage gewesen sind, zu aktualisieren, lag die Anforderung im Umschalten vom System ohne Datenverlust und dass das Update für die Redakteure möglichst reibungslos und unter wenig Pausenzeiten abläuft.
Das Update ist ja ein Prozess, der so etwa 24 bis 36 Stunden dauert. Mit Redaktionsstopp setzte dann das eigentliche Update an. Die Redakteure konnten ab diesem Zeitpunkt also nicht mehr ins Backend und nichts mehr eintragen. Dabei haben wir aber eine Sache nicht bedacht. In der Zeit, in der das Update lief, wurden trotzdem Formulare im Frontend ausgefüllt, abgeschickt und gespeichert. Diese Daten mussten wir nochmal mühsam über das alte System und über einzelne Instanzen mit letztem Datenstand wiederherstellen.
Aktuell arbeiten wir daran, dass das neue System schneller in der Auslieferung von Seiten wird, vor allem denen, die noch nicht gecacht sind. Aber ich bin sehr zuversichtlich, dass wir das auch in Zukunft weiter optimieren können.
Klaus, von meinen Kollegen habe ich erfahren, dass du in deiner Freizeit DJ bist und Musik auflegst. Kannst du uns dazu noch was mitgeben?
Ja, ich bin mit Leidenschaft DJ und lege in meiner Freizeit elektronische Tanzmusik auf. Meistens auf meinen eigenen Events, die ich seit einigen Jahren in Ulm organisiere. Unter dem Begriff Ecstatic Dance bringe ich die Besucher*innen zum barfuß tanzen und meine Freude ist es, am Ende einer Veranstaltung in meist glückliche Gesichter zu schauen. :-)
Falls sich jemand für die Musik und /oder Veranstaltungen interessiert: unter www.shiva-dance.de finden sich meine Events und unter www.mixcloud.com/ShivaDanceUlm/ kann man einige meiner Sets anhören.
Vielen Dank nochmals an Klaus für das tolle Gespräch und den interessanten Einblick in unsere Zusammenarbeit. Wir freuen uns, die Uni Ulm Website auch in Zukunft betreuen zu dürfen und künftige Hürden gemeinsam zu meistern.