Wenn du dir ein Venn-Diagramm vorstellst, würden die Staging-Umgebungen von Kinsta sowohl mit der Entwicklung für WordPress als auch mit deinem gewählten DevOps-Lebenszyklus konvergieren. Sie können Teil deines Workflows sein, von der ersten Planung bis hin zur Betriebsphase. Dazu gehören die lokale Arbeit mit WordPress, die Nutzung der Versionskontrolle und fast jede andere Aufgabe, die du während eines Zyklus hast.
In diesem Artikel werden wir uns mit der Entwicklung von Websites in den Staging-Umgebungen von Kinsta befassen. Wir werden das Ganze mit einem typischen DevOps-Lebenszyklus verknüpfen. Es gibt viel zu erklären, also fangen wir damit an, warum wir denken, dass du die Staging-Umgebungen von Kinsta nutzen solltest.
Die Vorteile von Kinsta’s Staging-Umgebungen
Die Staging-Umgebungen von Kinsta bieten dir Vielseitigkeit und Flexibilität, wenn es darum geht, Websites zu entwickeln und sie zu testen. Diese Umgebungen ermöglichen es dir, in einer Umgebung zu entwickeln, die deine Live-Umgebung widerspiegelt. Da dein Live-Server ebenfalls auf Kinsta läuft, ist dies ein zuverlässiges und genaues Testumfeld für deine Arbeit.
Natürlich kannst du Staging-Umgebungen über das MyKinsta-Dashboard erstellen, verwalten, klonen und löschen:
Wenn du mehr Flexibilität brauchst, kannst du mit dem Premium-Add-on für Staging-Umgebungen fünf weitere Umgebungen erstellen. Außerdem profitierst du von unserer robusten Infrastruktur, die das Premium Tier Network von Google und die Integration von Cloudflare umfasst.
Wie nicht anders zu erwarten, gibt es auch mehr Leistung unter der Haube. Je nach Tarif bekommst du bis zu 12 CPUs und 8 GB Arbeitsspeicher, eine auf deine Live-Site abgestimmte Anzahl von PHP-Workern und die Option, das Kinsta CDN für eine bessere Leistung zu aktivieren. Dieses Setup eignet sich für eine Reihe von Aufgaben wie A/B-Tests, Plugin-Kompatibilitätsprüfungen, ressourcenintensive Tests und vieles mehr.
Für die lokale Entwicklung ergänzt DevKinsta die gesamte Erfahrung. Sobald du die ersten Phasen überwunden hast, kannst du deine Website direkt in die Staging-Umgebungen von Kinsta übertragen.
Im Großen und Ganzen kannst du innerhalb des Kinsta-Ökosystems erstellen, entwickeln, entwerfen, testen und debuggen. Außerdem eignet es sich auch für deinen DevOps Lifecycle. Darauf werden wir in Kürze näher eingehen. Zunächst aber ein paar zusätzliche Informationen über die Staging-Umgebungen von Kinsta.
Einige Nebensächlichkeiten über Kinstas Staging
Die Staging-Umgebungen von Kinsta eignen sich hervorragend, um eine Website auf einem Live-Server zu testen, auch wenn dieser nicht produktiv ist. Es gibt jedoch einige Unterschiede zwischen Staging und Live bei Kinsta, die du kennen solltest:
- Erstens sind sowohl das Full Page Caching als auch der OPcache standardmäßig deaktiviert. Du kannst sie auf Wunsch aktivieren, aber ohne sie wirst du wahrscheinlich längere Ladezeiten haben.
- Auf die gleiche Weise ist auch die Seitenindexierung in WordPress deaktiviert. Du kannst diese Funktion zwar bei Bedarf wieder aktivieren, aber ein Aspekt, den du nicht abschalten kannst, sind unsere Header zur Einschränkung der temporären URL-Indizierung.
- Auch die Cron-Jobs werden im Staging-Modus nicht ausgeführt, obwohl sie immer noch vorhanden sind. Das bedeutet, dass du Änderungen an ihnen vornehmen kannst, die die Cron-Jobs auf deiner Live-Site ersetzen, sobald du sie live schaltest. Im Staging-Modus werden sie jedoch nicht ausgelöst.
- Beachte außerdem, dass deine WordPress-Zugangsdaten für deine Staging-Site die gleichen sind wie für deine Live-Site.
Es gibt noch einen weiteren Aspekt, auf den wir kurz eingehen wollen, bevor wir zum Workflow kommen: wie Plugins mit Staging interagieren.
Verwendung von Plugins in den Staging-Umgebungen von Kinsta
Kinsta verbietet bereits einige Plugins aus Sicherheits- und Leistungsgründen von der Installation in WordPress. Für die Staging-Umgebung solltest du jedoch auch einige Plugins deaktivieren.
Es gibt drei Situationen, in denen du dies in Betracht ziehen solltest:
- Wenn deine Plugin-Lizenz mit deinem Domainnamen verknüpft ist, kann es sein, dass sie in deiner Staging-Umgebung nicht funktioniert.
- Plugins wie Jetpack schalten automatisch in einen Staging-Modus um. Es kann sein, dass du keinen Unterschied bemerkst, obwohl keine der Daten, die du verarbeitest, an WordPress.com gehen. Außerdem kannst du Jetpack im Staging-Modus nicht deaktivieren.
- Einige Plugins verbinden sich mit sozialen Medien und posten dort, wie zum Beispiel CoSchedule. In diesen Fällen empfehlen wir dir, die Plugins zu deaktivieren, bis du sie live schaltest. Der Grund dafür ist, dass sie URLs aus deiner Staging-Umgebung anführen und posten können.
Weitere Informationen dazu (und zu vielem mehr) findest du in unserer Dokumentation. Sie ist eine wichtige Lektüre, wenn du die Staging-Umgebungen von Kinsta nutzen und gleichzeitig die Auswirkungen auf deine Plugins und Themes minimieren willst.
Ein typischer Entwicklungs-Workflow mit Kinstas Staging-Umgebungen
Wahrscheinlich hast du bereits einen typischen Arbeitsablauf für die Entwicklung. Mit den Staging-Umgebungen von Kinsta kannst du deinen DevOps-Lifecycle für Continuous Integration/Continuous Deployment (CI/CD) nahtlos integrieren.
Der Prozess beginnt nämlich mit einer lokalen Umgebung für die Entwicklung. Der Einrichtungsprozess nimmt keine Zeit in Anspruch und umfasst auch die Erstellung einer MariaDB-Datenbank.
DevKinsta ist auch ideal für Headless-WordPress-Projekte. Während WordPress hier einer Programmierschnittstelle (API) für Inhalte ähnelt, kannst du das Frontend mit einem JavaScript-Framework wie React oder Vue.js erstellen.
Wenn es an der Zeit ist, die Seite ins Staging zu stellen, kümmert sich DevKinsta wie gewohnt um das Backend. Das Frontend kannst du auf dem Statische-Seiten-Hosting von Kinsta oder auf unserem Anwendungs-Hosting bereitstellen.
So könnte der Rest eines typischen Workflows aussehen:
- Pushen in die Staging-Umgebung. Sobald du deine lokalen Entwicklungs- und Vorabtests abgeschlossen hast, solltest du einen Push zur Staging-Umgebung durchführen. Diese Produktionsreplik stellt sicher, dass deine Tests ähnliche Ergebnisse liefern wie deine Live-Site. Dies ist ein wichtiger Schritt in deiner CI/CD-Pipeline, da du vor der Bereitstellung automatisierte Tests und Qualitätssicherungsmaßnahmen durchführen kannst.
- Testen und Debuggen. Du wirst weitere Tests im Staging durchführen wollen, z. B. Leistungstests, Sicherheitsüberprüfungen und User Acceptance Testing (UAT). Da Kinsta die Staging- und die Live-Umgebung voneinander trennt, haben diese Tests keine Auswirkungen auf die Live-Site. Mithilfe der Protokollierungs- und Application Performance Monitoring (APM)-Tools von Kinsta kannst du hier auch alle Probleme beheben.
- Kontinuierliche Integration und Bereitstellung. Nach der Testphase und der endgültigen Freigabe musst du alle Änderungen aus dem Staging in die Live-Umgebung integrieren. Du kannst Teile dieses Prozesses entsprechend deinem CD/CI-Workflow automatisieren. So bleibt deine zentrale Versionskontrolle immer auf dem neuesten Stand, und du kannst den Code mit minimalem Aufwand in die Produktion einbringen.
- Überwachung und Rückmeldung. Nach der Bereitstellung ist es wichtig, Probleme zu erkennen und zu beheben, indem du eine kontinuierliche Feedback- und Überwachungsschleife einrichtest. Kinstas APM hilft dir, alle Herausforderungen nach der Bereitstellung zu bewältigen. Mit den gewonnenen Erkenntnissen und Daten kannst du dann kontinuierlich Verbesserungen vornehmen.
Insgesamt bieten die Staging-Umgebungen von Kinsta (und DevKinsta) eine robuste Infrastruktur, die dir hilft, deinen Entwicklungsworkflow zu optimieren. Sie unterstützen sogar Headless WordPress-Anwendungen. Im nächsten Abschnitt sehen wir uns an, wie du deine vorhandenen DevOps-Kenntnisse zusammen mit unseren Staging-Umgebungen nutzen kannst.
Anwendung von DevOps-Techniken bei der Nutzung der Staging-Umgebungen von Kinsta
Die Anwendung von DevOps-Techniken in den Staging-Umgebungen von Kinsta kann die Zusammenarbeit erheblich verbessern und den Entwicklungszyklus rationalisieren. Dies gilt insbesondere für funktionsübergreifende Teams, da das Staging die Produktion so genau wie möglich nachbildet.
So können Entwickler, Qualitätssicherungs-Teams (QA) und andere Personen während der Erstellungs-, Test- und Bereitstellungsphasen synchron zusammenarbeiten. Da dies in einer kontrollierten und isolierten Umgebung geschieht, können Konflikte minimiert werden. Außerdem kannst du so sicherstellen, dass du Probleme frühzeitig im Entwicklungsprozess erkennen und beheben kannst.
Im Kern geht es bei DevOps darum, die Barrieren zwischen den typischen und traditionellen „siloartigen“ Teams, der Entwicklung und dem Betrieb zu beseitigen. Die Praktiken, die du einführst, fördern eine kollaborative, automatisierte und integrative Kultur.
Darüber hinaus zielen die richtigen DevOps-Praktiken darauf ab, die Geschwindigkeit, Effizienz und Sicherheit deiner Entwicklung und Bereitstellung zu verbessern.
Du kannst dies in den verschiedenen Phasen des DevOps-Lebenszyklus in Aktion sehen. Es gibt etwa fünf bis sieben, je nach Projekt und Team:
- Entwicklung. In dieser Phase geht es um die Planung und Programmierung sowie um die Auswahl deiner Staging-Umgebung. Hier schreibst du den Code, testest ihn und kontrollierst ihn (wahrscheinlich mit Git), bevor du zur nächsten Phase übergehst.
- Integration. Hier führst du die Codeänderungen in einem zentralen Repository zusammen und stellst sicher, dass die neuen Elemente deine Website nicht beschädigen.
- Testen. Als Nächstes automatisierst du Tests, die in der Staging-Umgebung ausgeführt werden. Damit hast du eine zweite Ebene, die für fehlerfreien und qualitativ hochwertigen Code sorgt.
- Bereitstellen. Nachdem du deinen Staging-Code validiert hast, kannst du die Bereitstellung für die Produktion automatisieren. So wird sichergestellt, dass deine Website immer mit der neuesten Version läuft.
- Überwachung. Nach der Bereitstellung musst du die Leistung deiner Website überwachen. Hier sind ein robustes Warnsystem und ein Prozess von großem Nutzen. Die Daten, die du hier sammelst, werden dir auch in Zukunft bei der Umsetzung helfen.
- Feedback. In dieser Phase nach der Einführung sammelst du Erkenntnisse und Daten von den Nutzern – in diesem Fall von den Besuchern der Website. Das Feedback aus dieser Phase nutzt du, um Verbesserungsmöglichkeiten für den nächsten Entwicklungszyklus zu identifizieren.
- Betrieb. In dieser Phase wirst du wahrscheinlich einige Überschneidungen mit einem neuen Zyklus haben. Hier arbeitest du daran, Ausfälle zu minimieren, die Betriebszeit zu verbessern und die Serverkonfigurationen zu optimieren.
Je nach Anzahl der Schritte in deinem eigenen Lebenszyklus werden einige davon in einer anderen Reihenfolge ablaufen. Zum Beispiel kann die Integrationsphase Teil der Entwicklungs- oder Testphase sein. Außerdem kann es sein, dass du einige dieser Phasen nicht hast, wie z. B. eine spezielle Feedback- oder Betriebsphase.
Die Staging-Umgebungen von Kinsta sind ein wesentlicher Bestandteil der Entwicklungsphase, da sie einen sicheren, isolierten Bereich für die Codierung, das Testen und die Qualitätssicherung vor der Bereitstellung bieten. Die Integration dieser Umgebungen in den DevOps-Lebenszyklus kann die Zusammenarbeit fördern, die Lieferzeiten verkürzen und die Qualität der Ergebnisse verbessern.
Im Folgenden zeigen wir dir, wie du sie über das MyKinsta-Dashboard einrichtest.
Wie du eine Staging-Umgebung auf Kinsta einrichtest
Nicht alle Hoster bieten diese Funktion an, aber die Staging-Umgebungen von Kinsta sind in jedem unserer Tarife enthalten. Der gesamte Vorgang dauert nur ein paar Minuten und erfordert nur wenige Klicks.
Außerdem brauchen wir hier nicht jeden Schritt zu erklären, denn das kannst du in unserer Wissensdatenbank nachlesen. Kurz gesagt, kannst du die Einrichtung über dein MyKinsta-Dashboard beginnen:
Als erstes musst du dich für eine Standard- oder Premium-Staging-Umgebung entscheiden. Wir raten dir, dir darüber im Klaren zu sein, wie wichtig die Staging-Umgebung für deine Live-Site sein wird. Eine Standardumgebung eignet sich zum Beispiel, wenn du nur Elemente außerhalb der Produktion testen willst.
Eine Premium-Umgebung ist dagegen notwendig, wenn du den gleichen Umfang an Ressourcen wie für deine Live-Site benötigst. Es gibt noch weitere Vorteile, wie zum Beispiel die Möglichkeit, mehrere Staging-Umgebungen einzurichten. Für ressourcenintensive Websites (wie z. B. E-Commerce-Shops) musst du jedoch die gleichen Ressourcen wie für deine Live-Site verwenden.
In den meisten Fällen wirst du deine bestehende Website klonen wollen. Das ist eine der Optionen, die du hast, nachdem du dich für eine Staging-Umgebung entschieden hast.
Wenn du von DevKinsta kommst, kannst du hier eine leere Umgebung einrichten. In den Einstellungen deiner Website in DevKinsta gibt es eine Schaltfläche, mit der du die Staging-Umgebung einrichten kannst. Trotzdem solltest du ein paar Minuten warten, bis die Einrichtung deiner Umgebung abgeschlossen ist. Danach kannst du deine Kinsta-Staging-Umgebung nutzen, um deine Website zu erstellen und zu testen.
Die Kinsta-Staging-Umgebung mit einer richtigen Subdomain-Adresse versehen
In der Regel befindet sich deine Kinsta-Staging-Umgebung in einem Unterordner auf deinem Server. Sie hat eine URL, die eine Subdomain von kinsta.cloud ist, aber das kann zu einigen Problemen führen:
- Einige Plugins werden nicht funktionieren, z. B. solche, die eine Lizenz über einen bestimmten Domainnamen verifizieren müssen.
- Bestimmte Konfigurationen von WordPress Multisite haben Probleme mit Unterverzeichnissen auf Kinsta oder benötigen eine eigene Subdomain, um optimal zu funktionieren.
Daher ist es eine gute Idee, eine eigene Subdomain-Adresse für deine Kinsta-Staging-Umgebungen einzurichten. Für Premium-Benutzer stellt Kinsta dedizierte Subdomain-Adressen zur Verfügung, aber auch damit lassen sich deine Probleme möglicherweise nicht lösen.
Die Lösung ist, eine eigene Domain für deine Website einzurichten und dann das Staging über eine Subdomain mit Hilfe des Domain Name System (DNS) durchzuführen. Eine benutzerdefinierte Staging-URL mit einer eigenen Domain und Subdomain hat zwei Vorteile: Erstens kannst du die Probleme, über die wir sprechen, entschärfen. Zweitens hast du eine „schönere“ Subdomain, die du mit Mitarbeitern oder Kunden teilen kannst.
Eine Live-Site in die Staging-Umgebung verschieben
Ein Aspekt deiner Staging-Umgebung, der dir anfangs vielleicht nicht klar ist, ist die Frage, wie du deine Live-Site nach der Einrichtung in die Staging-Umgebung verschieben kannst. Wenn du erst einmal verstanden hast, dass eine Staging-Umgebung einfach eine Kopie deiner Live-Site ist, ist es einfacher, sich das vorzustellen.
Um jedoch alle Zweifel auszuräumen, hier ein kurzer Überblick über den Arbeitsablauf:
- Wenn du eine Staging-Umgebung erstellst, kopierst du deine Live-Site in eine Subdomain. Das schließt alle deine Datenbanken und Dateien ein. Es ist eine vollständige Eins-zu-Eins-Kopie deiner Live-Site.
- Du nimmst Änderungen an der Staging-Umgebung entsprechend deinem DevOps-Lebenszyklus vor. Das ist subjektiv und bezieht sich auf dein eigenes Projekt, deinen Workflow und deine Ziele.
- Wenn es darum geht, diese Änderungen live zu schalten, hast du mehrere Möglichkeiten. Du kannst die integrierte Push-to-Live-Funktion von Kinsta nutzen oder die Änderungen manuell vornehmen. Darauf werden wir später noch genauer eingehen.
- Ab hier hast du wieder eine Eins-zu-Eins-Kopie deiner Website für die Staging- und die Live-Umgebung.
Es gibt also keine Möglichkeit, deine Staging-Umgebung anhand des Status deiner Live-Site zu aktualisieren. Wir empfehlen dir, deine Staging-Umgebung zu löschen und bei Bedarf neu zu erstellen, um deine aktuelle Website zu kopieren. Dies ist ein weiterer guter Grund für die Verwendung einer eigenen Subdomain-Adresse für deine Kinsta-Staging-Umgebungen.
Kinsta erstellt Backups sowohl für deine Live-Site als auch für die Staging-Umgebung. Das bedeutet, dass du auch ein Backup der Live-Site direkt in der Staging-Umgebung wiederherstellen kannst. Auf diese Weise kannst du einfacher zwischen deinen Lifecycle-Phasen wechseln und frühere Versionen deiner Website während der Entwicklung verwenden.
Beachte, dass du zuerst deine Staging-Umgebung einrichten musst, aber du kannst entweder die Standard- oder die Premium-Umgebung wiederherstellen. In jedem Fall kannst du dies über das MyKinsta-Dashboard tun:
Die Wiederherstellung ist nur ein paar Klicks entfernt, und die bestehenden Backups deiner Live- und Staging-Websites sowie alle benutzerdefinierten Domains, die du eingerichtet hast, werden beibehalten.
Versionskontrolle in dein Staging-Setup einbinden
Viele Entwickler/innen verwenden eine Versionskontrolle wie Git, die wir empfehlen. Sowohl die Live- als auch die Staging-Umgebungen auf Kinsta bieten eine Integration mit Git, so dass du deine Staging-Site versionskontrollieren kannst, um den Überblick über deinen Entwicklungsplan zu behalten.
Das Ziehen und Klonen eines Repo auf den Kinsta-Server sollte ein Kinderspiel sein. Der Prozess besteht aus ein paar einfachen Schritten:
- Verbinde dich mit deiner Website über Secure Shell (SSH).
- Ziehe dein aktuelles Projektarchiv von GitHub, GitLab oder einem anderen ähnlichen Dienst.
- Alternativ kannst du dein Repo auch von deinem Standort aus klonen.
Die Art und Weise, wie du dein Remote-Repository abrufst, hängt davon ab, ob es öffentlich, privat oder mit Zwei-Faktor-Authentifizierung (2FA) ausgestattet ist. Für das Pushen deines Codes in das entfernte Projektarchiv musst du jedoch einen geeigneten Workflow finden.
Denn die Staging-Umgebungen von Kinsta und die Git-Integration unterstützen noch keinen Befehl wie git push kinsta mysite. Dennoch gibt es Umgehungsmöglichkeiten. Du könntest zum Beispiel ein Tool wie WP Pusher verwenden:
Clevere Entwickler finden auch einzigartige Wege, um von Kinsta aus zu GitHub zu pushen, und sei es, dass sie einen einfachen Befehl aus einem Git-Client ausführen oder den Prozess mit Skripten automatisieren. Wir werden später mehr über das allgemeine Konzept des Pushens deines Codes auf die Live-Site berichten.
Durchführung von Leistungstests in den Staging-Umgebungen von Kinsta
Zu den Test- und Überwachungsphasen im Lebenszyklus gehört es auch, die Leistung deiner Staging-Site zu prüfen (und mit Benchmarks zu vergleichen). Die gute Nachricht ist, dass du sowohl für deine Staging-Site als auch für die Live-Site Zugriff auf alle Tools von Kinsta hast.
Kurz gesagt: Du holst dir Benchmarks für deine Live-Site, legst Ziele fest, die du erreichen möchtest, und optimierst deinen Code in der Staging-Site. Anschließend bewertest du, ob diese Änderungen einen positiven Einfluss haben. Wenn ja, kannst du die Dinge vorantreiben. Wenn nicht, wiederholst du die Programmier- und Testschritte.
Für die Staging-Umgebungen von Kinsta wird das Kinsta APM-Tool wahrscheinlich eine zentrale Referenz sein:
Dabei handelt es sich um ein benutzerdefiniertes Tool, das sich auf WordPress-Probleme konzentriert und alle gesammelten Aktivitäten mit einem Zeitstempel versieht. Du kannst PHP-Prozesse, deine HTTP-Aufrufe, Datenbankabfragen und vieles mehr überwachen. Wir haben zum Beispiel festgestellt, dass die meisten Leistungseinbußen auf ein nicht optimales Plugin oder Theme zurückzuführen sind. Kinsta APM kann dir das auf der Registerkarte WordPress im Detail zeigen.
Du wirst sehen, dass es möglich ist, einzelne Transaktionen detailliert zu untersuchen, so dass du genau sehen kannst, wo deine Engpässe liegen. Bei Staging-Sites wirst du die Redis-Transaktionszeit nicht oft überwachen. Stattdessen werden deine PHP- und MySQL-Zeiten von größerem Interesse sein.
Die Verwendung eines absoluten Zeitrahmens bei der Fehlersuche hilft dabei, die Problembereiche zu identifizieren. Die Kinsta-Dokumentation führt dich durch den allgemeinen Arbeitsablauf, aber kurz gesagt: Langsam ladende Seiten sollten deine erste Sorge sein.
Danach kannst du dich mit den Prozessen befassen, die zu diesen Transaktionen führen, und entweder suboptimalen Code oder schlechte Tools von Drittanbietern ausfindig machen. Du wirst wahrscheinlich eine Mischung aus verschiedenen Tools verwenden, um problematischen Code zu finden und zu bekämpfen. Für die WordPress-Entwicklung sind WP_DEBUG und Query Monitor typisch.
Kontinuierliche Bereitstellung: Synchronisierung von Änderungen zwischen Staging und Produktion
In der Bereitstellungs-Phase deines Lifecycles musst du eine Entscheidung treffen: welchen Code du pushen willst. Dein erster Gedanke ist vielleicht, alles auf einmal zu pushen, aber das ist nicht immer die beste Idee.
Denn egal wie ähnlich deine Staging- und Live-Umgebungen sind, es gibt immer noch Unterschiede zwischen ihnen. Ein schrittweises Vorgehen kann sinnvoller sein, da du eine Reihe von Code für eine bestimmte Verbesserung pushen, die Änderungen überwachen und dann den nächsten Push planen kannst.
Dieses Konzept ist für die kontinuierliche Bereitstellung von zentraler Bedeutung, denn die sichere Bereitstellung sollte ein Hauptanliegen sein. In der Vergangenheit hat die Push-to-Live-Funktion von Kinsta mit einem Klick deine gesamte Website auf den Live-Server geschickt, unabhängig von deinen Änderungen. Jetzt kannst du aber auch selektiv pushen: Entweder deine Dateien, deine Datenbank oder beides auf den Live-Server:
Das schließt allerdings auch deine Umgebungseinstellungen ein, z. B. deine Nginx-, PHP- und Redirect-Konfigurationen. Das kann immer noch zu viel sein, vor allem, wenn du nur kleine oder geringfügige Änderungen an einem bestimmten Teil deiner Website vornimmst.
Du hast natürlich auch die Möglichkeit, auf die Push-to-Live-Optionen von Kinsta zu verzichten und die Arbeit selbst zu erledigen. Am sichersten ist es, wenn du deine Änderungen auf die Live-Site überträgst, anstatt sie zu automatisieren. Das dauert zwar länger, aber du hast die Möglichkeit, jede Änderung zu überwachen, während sie live geht.
Unabhängig von deiner Herangehensweise an die kontinuierliche Bereitstellung sind deine Backups jedoch ein wichtiger Bestandteil. Kinsta erstellt jeden Tag Backups für jede Website in deinem Account. Dazu gehören sowohl die Backups, die das System erstellt, als auch deine manuellen Backups.
Darüber hinaus ist jedes Backup ein vollständiger Schnappschuss einer bestimmten Umgebung. Das bedeutet, dass du innerhalb von Minuten zu einer bekannten, funktionierenden Konfiguration zurückkehren kannst, wenn du eine defekte Website reparieren musst.
Zusammenfassung
Mit den Staging-Umgebungen von Kinsta kannst du deine Website erstellen, testen und in die Produktion überführen, unabhängig davon, wie viele Phasen du durchführst und wie die einzelnen Schritte deines Workflows aussehen. Sie sind flexibel, denn du kannst die kostenlose Standard-Staging-Umgebung für jede Website nutzen, die du mit Kinsta betreibst.
Mit einer Premium-Staging-Umgebung kannst du jedoch mehrere Instanzen einrichten, Ressourcen für deine Live-Site verwenden und vieles mehr. Die Staging-Umgebungen von Kinsta eignen sich auch hervorragend, wenn du sie zusammen mit unserem Anwendungs-Hosting nutzt. In jedem Fall kannst du deine Website von der lokalen Umgebung in die Live-Umgebung überführen und hast direkt über das MyKinsta-Dashboard Zugriff auf alle typischen Kinsta-Tools.
Hast du Fragen dazu, wie du die Staging-Umgebungen von Kinsta neben deinen normalen DevOps-Techniken nutzen kannst? Schreib uns deine Meinung in den Kommentaren unten!
Schreibe einen Kommentar