WordPress-Websites, die auf einer schnellen Infrastruktur laufen, können trotzdem Zuverlässigkeitsprobleme haben – vor allem, weil diese Infrastruktur nur bestimmt, wie schnell Seiten geladen werden. Es ist der „Change-Management-Prozess“ des Unternehmens, der darüber entscheidet, ob die Website weiterhin funktioniert, nachdem jemand ein Plugin aktualisiert, ein Redesign umgesetzt oder die PHP-Version aktualisiert hat.
Deshalb ist der Prozess der Kontrolle, des Testens, der Freigabe und der Wiederherstellung nach Änderungen an einer Produktionsumgebung eines der wichtigsten Kriterien, anhand derer Unternehmensteams Hosting-Plattformen bewerten.
Eine Plattform, die keinen disziplinierten Änderungsprozess unterstützt, zwingt Teams dazu, eigene Kontrollmechanismen zu entwickeln: manuelle Backups vor dem Update, die per Chat weitergeleitet werden, informelle Genehmigungsschritte und das Löschen von Problemen nach der Bereitstellung, was Ingenieure immer wieder von ihrer eigentlichen Projektarbeit abhält.
Warum das Änderungsrisiko das Hauptanliegen von Unternehmen ist
Der Umfang der Änderungen, die eine WordPress-Umgebung im Laufe ihrer Lebensdauer erfordert, ist größer, als es auf den ersten Blick scheint. Zum Beispiel:
- Core-Releases erscheinen in der Regel nach einem festen Zeitplan.
- Bei einer komplexen Installation können sich Plugin-Updates auf Dutzende pro Monat belaufen.
- Upgrades der PHP-Version wirken sich auf die gesamte Ausführungsumgebung aus.
- Änderungen am Datenbankschema gehen mit größeren Plugin-Versionen einher und können zu Konflikten mit Anpassungen führen, die auf der vorherigen Struktur basieren.
In Unternehmen, in denen WordPress ein Kundenportal, einen compliance-kritischen Content-Workflow oder eine umsatzstarke E-Commerce-Plattform betreibt, wirkt sich jede Änderung auf zahlreiche Abhängigkeiten aus, die nicht immer dokumentiert sind. Die Ursache für etwaige Ausfälle liegt jedoch oft eher in einer Bereitstellung ohne zuverlässigen Testpfad als in der Infrastruktur selbst.
Ein Hosting-Anbieter, dem formalisierte Staging-Umgebungen, Rollback-Pfade oder Zugriffskontrollen fehlen, bedeutet, dass die Verantwortung für deren Einrichtung bei deinem Team liegt. Daher lauten die wichtigsten Fragen: Ist die Bereitstellung vorhersehbar und ist die Wiederherstellung infolgedessen schnell?
Wie Staging-Umgebungen einen sicheren Testpfad vor der Produktion schaffen
MyKinsta bietet dir die Tools, um einen disziplinierten Änderungsprozess durch Staging-Umgebungen, selektive Pushes, mehrstufige Backups und rollenbasierte Zugriffskontrollen zum Standard zu machen – statt ihn als zusätzlichen Aufwand zu betrachten.
Jeder Kinsta-Tarif beinhaltet eine kostenlose, containerisierte Standard-Staging-Umgebung pro Website. Um eine solche zu erstellen, navigiere zu Websites, wähle die Website aus, die du ins Staging übernehmen möchtest, klicke auf die Umgebungsauswahl (z. B. Live) und wähle Neue Umgebung erstellen. Du kannst die bestehende Live-Umgebung klonen, eine leere WordPress-Instanz installieren oder eine leere Umgebung für eine benutzerdefinierte Konfiguration erstellen.
Das Premium-Staging-Add-on von Kinsta bietet zusätzlich zu der einen kostenlosen Standardumgebung, die in jedem Tarif enthalten ist, bis zu fünf Premium-Staging-Umgebungen pro Website. Das ist ideal, wenn du parallele Entwicklungsstränge betreibst, ressourcenintensive Funktionen validieren musst oder unter Bedingungen arbeitest, die denen der Produktion entsprechen müssen. Es lohnt sich, die Unterschiede zwischen den beiden Umgebungstypen zu kennen, wenn du deinen Workflow planst:
- Standard-Staging läuft immer auf einer einzelnen CPU und verfügt über eine feste RAM-Zuweisung. Server-Caching ist verfügbar, jedoch ohne CDN- oder Edge-Caching-Unterstützung. Es eignet sich für Plugin-Updates, Design-Reviews und das Testen von Content-Workflows.
- Premium-Staging entspricht dem Ressourcenprofil deines Live-Containers und bietet dir sowohl CDN-Verfügbarkeit als auch Edge-Caching-Unterstützung. Du nutzt dies, wenn Tests Konfigurationen mit hohem Datentraffic, WooCommerce-Integrationen oder Verhaltensweisen beinhalten, die nur unter Lasten im Produktionsmaßstab auftreten.
Bei Plugin- oder Theme-Updates sollte dein Staging-Workflow Folgendes umfassen: das Ausführen des Updates, das Überprüfen aller Integrationspunkte, die davon betroffen sein könnten, das Einholen der Freigabe durch die relevanten Beteiligten und erst dann die Vorbereitung des Pushs in die Produktion. Das lässt sich ganz einfach durchsetzen, wenn Staging und Produktion getrennte Umgebungen sind.
Der Kinsta-Kunde Itineris baut seine Workflows für Unternehmenskunden auf der Staging-Infrastruktur von Kinsta auf:
Staging-Umgebungen, automatisierte Backups und eine robuste Infrastruktur waren entscheidend für die Optimierung unserer Workflows und die Verbesserung der Website-Performance.
Wie selektive Übertragungen den Umfang jeder Bereitstellung steuern
Staging beseitigt Risiken in der Testphase, doch das Übertragen der gesamten Staging-Umgebung in die Produktion birgt ein anderes Risiko. Nun werden jede Datei und jede Datenbanktabelle ersetzt, einschließlich Änderungen, die nicht Teil der beabsichtigten Bereitstellngen sind (wie z. B. Testinhalte).
Mit dem selektiven Push von Kinsta hast du die volle Kontrolle darüber, was genau von der Staging-Umgebung in die Produktion übertragen wird. Um diese Funktion zu nutzen, wähle deine Staging-Umgebung in MyKinsta aus, klicke auf Umgebung übertragen und wähle einen Bereitstellungs-Umfang:
- Dateien. Hiermit werden Themes, Plugins und Code-Änderungen übertragen, während die Live-Datenbank unverändert bleibt. Nutze diese Option, wenn die Staging-Datenbank nicht mit den Produktionsdaten synchron ist oder wenn die Änderung nur die Codebasis betrifft.
- Datenbank. Hier kannst du Datenbankänderungen übertragen, während die Produktionsdateien unverändert bleiben. Nutze diese Option für strukturelle Änderungen wie Aktualisierungen benutzerdefinierter Beitragstypen oder in der Datenbank gespeicherte Plugin-Konfigurationen.
Außerdem stehen dir Dropdown-Menüs zur Verfügung, um den Push weiter zu verfeinern. Du kannst beispielsweise bestimmte Dateien, Ordner oder Datenbanktabellen auswählen.
Vor jedem Push in eine Live-Umgebung erstellt Kinsta automatisch ein systemgeneriertes Backup der Produktionsumgebung, das den Zustand unmittelbar vor der Bereitstellung erfasst. Es steht dir als Wiederherstellungspunkt zur Verfügung, sobald der Push abgeschlossen ist. Sollte der Push zu einem unerwarteten Ergebnis führen, erfolgt das Rollback als einzelner Vorgang in MyKinsta und nicht als Rekonstruktion aus einem Backup.
Der Schritt „Suchen und Ersetzen“
Wenn die Bereitstellung eine Änderung der URL-Struktur oder einen Domain-Wechsel beinhaltet, enthält die Datenbank Verweise auf die Staging-URL. Mit dem Such- und Ersetzungs-Tool von MyKinsta kannst du solche Änderungen aktualisieren.
Beachte, dass die Option Suchen und Ersetzen ausführen im Dialogfeld „Push to Live“ nur für die Datenbank funktioniert; für Dateien und Ordner musst du also einen zusätzlichen Schritt durchführen. Dazu gehst du auf dem Bildschirm Tools in MyKinsta für eine Website zum Tool „Suchen und Ersetzen“.
Gib hier die Staging-URL in das Feld „Suchen“ und die Produktions-URL in das Feld „Ersetzen durch“ ein. Sobald du auf Ersetzen klickst, führt MyKinsta eine vom System generierte Sicherung durch und führt anschließend die Suche und den Ersetzungsvorgang durch.
Zusammengenommen machen selektives Pushen, Backups vor dem Pushen und ein spezieller Such- und Ersetzungsschritt das Staging zu einem Prozess mit festgelegten Kontrollpunkten in jeder Phase.
Wie mehrstufige Backups die Folgen einer fehlgeschlagenen Änderung mindern
Selbst mit einer Staging-Umgebung und einem Workflow für selektives Pushen führen manche Änderungen zu unvorhersehbaren Fehlern. Beispielsweise kann sich eine API eines Drittanbieters mit Produktions-Anmeldedaten anders verhalten als in der Staging-Umgebung.
Backups können dir helfen, die Folgen in solchen Fällen zu begrenzen. Für eine Website in MyKinsta rufst du den Bildschirm Backups auf, um auf alle Backups zuzugreifen:
Kinsta deckt jede Phase des Bereitstellungszyklus mit vier Backup-Typen ab:
- Tägliche Backups werden automatisch ausgeführt und bleiben je nach deinem Tarif 14 bis 30 Tage lang erhalten. Jedes Backup ist ein vollständiger Snapshot einer Website.
- Vom System generierte Backups werden automatisch vor wichtigen Vorgängen ausgelöst, darunter das Übertragen von der Staging-Umgebung in die Live-Umgebung, das Anwenden eines Plugin- oder Theme-Updates, das Wiederherstellen eines Backups, das Ausführen einer Such- und Ersetzungsaktion sowie das Zurücksetzen einer Website. Vor jedem automatisch ausgeführten Vorgang werden immer Wiederherstellungspunkte erstellt.
- Mit manuellen Backups kannst du jederzeit über den Reiter Manuell bis zu fünf zusätzliche, mit Tags versehene Snapshots erstellen (die verfügbare Anzahl hängt von deinem Tarif ab). Diese decken Vorgänge ab, die außerhalb des automatisierten Zeitplans liegen, wie zum Beispiel ein PHP-Versions-Upgrade oder eine Datenbankmigration, die du über WP-CLI durchführst.
- Stündliche Backups sind als kostenpflichtiges Add-on in zwei Stufen verfügbar: Backups im 6-Stunden-Intervall und echte stündliche Backups. Die aktuellen Preise findest du auf der Add-ons-Seite.
Wenn du bei einem Backup auf die Schaltfläche Wiederherstellen nach klickst und dann die Zielumgebung auswählst, kannst du zu diesem bestimmten Backup zurückkehren. Sobald die Wiederherstellung abgeschlossen ist, erstellt MyKinsta ein neues Systemsicherungs-Backup, das den Zustand unmittelbar vor der Wiederherstellung widerspiegelt.
Wenn man einen Change-Management-Prozess rund um diese Art von Funktionalität aufbaut, lassen sich geplante Wartungsfenster und formelle Rollbacks zu einem einzigen, ausführbaren Workflow innerhalb von MyKinsta zusammenfassen. Konica Minolta hat beispielsweise seine Marketing-Website innerhalb von drei Monaten auf WordPress bei Kinsta umgestellt und die Zuverlässigkeit der Bereitstellung als Grundlage des Projekts identifiziert:
Unsere größte Sorge waren Ausfallzeiten und Leistungseinbußen während der Migration, aber das Team von Kinsta hat alles reibungslos und ohne jegliche Unterbrechungen abgewickelt.
Wie rollenbasierter Zugriff den Änderungsprozess teamübergreifend sicherstellt
Bei Unternehmensbereitstellungen sind in der Regel mehrere Beteiligte mit unterschiedlichen Zuständigkeiten in jeder Phase des Änderungsprozesses involviert.
Beispielsweise benötigen Entwickler Zugriff auf die Staging-Umgebung, um Änderungen zu erstellen und zu testen, während QA-Ingenieure diese Änderungen validieren müssen. Weiter unten in der Kette benötigen Projektmanager Einblick in den Inhalt der Staging-Umgebung, ohne diese in die Produktion schalten zu können, und kundenseitige Prüfer müssen den Staging-Status genehmigen.
Mit dem Zugriffsmodell und der Benutzerverwaltung von Kinsta kannst du sechs Rollen definieren und durchsetzen, wobei für das Änderungsmanagement in Unternehmen drei davon besonders relevant sind:
- Unternehmensentwickler können alle Websites und Staging-Umgebungen verwalten, auf DNS zugreifen, Analysen einsehen und Staging-Inhalte in eine Live-Umgebung übertragen. Sie haben keinen Zugriff auf Abrechnungsdetails, können keine Migrationen genehmigen und keine kostenpflichtigen Add-ons hinzufügen oder entfernen. Die Rolle eignet sich für interne Entwickler und technische Leiter mit voller Bereitstellungsberechtigung.
- Website-Administratoren haben die vollständige Kontrolle über eine bestimmte Website und alle ihre Umgebungen. Sie können jedoch keine Website aus dem Unternehmenskonto entfernen oder Premium-Staging-Umgebungen erstellen und löschen. Diese Rolle eignet sich für technische Verantwortliche, die für eine bestimmte Website zuständig sind.
- Website-Entwickler haben Zugriff auf alle Staging-Umgebungen der ihnen zugewiesenen Websites, können Staging-Umgebungen jedoch nicht in die Produktion übertragen. Für einen Auftragnehmer, der an einem Feature-Branch arbeitet, oder einen QA-Ingenieur, der einen Release-Kandidaten validiert, bietet diese Rolle Zugriff auf den Teil des Workflows, den ihre Position erfordert.
Mit MyKinsta ist es ganz einfach, einen Nutzer über die Seite Unternehmens-Einstellungen > Nutzer einzuladen. Hier kannst du über die Schaltfläche Nutzer einladen die E-Mail-Adresse eingeben und auswählen, ob du Zugriff auf Unternehmensebene oder auf Website-Ebene gewähren möchtest.
Zentralisierung des Zugriffs mit SAML-SSO
Wenn du ein Unternehmen bist, das den Zugriff auf mehrere Tools über einen zentralen Identitätsanbieter verwaltet, unterstützt Kinsta SAML-SSO mit jedem Identitätsanbieter (IdP), der den SAML-Standard nutzt. Dazu gehören Microsoft Entra ID, Okta, Google Workspace und viele andere.
Um dies zu aktivieren, navigiere in MyKinsta zu Unternehmens-Einstellungen > Single Sign-On und klicke auf Aktivieren. Von dort aus konfigurierst du die SAML-Anwendung in deinem IdP mithilfe der von MyKinsta bereitgestellten Verbindungsdaten und kehrst anschließend zu MyKinsta zurück, um die Einrichtung mit der SSO-URL, der Entity-ID und dem öffentlichen Zertifikat deines IdP abzuschließen.
Sobald das SSO aktiv ist, authentifiziert sich ein Benutzer über deinen IdP mit den bestehenden Unternehmenszugangsdaten. Durch die Aktivierung des obligatorischen SSO wird verhindert, dass Benutzer den IdP durch eine direkte Anmeldung umgehen. Wenn jemand die Organisation verlässt, wird sein Zugriff im IdP widerrufen, wodurch er gleichzeitig auch in MyKinsta entfernt wird – und zwar über denselben Prozess, der auch für alle anderen Tools im Stack verwendet wird.
Schließlich ist die Zwei-Faktor-Authentifizierung (2FA) standardmäßig für alle Konten erforderlich, die nicht unter SAML-SSO fallen. Ein Unternehmensinhaber kann die 2FA-Methode jedes Nutzers im Bildschirm Unternehmenseinstellungen > Nutzer > 2FA einsehen.
Change Management ist der Schlüssel zur sicheren Skalierung von WordPress im Unternehmensbereich
Für Unternehmensorganisationen ist die Hosting-Plattform die Infrastruktur, die bestimmt, wie sicher sich eine WordPress-Umgebung ändern lässt – und nicht nur, wie schnell sie läuft. Was Plattformen im Managed-Hosting-Bereich voneinander unterscheidet, ist die Frage, ob ein Team ein WordPress-Update bereitstellen kann, während gleichzeitig ein zuverlässiger Wiederherstellungsweg vorhanden ist, falls etwas schiefgeht.
Kinstas Staging-Umgebungen, selektives Push, das mehrschichtige Backup-System und die rollenbasierten Zugriffskontrollen geben Unternehmensteams die Werkzeuge an die Hand, um einen disziplinierten Änderungsworkflow durchzuführen, ohne diese Kontrollen selbst verwalten zu müssen.
Um zu sehen, wie das für dein Unternehmen aussieht, schau dir Kinstas WordPress-Hosting-Optionen für Unternehmen an und finde heraus, ob du deinen aktuellen Änderungsmanagement-Prozess überdenken solltest.
Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.
