Aktivität

[Eigene Ergänzungen/Erfahrungen bearbeiten]

Konfigurations- und Umgebungsmanagement

A-299 Release entwickeln

Release entwickeln, aus einem Build ein Release machen

Aktivität muss nicht durchgeführt werden in Entwurf-/Architekturphase (Startphase) (Singuläre Aktivität) (bei Bedarf, prototypisch)
Aktivität sollte durchgeführt werden in Konstruktionsphase (Hauptphase) (Singuläre Aktivität)
Aktivität sollte durchgeführt werden in Einführungsphase (Singuläre Aktivität)


Täglich und spätestens am Ende der Iteration entsteht ein aktuelles Build von dem in Entwicklung befindlichen System. Zusätzlich hierzu stellt sich die Frage, wie Releases entstehen.

Ein Release ist die Weiterentwicklung eines Build. Im Gegensatz zum Build muss ein Release definierte fachliche Anforderungen erfüllen, d.h. entsprechend getestet werden, in die Zielumgebung überführt werden oder zumindest dafür bereitstehen, zuvor möglicherweise in einer Testumgebung betrieben werden, Abnahme- und Freigabeprozeduren durchlaufen und einiges mehr. Manchmal sind Testläufe notwendig, die nur nachts oder am Wochenende möglich sind.

Die dafür notwendigen Tätigkeiten können wiederum mit Arbeitsaufträgen geplant und umgesetzt werden, müssen dabei jedoch nicht mehr dem Iterationszyklus folgen. Welche Vorgehensweise hier konkret sinnvoll ist, hängt von dem für die Releaseentwicklung notwendigen Aufwand ab.

Sofern Releases ohne größere besondere Aufwände erstellt werden können, ist es denkbar, dass das letzte Build innerhalb einer Iteration auch gleichzeitig ein Release wird. In den meisten Fällen sind für die Releaseentwicklung aber einige Tage oder Wochen Arbeit notwendig. In diesem Fall wird ein Build aus der iterativen Entwicklung herausgegriffen und Basis für die Releaseentwicklung. Die Entwicklung verzweigt dann in zwei Richtungen. Mit dem einen Entwicklungspfad geht die iterative Entwicklung ganz normal weiter, d.h., es werden schrittweise, Build für Build, weitere Funktionalitäten und Features hinzugefügt. In dem anderen Entwicklungspfad werden keine weiteren Funktionalitäten hinzugefügt, außer sie sind zur Stabilisierung oder Freigabe notwendig. Stattdessen werden alle notwendigen Voraussetzungen geschaffen, um die Software einführen bzw. ausliefern zu können.

Die damit verbundenen Arbeitsaufträge und Schritte nach dem gleichen iterativen Schema abzuwickeln, sie also auch Reviews zu unterziehen etc., ist in den meisten Fällen nicht sinnvoll, da der Prozess der Relaseentwicklung bereits eine Bewertung und eine Rückmeldung darüber beinhaltet, wie brauchbar das Build war. Nach der Releasefreigabe gibt es dann weitere Rückmeldungen. Ausnahmen sind möglicherweise Projekte, die mehrere Monate Zeit benötigen, um aus einem Build ein Release zu machen. Dann sind dies schon eigene kleine Projekte, die wiederum iterativ abgewickelt werden können.

Erstellen Sie zusammen mit allen Betroffenen eine Checkliste, was für die Produktionsfreigabe eines Releases notwendig ist, und verwenden Sie diese dann für jede Releaseentwicklung.


Begründung:

Auslöser:

Vorbedingung:

Unterlagen:

E-180 Build [1]
E-177 Konfigurationsplan
E-84 Migrationskonzept
E-179 Releaseplan
E-164 Roll-Out-Plan

Gegenbedingung:

Ergebnisse:

E-182 Release [1]

Besond. Hilfsmittel:


Verantwortlicher:

projektintern.Technische Projektleitung

Beteiligte:

projektintern.AnwendungsentwicklerIn
projektextern.DV-Leitung
projektintern.Fachliche Projektleitung
projektintern.Konfigurations- und Build-ManagerIn
projektintern.Projekt-QualitätsmanagerIn
projektextern.Second-Level-Support

Nachfolg. [Beding.]:

A-302 Release testen

OEP - Object Engineering Process, v3.0, 06.11.2006 11:04:58, Copyright © 2006 by oose Innovative Informatik eG