Was ist Software Deployment?

Während K55 (CI/CD) die Pipeline behandelt hat (Code → Build → Test), geht es hier um den nächsten Schritt: wie kommt die fertige Software auf die Zielsysteme? Das klingt einfach – ist aber in der Praxis ein eigenes Fachgebiet mit vielen Fallstricken.

Ob du als FISI ein neues Programm auf 200 Arbeitsplätze ausrollen sollst, oder als FIAE eine neue Version deiner Webanwendung live bringst – die Konzepte sind ähnlich. Diese Lektion klärt die Grundbegriffe: was bedeutet Deployment, welche Akteure und Phasen gibt es, wie unterscheiden sich Deployment, Release und Installation, und warum ist das ein Risiko-Thema?

1) Was bedeutet „Deployment"?

Wörtlich übersetzt heißt deploy „in Stellung bringen" – aus dem militärischen Sprachgebrauch. In der IT bedeutet Deployment: fertige Software wird vom Build-Output auf die Zielumgebung gebracht und dort lauffähig gemacht.

Das umfasst mehr als nur „Datei kopieren". Ein vollständiges Deployment beinhaltet typischerweise:

• Bereitstellen der Software: Dateien auf die Zielsysteme bringen
• Konfiguration: Anpassung an die Umgebung (Datenbankzugänge, URLs, Lizenzschlüssel)
• Abhängigkeiten: benötigte Bibliotheken, Frameworks, Laufzeitumgebungen installieren
• Datenbank-Migrationen: Schema-Änderungen einspielen
• Service-Steuerung: Dienste stoppen, neu starten, neu konfigurieren
• Smoke-Tests: schnelle Funktionsprüfungen nach dem Deploy
• Monitoring: Verhalten beobachten – ist alles in Ordnung?

2) Der Deployment-Lifecycle

Software durchläuft mehrere Stufen vom Quellcode bis zur laufenden Anwendung. Diese Stufen sehen so aus:

3) Deployment vs. Release vs. Installation

Drei oft verwechselte Begriffe. Sie haben unterschiedliche Bedeutungen und werden in Klausuren gerne abgefragt:

4) Akteure und Verantwortlichkeiten

Wer ist beim Deployment beteiligt? In klassischen Unternehmen gibt's klare Rollen, in DevOps-Kulturen verschwimmen die Grenzen:

5) Manuell vs. automatisiert

Deployments können auf zwei grundsätzlich verschiedene Arten passieren – das eine ist die alte Welt, das andere der Standard heute:

6) Klassische Anwendungsfälle

Deployment ist nicht nur Webentwicklung. In der Praxis gibt es viele Szenarien:

• Webanwendung deployen: neue Version einer Web-App auf den Server bringen
• Mobile App veröffentlichen: APK/IPA in App Stores hochladen
• Desktop-Software ausrollen: Microsoft Office auf 500 Arbeitsplätze
• Embedded-Update: Firmware-Update für IoT-Geräte oder Maschinen
• Backend-Service updaten: Microservice neu deployen ohne Downtime
• Datenbank-Migration: Schema-Änderungen einspielen
• Konfig-Änderungen: nur Konfiguration anpassen, kein neuer Code

Je nach Szenario unterscheiden sich die Werkzeuge stark. Mobile App vs. Backend-Service haben kaum Berührungspunkte. Aber das Grundprinzip „kontrolliert, automatisiert, mit Rollback-Möglichkeit" gilt überall.

7) Warum Deployment ein Risiko ist

Jedes Deployment kann theoretisch Production crashen lassen. Genau deswegen werden Deployments oft als „Risikomoment" betrachtet. Was kann schiefgehen?

8) Deployment-Frequenz: wie oft?

Wie häufig sollte deployed werden? Die Antwort hat sich in 20 Jahren radikal geändert:

Die DORA-Forschung hat gezeigt: häufigere Deployments korrelieren mit besserer Stabilität – das klingt paradox, ist aber logisch. Wer ständig deployed, optimiert seine Tools dafür, hat kleine Änderungen pro Deploy und schnelle Rollback-Mechanismen. Mehr in K55 L9 Monitoring.

9) Drei typische Deployment-Modelle

Es gibt drei Hauptarten wie Software auf die Zielsysteme kommt – jeweils mit eigenen Stärken:

• Push-Modell: ein zentraler Server schickt aktiv die Software an die Ziele (z.B. Ansible). Einfach, aber Ziele müssen erreichbar sein.
• Pull-Modell: die Zielsysteme holen sich die Software selbst (z.B. Linux mit apt update oder Kubernetes mit GitOps). Skaliert gut, Ziele steuern den Zeitpunkt selbst.
• Image-basiert: das Ziel wird komplett neu gebaut, mit der gewünschten Software „eingebacken" (Docker-Container, Cloud-VM-Images). Maximale Reproduzierbarkeit.

In modernen Umgebungen werden diese oft kombiniert: Docker-Image wird gebaut (image-basiert), Kubernetes pullt das Image (Pull), und alles wird über CI/CD orchestriert.

10) Was du in den nächsten Lektionen lernst

K56 vertieft die wichtigsten Deployment-Aspekte. Hier ein Ausblick auf die Lektionen:

• L2 – Deployment-Strategien: Big Bang, Rolling, Blue-Green, Canary
• L3 – Software-Pakete: MSI, MSIX, DEB, RPM
• L4 – Windows-Verteilung: WSUS, Intune, PDQ
• L5 – Linux-Verteilung: apt, yum, Ansible
• L6 – Ansible-Grundlagen: Configuration Management (Übersicht)
• L7 – IaC mit Terraform: Infrastructure as Code (Übersicht)
• L8 – Umgebungen: Dev, Test, Staging, Prod
• L9 – Rollback-Strategien
• L10 – IHK-Aufgaben

K56 baut stark auf K55 (CI/CD) auf. Idealerweise hast du K55 schon durchgearbeitet – dann fühlen sich viele Konzepte hier wie eine logische Fortsetzung an.

Zusammenfassung

Software Deployment bringt fertige Software vom Build-Output auf die Zielsysteme und macht sie lauffähig. Mehr als nur Datei-Kopieren: Konfiguration, Dependencies, DB-Migrationen, Service-Steuerung, Smoke-Tests, Monitoring. Deployment-Lifecycle: Source → Build → Package → Deploy → Run. Wichtige Unterscheidung: Deployment (Software ist da), Release (User können nutzen), Installation (einzelnes Gerät). Akteure: Developer, DevOps Engineer, Sysadmin, Release Manager, Product Owner, QA. Modern: „you build it, you run it". Manuell vs. automatisiert: heute klar automatisiert via CI/CD. Risiken: Code-Bugs, DB-Migrationen, Config, Dependencies, Downtime, Kompatibilität, Rollback. Frequenz hat sich von Quartal zu mehrmals täglich entwickelt – häufigere Deploys = bessere Stabilität laut DORA. Drei Modelle: Push (Ansible), Pull (apt, GitOps), Image-basiert (Docker). Foundation-Lektion für den ganzen Kurs.