In der Vergangenheit wurde Psono.com von Odoo v11 betrieben. Odoo ist ein großartiges CMS, aber wie wir lernen mussten, sind Updates schwierig. Besonders ihr Website-Modul verursachte während unserer Tests viele Probleme. Odoo v11 wird Ende 2020 das Ende seines Lebenszyklus erreichen, daher waren wir gezwungen, eine Lösung zu finden.
Wir dachten über verschiedene Optionen nach: entweder ein Update auf Odoo v13 und die manuelle Migration aller Inhalte und Anpassungen selbst, jemanden beauftragen, der die Migration für uns übernimmt, oder komplett zu einem neuen CMS migrieren. Wir haben uns entschieden, Psono.com komplett zu migrieren und werden v11 hinter einer Firewall weiter verwenden und später migrieren (das haben wir noch nicht entschieden).
Die Gründe für diese Entscheidung:
- Wir haben nur eine sehr geringe Menge an Inhalten, die wir für Psono.com migrieren müssten. Hauptsächlich einige Blogbeiträge.
- Eine Migration zu Odoo v13 würde dasselbe Problem in zwei Jahren reproduzieren, wenn v13 sein EOL erreicht, möglicherweise mit einer viel größeren Datenmenge, die zu migrieren ist.
- Wir waren nicht besonders zufrieden mit den Anpassungsmöglichkeiten von Odoo v11-Websites. Alles ist extrem komplex, da ihre Vorlagen in der Datenbank gespeichert sind.
- Die Kosten. Jemanden für die Migration zu beauftragen, würde uns mindestens 5000 USD kosten, möglicherweise mehr.
- Die Community von Odoo war sehr aktiv, aber mit der Entwicklung in den letzten Jahren von Lizenzwechseln und dem Migrieren von Funktionalitäten und Plugins zu kostenpflichtigen Lösungen und dem Verstecken hinter einer Paywall ist die Community tot.
- Psono.com ist hauptsächlich eine statische Website mit statischen Inhalten. Wenn wir dynamische Inhalte benötigen würden, könnten wir sie über APIs einziehen.
Die Reise
Nachdem wir die Entscheidung getroffen hatten, zu migrieren, mussten wir uns für ein Framework entscheiden. Es gibt klassische Frameworks wie z.B. Hugo, das wir benutzten, aber deren Funktionalität ist begrenzt. Auf der Suche nach Alternativen fanden wir einige Lösungen in der Node/React-Welt.
Ich wollte hier "exzellente Lösungen" schreiben, aber ich denke nicht, dass irgendetwas im derzeit gebrochenen Zustand der Frontend-Entwicklung diesen Titel verdient. Gebrochen, fragen Sie? Erinnern Sie sich an die Zeiten, in denen Entwickler eine Website mit einer index.html und einem Skript-Tag zum Laden von jQuery erstellen konnten und dann mit der Entwicklung von Websites beginnen konnten? Jetzt benötigt man npm oder Yarn, man muss package.json, webpack-Skripte, moderne Frameworks wie Angular oder React verstehen, die alle ihren eigenen Client mitbringen. JSX oder Typescript. Funktionen wie das Hot-Reloading funktionieren nicht zuverlässig (Datei nicht überwacht, einige Änderungen erfordern einen kompletten Neustart oder das Hot-Reloading wird zu früh ausgelöst, sodass man trotzdem manuell aktualisieren muss), sodass man am Ende Entwicklungserver beenden und Minuten warten muss, bis sie wieder hochfahren (zumindest bei größeren Projekten). (Ich vermisse das Drücken von F5 und dann ist einfach alles da, ohne Probleme!). Ganz zu schweigen von einem neuen Framework oder Tool mindestens alle sechs Monate, bei dem alte Tools täglich aufgegeben werden. Ich könnte leicht Seiten damit füllen, mich über den aktuellen Stand der Frontend-Entwicklung zu beklagen. Wie auch immer, zurück zum eigentlichen Thema.
In Ermangelung vernünftiger Alternativen wären die besten Optionen (zum Zeitpunkt, als ich dies schrieb) next.js und gatsby. Zumindest haben einige Artikel sie so beworben. Beide sind gleich beliebt, wenn man Github-Sterne oder Commits vergleicht. Der einzige Unterschied, den wir bei einer ersten Bewertung feststellen konnten, ist die Anforderung einer Serverkomponente für next.js, während gatsby statische Seiten erstellt (bitte tötet mich jetzt nicht, wenn es eine Option gibt, next.js ohne aktiven Server zu betreiben! :D).
Also haben wir ein wenig mit Gatsby gespielt und es sah gut aus. Als nächsten Schritt gingen wir weiter und suchten nach einem Thema. Gatsby ist ein "neues" Tool, daher waren alle Themen, die wir finden konnten, noch in einem sehr grundlegenden Zustand. Dreißig Minuten und dreißig Dollar später hatten wir ein optisch ansprechendes Thema, das zumindest einige der erforderlichen Komponenten abdeckte, und wir begannen, es zu modifizieren.
Als Hosting-Option können Sie heutzutage zwischen mehreren Anbietern wählen, nämlich Firebase, netlify, Cloudflare, Vercel, einfachem GCP-Cloud-Speicher oder AWS Cloudfront, eigene Server, Docker-Container, die auf Kubernetes laufen (das musste ich erwähnen!)... (Erinnern Sie sich an die alten Zeiten, in denen man für 5 Dollar im Monat einen Webspace mit PHP und einer MySQL-DB mieten konnte :D ... aber das ist ein Thema für einen anderen Artikel...).
Nachdem wir sie verglichen, einige Bewertungen gelesen und mögliche Kombinationen (wie Cloudflare vor Firebase) überprüft hatten, versuchten wir zunächst Cloudflare. Als große Fans ihres Dienstes war es eine natürliche Wahl, doch leider hatte ihr Wrangler-Tool Probleme. Zuerst warf es immer einen Fehler, und dann konnten wir uns nicht authentifizieren ... Die anfänglichen Fehler waren am nächsten Tag verschwunden (vielleicht hat ein neuer Bash den Trick gemacht), doch das Authentifizierungsproblem blieb bestehen. Ich glaube, dass ich einen Fehler gemacht haben muss und gab nach ein paar Stunden des Lesens ihrer Dokumentation und Versuchs verschiedener Lösungen auf.
Netlify war ein weiterer Kandidat, doch entweder muss man es mit einem Git-Anbieter verbinden und es von ihnen erstellen lassen (wir wollten GitLab CI verwenden) oder den Build-Output manuell hochladen. Vielleicht haben sie irgendwo eine Option, den Build-Output über eine API hochzuladen, doch ich konnte keine finden. Eine Alternative wäre ein Repo gewesen, in das wir den Build-Output tatsächlich pushen, doch das schien unnötig komplex... Ein weiteres Problem für mich ist ihr Preismodell. Sie berechnen pro Mitglied (!!!) einen ziemlich beträchtlichen Betrag. Beachten Sie, dass dies für eine statische Website ist. Aussagen wie "4× Bandbreite" lösen schlechte Erinnerungen an "Fair-Use-Webhosting"-Zeiten aus, in denen Leute einem den Stecker zogen, wenn man zu viel nutzte...
Als vierten Dienst versuchten wir Firebase (was als Vorteil kostenlos für unsere Zielbandbreite und Anfragen ist) und alles funktionierte sofort. Ihre Umleitungsmöglichkeiten sind etwas begrenzt, daher wurde das Zuordnen alter URLs zu schöneren etwas mühsam, aber ein paar Umleitungsregeln später funktionierte alles. Ihre Preisgestaltung scheint vernünftig und Sie zahlen für Server-Ressourcen. Man sollte alle ihre Zusatzdienste meiden, um Vendor-Lock-In zu vermeiden, doch wir brauchten nur Hosting.
Wir haben uns auch kurz Vercel angesehen, doch ihre Anforderung, sich mit einem Github-Konto anzumelden und dann eine Berechtigung mit "In meinem Namen handeln" zu gewähren, hat mich schon vor der Anmeldung abgeschreckt.
Der Blog war am schwierigsten zu migrieren. Wir haben schließlich alle Inhalte manuell kopiert. Das ist nichts, was man mit einem größeren Blog tun sollte, doch unser Blog hatte nur fünfzehn Beiträge. Gatsby unterstützt mehrere Mechanismen, doch wir wollten etwas Einfaches, das jemand ohne technischen Hintergrund in der Lage sein würde, neue Blogbeiträge zu erstellen. Wir entschieden uns für Markdown und mussten daher lernen, wie man Gatsby anweist, Markdown-Seiten zu lesen. Der eigentliche Mechanismus dauerte etwa einen halben Tag mit der gesamten Bildverarbeitung. Ein schönes Blog-Post-Thema und Bilder nochmal einen halben Tag.
Nach der Migration aller Inhalte und der weiteren umfangreichen Modifikation des Themas automatisierten wir unseren Deployment-Prozess mit Gitlab CI, sodass ein einfacher Push unsere Build-Pipeline auslösen und alles zu Firebase bereitstellen würde.
Warum Gitlab und nicht Github? Github hat aus historischen Gründen die Führung. Sie haben derzeit mindestens 80% aller Entwickler und Projekte. Gitlab hingegen liefert Features. Deshalb haben wir uns in der Vergangenheit für Gitlab entschieden, da es jahrelang keine wirkliche Feature-Entwicklung bei Github gab. Das hat sich nun dramatisch verändert, seit Microsoft Github gekauft hat, und Github Actions sind ein Meilenstein, doch Github hat noch einen langen Weg vor sich, wenn sie mit Gitlab konkurrieren wollen. Für uns, die alle ihre Projekte auf Gitlab hosten, war es daher eine natürliche Wahl, es auch für dieses Projekt zu verwenden.
Das Fazit
Und hier sind wir nun:
- Gatsby als CMS
- Kommerzielles Thema
- Markdown-basierter Blog
- Gitlab CI für automatisierte Bereitstellungen
- Firebase Hosting
Wir waren mit diesem Ergebnis ziemlich zufrieden und die neue Website sieht viel besser aus!
