Deployen, Hochladen, Anwenden — Bedeutung der Begriffe und Unterschiede

Was bedeutet „Deployen“, „Hochladen“, „Anwenden“

„Deployen“ ist der allgemeinste Begriff und bedeutet die Veröffentlichung einer neuen Version eines Softwareprodukts, Features oder einer Änderung. „Wir haben ein Update deployed“, „wir haben einen Fix deployed“, „wir haben einen Release deployed“ — in allen Fällen wird die Änderung für die Benutzer verfügbar. Der Begriff impliziert eine ziemlich große Aktion: normalerweise deployed man eine komplette Version, nicht eine einzelne Datei.

„Hochladen“ ist ein spezifischerer Begriff und bedeutet das Laden von Dateien, Daten oder Artefakten auf einen Server oder in einen Speicher. „Build auf den Server hochladen“, „Skripte in die DB hochladen“, „Assets in das CDN hochladen“. Im Gegensatz zu „Deployen“ impliziert der Begriff nicht, dass das Hochgeladene für die Benutzer verfügbar geworden ist — die Dateien können auf dem Server liegen, aber noch nicht mit der Anwendung verbunden sein. Nuance: „Hochladen“ wird auch für das Senden von Code an ein Repository verwendet („auf GitHub hochgeladen“).

„Anwenden“ ist ein Begriff, der das Anwenden einer Änderung auf eine vorhandene Version bedeutet. „Eine Migration anwenden“, „Einen Patch anwenden“, „Eine Konfiguration anwenden“. Der Hauptunterschied ist, dass die Änderung darüber gelegt wird ohne vollständigen Ersatz. Wenn „Deployen“ bedeutet, eine neue Version anstelle der alten zu starten, dann bedeutet „Anwenden“, eine Änderung zu dem hinzuzufügen, was bereits funktioniert. Der Begriff ist im Kontext von Datenbanken (Migrationen) und Patch-Releases verbreitet.

Zusätzliche Begriffe aus demselben semantischen Feld: „Ausrollen“ (eine Änderung auf alle Server im Cluster verteilen), „Zurücksetzen“ (zur vorherigen Version zurückkehren), „Verschütten“ (versehentlich die falsche Version deployen). All diese Verben beschreiben Aktionen mit Code als wäre er ein physisches Objekt, das man „rollen“, „gießen“ und „zurückrollen“ kann.

Ursprung der umgangssprachlichen Begriffe

Der Begriff „Deployen“ stammt aus einer Automobilmetapher: „Ein Auto aus der Garage fahren“. Wenn der Code für die Veröffentlichung bereit ist, wird er „deployed“ — hinausgelassen, für die Benutzer verfügbar gemacht. Die Metapher verbreitete sich Anfang der 2000er Jahre mit dem Aufkommen von Continuous-Delivery-Praktiken, als Releases regelmäßig statt jährlich wurden. „Wir haben heute Deployment-Tag“ bedeutet Release-Tag.

Der Begriff „Hochladen“ hat seine Wurzeln im frühen Web, als Seiten per FTP auf Server hochgeladen wurden. „Dateien auf den Server hochladen“ — buchstäblich Dateien über ein Protokoll übertragen, das mit „Gießen“ von Daten assoziiert wurde. Das Wort hat sich gehalten, obwohl modernes Deployment CI/CD-Pipelines und keine FTP-Clients verwendet. Interessante Tatsache: im Englischen ist das Analogon “push” (Push to Server), nicht “pour”. Die russische Sprache hat eine andere Metapher gewählt.

Der Begriff „Anwenden“ stammt aus der Produktionsumgebung: „Ein Rad anbringen“, „Eine Mutter festziehen“. Im Kontext von Software — eine Änderung auf ein bestehendes System auflegen, wie das Aufschrauben eines Gewindes auf einen Bolzen. In Datenbanken ist der Begriff besonders organisch: Migrationen werden „angewendet“ und „zurückgesetzt“. Rollback ist einer der wenigen englischen Begriffe, der ein genaues russisches Pendant hat: „otkat“.

Unterschied zwischen den Begriffen in verschiedenen Kontexten

Im Kontext von Datenbanken: Migrationen werden „angewendet“, Daten werden „hochgeladen“, die Schema-Version wird „deployed“. Wenn eine neue Spalte hinzugefügt werden muss — eine Migration anwenden. Wenn Testdaten eingefügt werden müssen — einen Dump hochladen. Wenn sich die gesamte DB-Struktur ändert — ein neues Schema deployen. Der Unterschied spiegelt verschiedene Operationen wider: Apply, Insert/Load, Deploy.

Im Kontext von DevOps: „Deployen“ — eine Pipeline ausführen, „Hochladen“ — ein Docker-Image in eine Registry pushen, „Anwenden“ — eine Konfiguration per Ansible auf einen Server anwenden. Beispiel: „zuerst laden wir das Image in die Registry hoch, dann wenden wir die Konfiguration auf dem Server an, und erst dann deployen wir den Release“. Jeder Begriff entspricht einer separaten Stufe der CI/CD-Pipeline.

Im Kontext der mobilen Entwicklung: „Hochladen“ — einen Build an App Store Connect oder Google Play Console senden, „Deployen“ — im App Store veröffentlichen, „Anwenden“ — ein Update über den In-App-Update-Mechanismus ausliefern. Für iOS bedeutet „Deployen“ die Review zu bestehen, für Android den Rollout über die Play Console. Zeitskala: „Hochladen“ dauert Minuten, „Deployen“ dauert Stunden oder Tage (aufgrund der Review).

Schritte des Release-Prozesses: vom Commit bis zur Produktion

Schritt 1: Build (Build). Der Code wird kompiliert, ein Artefakt wird erstellt (Binärdatei, Docker-Image, APK/IPA). Der CI-Server führt den Build nach jedem Commit in den Hauptbranch aus. Das Ergebnis des Builds ist ein deploy-fähiges Artefakt mit einem eindeutigen Versionstag (semantische Versionierung oder Commit-Hash). Wenn der Build fehlschlägt — die gesamte Pipeline stoppt, der Entwickler erhält eine Benachrichtigung.

Schritt 2: Testen (Test). Unit-Tests, Integrationstests, Linter und Sicherheitsprüfungen (SAST) werden ausgeführt. Diese Phase sollte nicht länger als 10–15 Minuten dauern — wenn länger, verlieren die Entwickler den Kontext und wechseln zu anderen Aufgaben. Schnelles Feedback ist ein Schlüsselprinzip von CI/CD. Laut Puppet State of DevOps 2023 machen Teams mit schnellem Testen (<10 Min) dreimal mehr Releases.

Schritt 3: Deployment auf Staging (Staging Deploy). Das Artefakt wird in einer zur Produktion identischen Staging-Umgebung deployed. Auf Staging werden E2E-Tests, Smoke-Tests und bei Bedarf manuelle QA-Tests durchgeführt. Wenn auf Staging eine Regression gefunden wird — wird der Release blockiert und die Änderungen zur Überarbeitung zurückgeschickt.

Schritt 4: Deployment auf Produktion (Production Deploy). Das Artefakt wird auf den Produktionsservern deployed. Je nach Deployment-Strategie (Rolling, Blue-Green, Canary) kann der Rollout von Sekunden bis zu Stunden dauern. Nach dem Rollout werden Post-Deploy-Tests und Monitoring durchgeführt — wenn die Metriken normal sind, gilt der Release als erfolgreich. Automatischer Rollback bei Überschreitung der Fehlerschwelle ist Standardpraxis.

Deployment-Strategien: Rolling, Blue-Green, Canary

Rolling Deploy — Server werden nacheinander aktualisiert. Während ein Server aktualisiert wird, bedienen die anderen weiterhin die Benutzer. Nach erfolgreicher Aktualisierung des ersten Servers wird der zweite aktualisiert, und so weiter. Nachteil: während des Deployments laufen auf verschiedenen Servern unterschiedliche Versionen, was Inkompatibilität verursachen kann. Vorteil: Zero-Downtime und keine Notwendigkeit für doppelte Serverkapazität.

Blue-Green Deploy — zwei identische Umgebungen: Blue (aktuelle Version) und Green (neue Version). Sobald Green vollständig bereit und getestet ist, schaltet der Load-Balancer den Traffic von Blue auf Green um. Wenn ein Problem auf Green gefunden wird — zurück zu Blue. Vorteil: sofortiger Rollback. Nachteil: doppelte Ressourcen (Server) zur Unterstützung von zwei Umgebungen erforderlich. Die Umschaltung dauert Sekunden.

Canary Deploy — die neue Version wird zunächst auf einen kleinen Prozentsatz der Server (5–10%) deployed. Ein Teil der Benutzer erhält die neue Version, der Rest bleibt auf der alten. Wenn die Metriken in der Canary-Gruppe normal sind (Fehlerrate nicht gestiegen, Latenz nicht erhöht), wird die neue Version schrittweise auf alle Server ausgerollt. Google, Netflix, Spotify verwenden Canary Deploy zur Risikominimierung. Nachteil: Komplexität des Monitorings und der Metrikanalyse.

Automatisierungswerkzeuge für das Deployment

CI/CD-Server — Jenkins, GitLab CI, GitHub Actions, CircleCI, Bitrise (für mobile). Sie werden je nach Stack ausgewählt: Jenkins ist universell, GitLab CI wenn das Repository auf GitLab ist, Bitrise für iOS/Android. Die Hauptaufgabe eines CI/CD-Servers ist die automatische Ausführung der Build-, Test- und Deployment-Pipeline ohne menschliches Eingreifen.

Containerisierung — Docker, Kubernetes. Docker erstellt isolierte Container mit der Anwendung und allen Abhängigkeiten. Kubernetes verwaltet das Deployment von Containern über einen Server-Cluster: automatisches Rolling Update, Skalierung, Lastverteilung. Laut CNCF Survey 2023 verwenden 96% der Organisationen Container in der Produktion, davon 67% Kubernetes.

Infrastructure as Code — Terraform, Ansible, Pulumi. Terraform beschreibt die Infrastruktur (Server, Netzwerke, Load-Balancer) als Code und verwaltet ihren Zustand. Ansible ist für die Serverkonfiguration zuständig: Softwareinstallation, Parametereinstellung. Die Kombination Terraform + Ansible bietet eine vollständig automatisierte Infrastruktur: Terraform erstellt die Server, Ansible konfiguriert sie. Unveränderliche Infrastruktur — Server werden nicht aktualisiert, sondern durch neue mit einem aktualisierten Image ersetzt.