Pressemitteilung

Offen und frei verfügbar: Code des OVH Kundencenters endlich als Open Source

2018
Pressemitteilung
Deutschland

""Die während des Summit 2016 angekündigte Öffnung des Quellcodes für das Kundencenter wurde nun umgesetzt. Ab jetzt kann sich jeder über unser GitHub an der Entwicklung beteiligen. Die Offenlegung der schon lange verwendeten Anwendung von OVH − eine Schnittstelle, über die Nutzer mit wenigen Klicks sämtliche Dienstleistungen verwalten können − war ein großes Abenteuer. Im Folgenden berichten wir über diese Erfahrung und beschreiben, was wir daraus gelernt haben. Ein Bericht vom UX-Team. Warum ein offener Quellcode? Neben der Befreiung der Organisationskultur zeichnete sich bei OVH seit einigen Monaten eine weitere Befreiung ab: die unseres Kundencenters. Es ist das Herzstück OVH Dienstleistungen, jeder Kunde verwaltet darüber seine Dienste. Aus diesem Grund spielt es natürlich auch eine bedeutende Rolle in der Arbeit des UX-Teams. Als Entwickler, die sich ganz der Nutzererfahrung verschrieben haben, sind wir der Meinung, dass ein frei verfügbarer Quellcode zahlreiche Vorteile mit sich bringt. Diese Vorteile bestärken uns in der Überzeugung, dass Open Source zum Standard in der IT-Branche geworden ist.

Von Anfang stand der Gemeinschaftssinn bei OVH im Vordergrund. Wann immer möglich, sind wir auf die Bedürfnisse unserer Nutzer eingegangen und haben Vorschläge und Kritik aufgenommen. So konnten wir wachsen und uns weiterentwickeln. Jetzt war es an der Zeit, einen weiteren Schritt zu gehen und eine gemeinschaftliche Entwicklungsumgebung schaffen. Gemeinsam können wir die Gesamtqualität des Kundencenters auf effizientere Weise verbessern. Dies konnten wir bereits anhand von Bug Bounty feststellen, einem Bug-Erkennungsprogramm, das wir im Sommer 2016 ins Leben gerufen haben. Es korrigiert Rechtschreibfehler im Interface, die von eifrigen Duden-Fans regelmäßig und mit mehr oder weniger Nachsicht in den sozialen Netzwerken gemeldet werden. Die Community kann nun insbesondere auch neue technische oder bedienerfreundliche Ideen einbringen. Das Beste dabei: Da Sie das Kundencenter (fast) täglich nutzen, sind Sie selbst der Experte. Das Ziel ist, unsere Vorgehensweise für zukünftige Entwicklungen des Kundencenters so an Ihre Bedürfnisse anzupassen.

Darüber hinaus steht ein offener Quellcode durch die Bereitstellung von Changelogs, Commits und weiteren GitHub-Labels für zusätzliche Transparenz. Diese Bestandteile zeigen Ihnen jederzeit, in welche Richtung sich das Projekt entwickelt und geben Ihnen die Möglichkeit, selbst Einfluss darauf zu nehmen. Einfachere Beteiligung Der erste Schritt zur Beteiligung aller war die Öffnung des Quellcodes. Einfacher gesagt als getan: Das OVH Kundencenter blickt auf eine lange Geschichte zurück und barg ursprünglich in einigen Bereichen gravierende technische Mängel. Die schwerwiegendste Baustelle blieb Ihnen somit verborgen. Im Folgenden sehen wir uns an, wie wir vorgegangen sind. Richtlinien offen für Vorschläge Eine erfolgreiche Zusammenarbeit bedarf einiger Rahmenbedingungen. Aus diesem Grund war die Erstellung einer eindeutigen Dokumentation erforderlich. Ziel war die Homogenität im Gesamtbestand, sowohl in Bezug auf den Code als auch auf die Methodik der Beiträge. Ist die Dokumentation nicht präzise genug, bleibt der Nutzen gering. Eine zu schwerfällige und restriktive Dokumentation erschwert jedoch die Beteiligung. Gar nicht so einfach, die goldene Mitte zu finden. Daher sind auch unsere Richtlinien offen für Ihre Vorschläge. Die gemeinsamen Richtlinien enthalten folgende Dateien:

  • README.md: Zusammenfassung der erwarteten Form in unseren Repositorys
  • CODE_OF_CONDUCT.md: Definition der Verhaltensregeln für Mitwirkende
  • CONTRIBUTING.md: Hierbei handelt es sich um ein dickes, verstaubtes Buch, das alle Regeln enthält, die für die Beteiligung an sämtlichen Projekten notwendig sind
  • ISSUE_TEMPLATE.md: GitHub-Template, mit dem das Problemformular vorab ausgefüllt werden kann. So können dank des ähnlichen Formats Probleme schnell behandelt werden
  • PULL_REQUEST_TEMPLATE.md: identisch mit dem ISSUE_TEMPLATE, jedoch für Pull Requests
  • LICENSE.md: beschreibt die in den Projekten zu verwendende „3-Klausel-BSD“

Toolbox Neben den Richtlinien selbst bieten wir verschiedene Tools an, die deren Einhaltung erleichtern:

<emoji> <type>(<scope>): <subject>

<BLANK LINE>

<body>Kundencenter Müller

<BLANK LINE> <footer>

Wir haben uns natürlich von bestehenden Normen wie zum Beispiel Angular inspirieren lassen, um eine allen Mitwirkenden vertraute Umgebung zu schaffen.

  • Changelog-Generator: Es handelt sich um ein Node.js-Skript, mit dem ein Changelog im Standardformat erzeugt werden kann. Dies geschieht mithilfe des spezifischen Commit-Nachrichten-Formats.

Beispiel für ein Changelog. Hier der Chatbots.  

  • JavaScript-“Linter“ und Stylesheet-“Linter“: Diese Tools überprüfen Syntax und Format des Codes, damit sie in möglichst vielen Repositorys übereinstimmen. Das Lesen des Codes ist leichter, wenn die Syntax nicht allzu exotisch ist. So kann man sich einfacher auf den Code selbst konzentrieren.

Sich neben dem Code selbst auch mit all diesen Tools vertraut zu machen, bedeutet schon einigen Aufwand. Deshalb verwenden wir den allseits bekannten Makefile-Standard, um die Installation des Kundencenters zu erleichtern. Die zwei wesentlichen Befehle lauten: make install make dev Da erzählen wir Ihnen nichts Neues: Der erste Befehl installiert die für den Betrieb des Kundencenters nötigen Abhängigkeiten. Der zweite startet die Entwicklungsumgebung. Danach können Sie direkt loslegen! Den Code entstauben: mühsam, aber notwendig Wie sind wir bei der Offenlegung des Codes vorgegangen? Hier die wichtigsten Schritte.

Damit das Kundencenter funktioniert, werden Software-Bausteine benötigt, die wir Komponenten nennen. Um diese Komponenten freizugeben, wurden 53 GitHub-Repositorys erstellt und anschließend in NPM und Bower veröffentlicht. Die Offenlegung so vieler Komponenten als Open Source ist eine langwierige Angelegenheit, vor allem, da der Code nicht immer den heutigen Qualitätsstandards entsprach. Politisch weniger korrekt ausgedrückt: Einige Teile des Quellcodes sahen verdammt hässlich aus und benötigten einen frischen Look (man werfe den ersten Stein...). Nach der optischen Auffrischung wurden die wesentlichen Komponenten veröffentlicht. Anschließend stellten wir das Telekom-Kundencenter auf GitHub bereit. Warum das Telekom-Kundencenter? Der Telekom-Manager als neuester Teil des Kundencenters enthielt den geringsten Teil an sogenanntem Legacy Code. Es musste nur wenig umgestaltet werden: Die größte Aufgabe bestand darin, sicherzugehen, dass Kommentare oder Teile des Codetextes weder für Sicherheitslücken verantwortlich noch hinfällig waren oder OVH-interne Kommentare enthielten. Nach der Offenlegung dieses Bereichs im Kundencenter folgte der Cloud-Manager. Aufgrund eines ähnlichen Code-Aufbaus von Cloud- und Telekom-Manager wurde hier dieselbe Methode angewendet. Das machiavellistische Erbe des Web-Kundencenters In zwei Kundencenter-Bereichen kam es zu technischen Verzögerungen, da die Veröffentlichung im damaligen Zustand nicht möglich war: im Web-Manager und im Dedicated-Server-Manager. „Das Mögliche wurde bereits umgesetzt. Das Unmögliche ist in Bearbeitung. Für Wunder sollte man sich auf eine Wartezeit von 48 Stunden einstellen.“ Diese Lebensweisheit ist auch einwandfrei auf die IT übertragbar, wenn man versucht, einen technischen Fehler, der fast 19 Jahre lang liebevoll gehegt und gepflegt wurde, mit einer Armee von Entwicklern auszumerzen.

Wir waren der Meinung, dass die ältesten Teile des Kundencenters einen frischen Touch verdient hätten und begannen mit der Partie, die auf eine reichhaltige (und wechselvolle) Geschichte zurückblickt: dem Web-Manager. Damit Sie eine konkretere Vorstellung bekommen: Wir sprechen von ca. 32.000 Zeilen JavaScript, 800 HTML-Templates und Unmengen von CSS-Dateien. Es ging also nicht darum, die Wände weiß zu streichen und den Teppich auszutauschen. Eine solche Großbaustelle beseitigt man nicht auf einmal, es bedarf vieler kleiner, wohlüberlegter Schritte. Zunächst haben wir den Code komplett überarbeitet. Alles, insbesondere die JavaScript-Dateien und ihre Umstellung auf ES6 und AngularJS (Version 1.3 und höher), sollte den neuesten Normen entsprechen und gleichzeitig für die Community, die am GitHub-Projekt arbeiten sollte, gebräuchlicher sein. Um Rückschritte zur vermeiden, nutzten wir Tools wie „Prettier“ und „SonarJS“. Sie sind von großer Hilfe bei der Erkennung von Bugs sowie zur Vereinheitlichung von Dateien. Anschließend kamen die HTML-Dateien in den Genuss einer Verjüngungskur. Auch hier haben wir das DOM vereinfacht und das Projekt in die gleichen Programmbibliotheken wie die Telekom- und Cloud-Manager migriert (wie Bootstrap 3). Nach Beendigung dieser Nachrüstung sind wir nun bei der Umsetzung des zuvor beschriebenen Prozesses für die Offenlegung der Telekom- und Cloud-Kundencenter. Dieselbe Vorgehensweise wurde inzwischen für das Dedicated-Kundencenter angewendet. Auch die für den Web-Manager verwendeten Komponenten sind auf GitHub veröffentlicht und der Code wurde Ende 2017 bereitgestellt. Make the fork be with you Wie Sie sehen ist die Offenlegung des Quellcodes für das OVH Kundencenter eine Baustelle, für die gerade erst die Fundamente gelegt werden. Die nächsten Schritte sind für die Community und für alle, die sich an diesem Projekt beteiligen möchten, von größter Bedeutung.

Jedem Nutzer soll letztendlich die Möglichkeit zur Abspaltung (Fork) des OVH Kundencenters und zur Anwendung in der eigenen Infrastruktur gegeben werden. Ob Sie nun ein Kundencenter für sehr spezielle Zwecke anpassen oder ein White Label erstellen möchten, das Kundencenter gehört Ihnen! Ihnen ist sicher schon aufgefallen, dass wir immer von dem „OVH Kundencenter“ sprechen. In Wirklichkeit handelt es sich aber um unterschiedliche Basiscodes, die zu je einer Produktwelt von OVH gehören: Telekom (in Frankreich), Cloud, Web und Dedicated. Dies geht auf eine veraltete Organisationsstruktur zurück. Die Trennung der unterschiedlichen Produktwelten im Kundencenter führte zu den von Ihnen festgestellten Unterschieden in den Bereichen Technik und Benutzerfreundlichkeit, worüber Sie so oft geschimpft haben. In den kommenden Monaten arbeiten wir an der Vereinheitlichung von Technik und Benutzerfreundlichkeit in den OVH Kundencentern. Denn wir möchten, dass Sie sich als Nutzer und Entwickler wohl fühlen. Das Abenteuer geht weiter. Mit Ihnen!  ""