Auf einen Blick: Die Bereitstellung von Software beinhaltet, sie durch kontrollierte Umgebungen zu bewegen, während das Release sie den Nutzern zur Verfügung stellt. Wichtige Aktivitäten im Deployment sind Planung, Verifikation, Ausführung und Bestätigung, während das Release-Management mit Geschäftsstrategien für die Verfügbarkeit von Funktionen übereinstimmt.
- Deployment-Techniken umfassen Blue-Green- und rollierende Deployments.
- Freigabetypen werden als große, kleine, Notfall- und Wartungsfreigaben kategorisiert.
Trotz aller Arbeit in der Welt der Softwareentwicklung wird der Wert der Software erst realisiert, wenn ein Kunde die Software nutzt, um ein Ergebnis zu erzielen.
Jeden Tag werden Tausende von Updates in App-Stores bereitgestellt, meist mit Bugfixen, Sicherheitsupdates und Leistungsverbesserungen; manchmal werden die neuesten Funktionen den Nutzern zur Verfügung gestellt. Das App-Store-Intelligenzunternehmen App Annie berichtete, dass im zweiten Quartal 2020 die App-Downloads einen Höchststand von fast 35 Milliarden erreichten.
Im Servicemanagement werden zwei Begriffe, Deployment und Release, oft synonym verwendet, um den Rollout dieser Updates zu beschreiben. Aber gibt es einen Unterschied zwischen ihnen? Lassen Sie uns das untersuchen. (Für die kurze Antwort springen Sie zum wesentlichen Unterschied zwischen Deployment und Release von Software.)
Was ist Deployment?
Die Bereitstellung beinhaltet das Verschieben von Software von einer kontrollierten Umgebung in eine andere. Laut den ITIL-4-Praxisleitfäden ,
Eine Umgebung ist eine Teilmenge der IT-Infrastruktur, die für einen bestimmten Zweck verwendet wird.
Die häufigsten Umgebungen sind:
- Entwicklung. Üblicherweise als Dev bezeichnet, hier bauen Entwickler den Code.
- Integration. Hier wird der neue Code kombiniert und überprüft, dass er mit bestehendem Code funktioniert.
- Test. Hier werden sowohl funktionale als auch nicht-funktionale Tests am zusammengeführten Code durchgeführt, um sicherzustellen, dass er den Anforderungen der Organisation und des Kunden entspricht.
- Staging. Diese Umgebung wird verwendet, um die Software mit echten Daten zu testen, um sicherzustellen, dass sie einsatzbereit ist.
- Produktion. Gemeinhin als Produktion bezeichnet, wird die Software den Nutzern zur Verfügung gestellt.
Die Bereitstellung gilt allgemein als die letzte Phase des Softwareentwicklungslebenszyklus (SDLC):
Einsatzaktivitäten
Die im Einsatzmanagement anfallenden Aktivitäten umfassen:
- Planung des Einsatzes. Vorbereitungsaufgaben wie Autorisierung, Ausrichtung der Ressourcen und Terminplanung.
- Verifizierung von Servicekomponenten. Unit- und Integrationstests, mit iterativer Reparatur und erneuten Tests.
- Verifizierung der Zielumgebungen. Validierung, um sicherzustellen, dass die Host-Umgebungen bereit sind, die Softwarepakete zu akzeptieren.
- Ausführen der Bereitstellung. Die Software in die Umgebung bringen und relevante Systemtests durchführen.
- Bestätigung der Bereitstellung. Akzeptanztests zur Validierung der Kundenanforderungen sind erfüllt. Auch Aktivitäten nach der Überprüfung und Erkenntnisse werden hier durchgeführt.
Einsatztechniken
Traditionell wurden Deployments mit dem sogenannten Big-Bang-Ansatz durchgeführt, bei dem alle Funktionen auf einmal veröffentlicht werden. Derzeit werden aufgrund von Technologie und Risikomanagement rollierende oder phasenweise Deployments bevorzugt, indem sie über einen längeren Zeitraum schrittweise in der Umgebung freigegeben werden.
Eine gängige Technik bei der Bereitstellung ist der Blue-Green-Ansatz. Hier werden zwei identische, aber getrennte Produktionsumgebungen verwendet, wobei der aktuelle Code in der 'blauen' Umgebung läuft und der neue Code in der 'grünen' Umgebung bereitgestellt wird. Der Datenverkehr wird dann von blau auf grün umgestellt, und die Leistung des neuen Services oder der neuen Funktionen wird überwacht. Im Falle eines größeren Problems wird der Datenverkehr wieder auf Blau umgestellt (ähnlich wie bei einem Rollback), was Reparaturen und Korrekturen ermöglicht, ohne die Kunden wesentlich zu beeinträchtigen.
Verbesserung der Einsatzaktivitäten
Die Bereitstellung war im Laufe der Jahre ein herausfordernder Teil der Softwareentwicklung, wurde aber in letzter Zeit durch Fortschritte in Praktiken wie DevOps erleichtert. CI/CD (Continuous Integration/Continuous Delivery or Deployment) hat dank Automatisierung bei Integration, Testing und Bereitstellung zu einer schnelleren Bereitstellung von Software mit weniger Fehlern geführt. Werkzeuge werden in diesem Bereich schnell zu gängigen Mainstream-Lösungen, wie zum Beispiel:
Viele Organisationen nutzen jedoch weiterhin manuelle Änderungsgenehmigungen, um die Bereitstellung in Produktionsumgebungen auszulösen, typischerweise aus zwei Hauptgründen:
- Um das Risiko zu mindern, falls Live-Dienste betroffen sind.
- Um Compliance-Anforderungen zu erfüllen.
Was ist eine Softwareversion?
Nach der ISO/IEC 20000-Normdefinition ist eine Veröffentlichung:
Eine Sammlung von einem oder mehreren neuen oder geänderten Diensten oder Servicekomponenten, die infolge einer oder mehrerer Änderungen in die Live-Umgebung eingesetzt wurden.
Mit anderen Worten: Ein Release macht Dienste und Funktionen den Nutzern zugänglich. Oft ist Release-Management eher eine geschäftliche als eine technische Verantwortung. Das liegt daran, dass Entscheidungen über die Terminplanung von Releases aus Umsatz- oder Portfoliomanagement-Sicht an die Geschäftsstrategie gebunden sein können.
Ein Unternehmen kann entscheiden, Funktionen basierend auf einem vereinbarten Marketingplan zu veröffentlichen oder die Veröffentlichungen zu staffeln, um eine Kannibalisierung bestehender Produkte zu verhindern oder um Konkurrenzaktivitäten entgegenzuwirken. Funktionen können auch an verschiedene Kunden basierend auf dem Produktangebot des Unternehmens freigegeben werden, z. B. Premium-Kunden, die erweiterte Funktionen erhalten.
Veröffentlichungskategorien
Die allgemeinste Kategorisierung der Veröffentlichungen basiert auf dem Umfang:
- Die Begriffe Major und Minor werden verwendet, um eine Veröffentlichung im Hinblick auf die Bedeutung von Änderungen in Code, Service und Funktionen zu beschreiben. Zum Beispiel könnte eine große Version dazu führen, dass eine Software von Version 2.4 auf 3.1 wechselt, während eine kleinere Version von 2.2.1 auf 2.2.2 liegt.
- Emergency Release wird verwendet, um eine Softwareversion oder ein Paket zu definieren, das schnell verfügbar ist, um ein großes Problem zu beheben, insbesondere aus Sicherheits- oder Leistungsperspektive.
- Wartungsfreigabe für Fehlerbehebungen und Patches.
- Feature-Release für neue oder geänderte Funktionalität.
Freisetzungstechniken
Einige Release-Techniken, die in der Softwareentwicklung verwendet werden, umfassen:
- Kanarienvogel-Veröffentlichung. Dies beinhaltet die Veröffentlichung neuer Funktionen nur für eine Teilgruppe von Nutzern. So wie Kanarienvögel verwendet werden, um giftige Gase in Minen zu testen, ist diese Nutzergruppe der Testfall, um Probleme aufzudecken, bevor der Rest der Population Zugang erhält.
- Dark Launching. Ähnlich wie bei Canary-Releases beinhaltet Dark Launching die Aktivierung von Funktionen für eine Teilmenge von Nutzern, die sich der neuen Funktionen nicht bewusst sind (daher "dark"). Dies kann durch den Einsatz von Feature-Flags geschehen, die das Ein- und Ausschalten von Funktionen je nach Bedarf der Organisation ermöglichen.
Einsatz vs. Release: Der entscheidende Unterschied
Der entscheidende Unterschied zwischen Deployment und Release ist die geschäftliche Begründung. Deployment bedeutet nicht zwangsläufig, dass Nutzer Zugang zu Funktionen haben, wie klar an den verschiedenen beteiligten Umgebungen zu erkennen ist. Einige Unternehmen veröffentlichen zeitgleich mit der Bereitstellung in Produktion.
Andere entscheiden sich zu warten, wodurch die neuen Funktionen in Produktion sind, aber den Nutzern erst zur Verfügung stehen, wenn das Unternehmen sich entscheidet.
Zusätzliche Ressourcen
Für mehr zu diesem Thema entdecken Sie diese Ressourcen:
Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.