Deployment: Der aktive Akt, ein Artefakt in einer Umgebung zu platzieren

Sie haben Ihre Anwendung gebaut, in ein Artefakt verpackt und in einem Repository abgelegt. Und jetzt? Das Artefakt, das im Repository liegt, ist nur eine Datei. Es wird erst nützlich, wenn es in einer Umgebung platziert wird und tatsächlich läuft. Diesen Akt des Platzierens und Ausführens nennen Ingenieure Deployment.

Deployment ist kein passiver Zustand. Es ist eine aktive Handlung. Vor dem Deployment läuft in Ihrer Staging-Umgebung Version 1.1.0. Nach dem Deployment läuft Version 1.2.0. In dieser Umgebung hat sich etwas geändert. Jemand oder etwas hat das Artefakt genommen, auf den richtigen Server verschoben und gestartet.

Was während eines Deployments tatsächlich passiert

Wenn ein Team beschließt, Version 1.2.0 auf Staging zu bringen, muss eine Reihe konkreter Schritte erfolgen. Jemand zieht das Artefakt aus dem Repository. Er überträgt es auf den Staging-Server. Er stoppt den alten Prozess, startet den neuen und überprüft, ob er läuft. Die Umgebung hat nun einen neuen Zustand.

Hier ist ein konkretes Beispiel, wie diese Schritte als Shell-Befehle aussehen:

scp myapp-v1.2.0.jar user@staging-server:/opt/myapp/ && \
ssh user@staging-server "systemctl stop myapp && \
  cp /opt/myapp/myapp-v1.2.0.jar /opt/myapp/current.jar && \
  systemctl start myapp"

Deshalb unterscheidet sich Deployment vom bloßen Speichern von Dateien. Sie können ein perfektes Artefakt-Repository mit jeder jemals gebauten Version haben, aber bis diese Artefakte in Umgebungen platziert und ausgeführt werden, wurde nichts ausgeliefert. Deployment ist die Brücke zwischen "wir haben es gebaut" und "es läuft irgendwo".

Das folgende Sequenzdiagramm veranschaulicht die Trennung von Deployment und Release:

sequenceDiagram participant AR as Artifact Registry participant DT as Deployment Tool participant S as Server participant LB as Load Balancer DT->>AR: Pull artifact v1.2.0 DT->>S: Transfer artifact DT->>S: Stop old process (v1.1.0) DT->>S: Start new process (v1.2.0) DT->>S: Verify health S-->>DT: Healthy Note over DT,LB: Deployment complete DT->>LB: Switch traffic to v1.2.0 Note over DT,LB: Release happens

Die Frage, die sich daraus ergibt, ist: Bedeutet Deployment, dass Benutzer die neue Version sofort nutzen können? Nicht unbedingt. Deployment und Release sind zwei verschiedene Konzepte, auch wenn Teams sie oft zusammen durchführen.

Deployment versus Release

Deployment ist eine technische Aktion. Sie platzieren ein Artefakt in einer Umgebung und führen es aus. Release dreht sich um Zugriff. Es beantwortet die Frage: Wann beginnen Benutzer tatsächlich, die neue Version zu nutzen?

Stellen Sie sich vor, Ihr Team deployed Version 1.2.0 um 2:00 Uhr morgens in die Produktion. Die Produktionsserver laufen jetzt mit der neuen Version, aber das Team leitet den Benutzerverkehr bewusst noch nicht dorthin. Deployment hat stattgefunden. Release nicht. Die Benutzer sind noch auf der alten Version. Das Team kann überprüfen, ob die neue Version fehlerfrei läuft, bevor es die Tür öffnet.

Stellen Sie sich nun das gegenteilige Szenario vor. Das Team deployed in die Produktion und leitet sofort alle Benutzer auf die neue Version. In diesem Fall fallen Deployment und Release in einem Schritt zusammen. Beide Ansätze sind gültig, aber das Verständnis des Unterschieds gibt Ihnen Optionen.

Warum ist diese Trennung wichtig? Weil ein Deployment fehlschlagen kann. Wenn das passiert, müssen Sie wissen, wie Sie die Umgebung in ihren vorherigen Zustand zurückversetzen. Diese Aktion heißt Rollback. Ein Rollback ist im Wesentlichen ein Deployment der alten Version in dieselbe Umgebung. Wenn Ihr Team nur weiß, wie man "die neue Version pusht", ohne zu verstehen, dass Deployment eine umkehrbare Aktion ist, werden Sie Probleme bekommen, wenn etwas schiefgeht.

Deployment ist nicht immer reibungslos

Selbst bei sorgfältiger Planung können bei Deployments Probleme auftreten. Dem Server könnte der Speicherplatz ausgehen. Eine Konfigurationsdatei könnte einen Tippfehler enthalten. Das aus dem Repository heruntergeladene Artefakt könnte beschädigt sein. Netzwerkprobleme könnten während der Übertragung zu einem Timeout führen.

Deshalb benötigt jedes Deployment eine Verifikation. Nachdem das Artefakt platziert ist und läuft, muss jemand oder etwas überprüfen, ob die Umgebung tatsächlich gesund ist. Reagiert die Anwendung auf Anfragen? Sind die Logs sauber? Liegen die erwarteten Metriken im normalen Bereich?

Die Verifikation kann automatisiert oder manuell erfolgen, aber sie muss existieren. Ein Deployment, das ohne Verifikation abgeschlossen wird, ist nur die Hoffnung, dass nichts schiefgelaufen ist. Hoffnung ist keine Deployment-Strategie.

Die praktischen Implikationen

Sobald Sie Deployment als aktive Aktion und nicht als passiven Zustand betrachten, werden mehrere Dinge klarer.

Erstens ist Deployment wiederholbar. Wenn Sie heute Version 1.2.0 deployen können, sollten Sie morgen Version 1.2.0 erneut in dieselbe Umgebung deployen können, mit demselben Ergebnis. Wenn das nicht der Fall ist, hat Ihr Deployment-Prozess versteckte Schritte oder Abhängigkeiten.

Zweitens ist Deployment umkehrbar. Wenn Version 1.2.0 Probleme verursacht, sollten Sie Version 1.1.0 zurück in dieselbe Umgebung deployen können. Das ist Rollback. Wenn ein Rollback schmerzhaft oder riskant ist, muss Ihr Deployment-Prozess verbessert werden.

Drittens ist Deployment überprüfbar. Sie sollten innerhalb einer angemessenen Zeit wissen, ob das Deployment erfolgreich war oder fehlgeschlagen ist. Nicht nur, ob das Skript fehlerfrei durchgelaufen ist, sondern ob die Anwendung in dieser Umgebung tatsächlich korrekt funktioniert.

Eine einfache Deployment-Checkliste

Bevor Sie ein Deployment als abgeschlossen betrachten, gehen Sie diese Prüfungen durch:

  • Wurde das Artefakt in der korrekten Umgebung platziert?
  • Läuft die neue Version tatsächlich und nimmt Traffic an?
  • Bestehen die grundlegenden Health Checks (Antwortcodes, Latenz, Fehlerraten)?
  • Können Sie bestätigen, dass die alte Version nicht mehr läuft (es sei denn, Sie führen ein schrittweises Rollout durch)?
  • Wissen Sie, wie Sie bei Bedarf ein Rollback durchführen, und ist dieser Rollback-Pfad getestet?

Diese Checkliste ist nicht vollständig, deckt aber das Minimum ab. Jedes Team sollte sie basierend auf seiner eigenen Umgebung und den Anwendungseigenschaften erweitern.

Das Fazit

Deployment ist der Moment, in dem Ihr Artefakt aufhört, eine Datei zu sein, und beginnt, ein laufender Dienst zu sein. Es ist eine aktive, wiederholbare, umkehrbare und überprüfbare Aktion. Die Trennung von Deployment und Release gibt Ihnen die Kontrolle darüber, wann Benutzer Änderungen sehen. Die Verifikation jedes Deployments bewahrt Sie davor, Probleme erst zu entdecken, nachdem Ihre Benutzer sie gefunden haben.

Wenn Ihr Team das nächste Mal sagt "wir haben deployed", fragen Sie: Haben wir das Artefakt tatsächlich platziert und überprüft, dass es läuft? Oder haben wir nur einen Knopf gedrückt und gehofft? Die Antwort wird Ihnen sagen, wie ausgereift Ihr Deployment-Prozess wirklich ist.