Boehrsi.de - Blog

Letzten Sonntag erfolgte der erste Live-Test meines neuen Service-Setups und ich konnte den neuen Such-Service direkt online lassen. Als Backup verweilt das alte Setup weiterhin auf dem Server, aber bis dato läuft alles recht problemlos. Ich bin mit dem Ablauf des Deployments trotz eher minimalistischer Planung sehr zufrieden und aus diesem Grund möchte ich meinen Ablaufplan gerne mit euch teilen. Vielleicht hat der eine oder andere ähnliche Deployments geplant und findet hier die eine oder andere interessante Anregung.

Für die Umsetzung bin ich wie folgt vorgegangen:

1. Fertige Implementierung

Hierbei geht es nicht nur um die eigentlichen Features, auch der Bereich Security, Health- / Management-Endpoints, Statistiken, Spam Handling, Error Handling und das gerne vergessene Handling von CORS Requests open_in_new sollte abgeschlossen sein. Übrigens auch die Anpassungen am jeweiligen Frontend sollten nicht vergessen werden.

2. Bauen der Applikation

Es ist das eine ein Programm im Debugmodus aus der IDE zu starten, aber teilweise etwas ganz anderes es zu bauen und als lauffähige eigenständige Anwendung auszuliefern. Dabei sollte auch auf externe Dinge wie die Konfigurierbarkeit geachtet werden. Ob man hier auf eine Config Datei, Umgebungsvariablen oder Startparameter setzt ist meiner Meinung nach Geschmackssache.

3. Backend entkoppelt vom Frontend

Auch wenn dieser Punkt offensichtlich ist, schließlich geht es darum einen losgelösten eigenständigen Service auszuliefern, will ich ihn hier noch einmal erwähnen. Der neue Service sollte initial ohne die finale Umstellung des Frontends testbar sein. Hier kann CURL open_in_new oder ein GUI Tool wie Postman open_in_new sehr hilfreich sein. Auf diesem Weg kann man mittels direkter Requests die Endpoints testen.

4. Deployment

Der Upload und das Setup des Services sollte ohne Beeinträchtigung der anderen Serverkomponenten durchführbar sein. Hierbei wird die neue Anwendung hochgeladen, die Config falls nötig angepasst und z.B. Ordner erstellt. Am Ende sollte das neue Stück Software vor Ort bereit liegen und mit wenigen Schritten ausführbar sein. Ich füge meine Services gerne noch als System-Service hinzu und packe sie in den Autostart. Auf diesem Weg kann ich sie einfach als Daemon starten, ohne umfangreiches weiteres Tooling oder Scripting.

5. Ausführung und ein erster Test

Der Service sollte parallel zum bereits laufenden ausführbar sein, ich setze hier gerne auf unterschiedliche Ports. Auf diesem Wege kann man sowohl die Produktivumgebung, wie auch die Testumgebung auf einem System betreiben. Nun können eventuelle Requests via Postman o.ä. an den neuen Service gesendet werden und entsprechend kann die Funktionalität der Live-Version verifiziert werden.

6. Backend Umstellung

Sofern es keine Probleme beim Testen gab kann nun die Umstellung erfolgen. Hierbei ändere ich lediglich den Port im Reverse-Proxy der Domain die auf den Service zeigt. Denn wir wollen ja nicht auf eine Domain mit angehängtem Port zugreifen, sondern auf so etwas wie search.boehrsi.de. Dafür muss in den jeweiligen Web-Server Configs lediglich der bis dato hinterlegt Port geändert werden. Anders als bei DNS Änderungen ist übrigens keine Wartezeit nötig, bis der neue Service angesprochen werden kann.

7. Frontend Umstellung

Je nach Art und Weise des Upgrades hat sich vielleicht auch etwas am Frontend geändert und muss nun ausgeliefert werden. Hierfür sollte direkt nach der Durchführung von Phase 6. oder vielleicht sogar parallel die Anpassung des Frontends / der Clients erfolgen. Denn in diesem Bereich hat man sonst im gesamten Ablauf den ersten Zeitpunkt zu welchem Fehler auftreten können oder der Service nicht für den Nutzer verfügbar ist.

8. Verifizierung und Aufräumen

Nachdem alles umgestellt ist, sollte getestet werden ob alles online und funktional ist. Hierbei eventuelles Monitoring nicht vergessen, denn auch selbiges kann durch umfangreiche Umstellung ausfallen. Ist also das Backend, das Frontend und das Monitoring glücklich, können alte Services angeschaltet werden. Ich bevorzuge ein Backup selbiger zu erstellen und es für den Notfall bereitzulegen, danach entferne ich die alten Dateien vom Server. Alternativ kann man den neuen und alten Service auch eine gewisse Zeit parallel laufen lassen, sofern es die Ressourcen des Servers zulassen.

Dieser Ablaufplan funktionierte bei mir sehr gut und führte zu sehr geringen Ausfallzeiten. Selbige traten bei mir durch kleine Probleme beim CORS Handling auf, welche ich leider erst nach dem realen Deployment ordentlich testen konnte. Ansonsten lief alles nahezu perfekt open_in_new, denn lediglich ca. 5 Minuten war der Service gar nicht verfügbar und ca. 25 Minuten lang war das Monitoring falsch konfiguriert. Letzteres hatte allerdings keine Auswirkungen für die Nutzer. Derzeit überlege ich diesen kleinen Ablaufplan in eine Art Checkliste oder ein kleines Tool zu überführen, sodass ich keine Schritte vertausche und vielleicht sogar direkt Lessons Learned hinterlegen kann.