
TL;DR
|
Anwendungsmigrationen stocken aus einem vorhersehbaren Grund: Der anspruchsvolle Teil ist selten der Anwendungscode selbst. Es ist die Infrastruktur drumherum: die Deployment-Logik, die Pipeline und die Umgebungskonfiguration, die neu aufgebaut werden müssen.
Genau diese begleitenden Arbeiten machen eine Migration zu einem monatelangen Projekt, und genau deshalb bleiben Teams bei einer Infrastruktur, die ihren Anforderungen nicht mehr gerecht wird.
Upsun Cloud reduziert die Migration auf eine viel kleinere Aufgabe. Du beschreibst deine Laufzeiten, Dienste und Routen einmalig in einer Konfigurationsdatei, die sich in deinem Repository befindet, verschiebst deine Daten und testest das Ergebnis auf einem Branch. Der Anwendungscode bleibt unverändert.
Das Wichtigste auf einen Blick: Bei der Migration geht es darum, deinen bestehenden Stack in einer Konfigurationsdatei zu beschreiben, nicht darum, ihn neu aufzubauen. Dein Anwendungscode und deine CI-Tools bleiben unverändert erhalten.
Bei der Migration wird deine bestehende Konfiguration beschrieben, anstatt sie neu aufzubauen; der Großteil dessen, was du bereits hast, bleibt unverändert:
Was du hinzufügst, ist eine einzige Datei, „.upsun/config.yaml“, die wie jeder andere Code in dein Repository committet wird. Sie wird nicht in ein separates Dashboard oder eine herstellerspezifische Konsole eingegeben. Die Datei legt drei Dinge fest:
Das Erstellen dieser Datei hat mehr mit Dokumentation als mit Infrastruktur-Engineering zu tun. Du beschreibst, was deine App benötigt, anstatt Server manuell bereitzustellen.
Das Wichtigste auf einen Blick: Jeder Schritt läuft auf einem isolierten Branch ab, sodass du die gesamte Migration anhand echter Daten validieren kannst, bevor die Produktion überhaupt betroffen ist.
Nachdem du dein Projekt und dein Git-Repo auf der Upsun Cloud eingerichtet hast, erfolgt die Migration in kleinen Schritten, die jeweils ohne Wartungsfenster ausgeführt werden können. Die Produktion bleibt unberührt, bis du dich für ein Merge entscheidest.
1. Füge die Konfigurationsdatei neben deiner bestehenden App in deinem Repo hinzu. Dieser Schritt allein führt zu keiner Bereitstellung. Du beschreibst deinen Stack, ohne dich bisher auf etwas festzulegen.
2. Führe einen Push für einen Zweig durch. Durch den Push wird eine isolierte Umgebung erstellt, die an diesen Zweig gebunden ist. Die Produktion bleibt unberührt. Du testest in einer echten, laufenden Umgebung und nicht in einer lokalen Annäherung daran.
3. Füge deine Umgebungsvariablen hinzu. Nutze die Konsole oder die CLI, um alle Variablen hinzuzufügen, die zum Ausführen deiner Anwendung benötigt werden.
4. Synchronisiere Daten in die Zweigumgebung. Führe „upsun environment:synchronize code data“ aus, um eine Kopie der Daten der übergeordneten Umgebung in den Zweig zu ziehen. Wenn der Zweig aus der Produktivumgebung erstellt wird, bedeutet das, dass du mit echten Produktionsdaten testest und nicht mit Testdaten, die möglicherweise nicht die tatsächlichen Bedingungen widerspiegeln.
5. Iteriere an der Konfiguration, nicht am Programmieren. Wenn etwas falsch konfiguriert ist, erfolgt die Korrektur in der YAML-Datei auf diesem Zweig. Deine Anwendungslogik wird nicht Teil des Debugging-Zyklus.
6. Führe den Merge erst durch, wenn der Zweig sich bewährt hat. Die Umstellung erfolgt zuletzt, nachdem sich die Umgebung bereits als funktionsfähig erwiesen hat. Zu keinem Zeitpunkt in diesem Prozess testest du zum ersten Mal in der Produktivumgebung.
Jeder Schritt ist reversibel. Wenn in Schritt 4 ein Problem auftaucht, behebst du es und wiederholst den Schritt. Nichts, was danach kommt, hängt davon ab, dass ein früherer Schritt beim ersten Versuch richtig klappt.
Das Wichtigste auf einen Blick: Die Tools und Gewohnheiten, auf die du dich bereits verlässt – Git, die CLI, deine Programmiersprache und deine Dienste – lassen sich auf Upsun übertragen, anstatt ersetzt zu werden.
Das Wichtigste auf einen Blick: Die Änderungen betreffen die Art und Weise, wie die Infrastruktur definiert und gesichert wird – sie wird in der Konfiguration festgelegt, statt manuell eingerichtet.
Dein Workflow und dein Stack bleiben erhalten, aber einige Dinge funktionieren anders, sobald du auf der Upsun Cloud bist. Hier sind die wesentlichen Unterschiede.
Eine Migration erscheint riskant, weil die Validierung meist am falschen Ort stattfindet. Bei einer einmaligen Umstellung erfolgt der erste echte Test, ob alles funktioniert hat, erst nach dem Wechsel, wenn die Anwendung bereits live ist und Nutzer bedient. Dieser Ansatz verlegt den Test auf einen früheren Zeitpunkt.
Du fügst eine Konfigurationsdatei zu deinem Repository hinzu, pushst einen Branch und beobachtest, wie deine Anwendung auf der Upsun Cloud mit einer Kopie deiner echten Produktionsdaten läuft. Währenddessen ändert sich an deiner Live-Seite nichts. Wenn der Branch funktioniert, hast du deinen Beweis und machst weiter. Wenn nicht, korrigierst du die Konfiguration und pushst erneut – oder du gehst, nachdem du einen Nachmittag statt eines ganzen Quartals damit verbracht hast.
Das ist der Unterschied, den ein schrittweiser Ansatz ausmacht. Du legst dich nicht auf eine Migration fest, bevor du weißt, ob sie funktioniert. Du testest eine Migration, beobachtest das Ergebnis und triffst deine Entscheidung auf der Grundlage von Fakten statt auf der Grundlage von Hoffnungen. Die Kosten dafür betragen nur einen Branch.
Muss ich mein Programmieren für die Migration umschreiben?
Nein. Die Migration zu Upsun Cloud erfordert keine Änderungen an deiner Anwendungslogik. Das einzige neue Artefakt ist eine Konfigurationsdatei, die deine Laufzeitumgebung und Dienste deklariert. Dein Code wird unverändert übernommen.
Beeinflusst das Testen einer Migration meine Live-Produktionsumgebung?
Nein. Das Testen der Migration erfolgt auf einem Branch in einer eigenen, isolierten Umgebung. Die Produktion bleibt unberührt, bis du dich für ein Merge entscheidest – und zu diesem Zeitpunkt wurde die Umgebung bereits anhand einer Kopie der Produktionsdaten getestet.
Wie werden Umgebungsvariablen und Geheimnisse bei der Migration zu Upsun Cloud behandelt?
Sensible Anmeldedaten werden über die CLI oder die Konsole als Variablen auf Projekt- oder Umgebungs-Ebene festgelegt, anstatt manuell zwischen den Umgebungen kopiert zu werden. Eine gemeinsam genutzte .env-Datei muss nicht unverändert migriert werden. Jede Variable wird auf der Ebene festgelegt, auf der sie gelten soll, sodass ihr Geltungsbereich von Anfang an korrekt ist.
Was passiert mit meiner bestehenden CI/CD-Pipeline? Der Build- und Deployment-Prozess von
Upsun Cloud wird durch einen Git-Push ausgelöst und übernimmt die Bereitstellung automatisch. Ein separates CI-Tool für Linting, Tests oder Code-Review-Prüfungen kann parallel dazu weiterlaufen, sodass du deine bestehende Pipeline nicht entfernen musst, um eine Migration zu testen.
Welche Frameworks und Sprachen unterstützt Upsun?
Upsun Cloud unterstützt eine breite Palette an Sprachen und Frameworks, darunter Next.js, Django, Symfony, Laravel, Go und ruby sowie CMS-Plattformen wie WordPress und Drupal.