1 Kurzbeschreibung
In diesem Dokument wird die Verwendung der Labels im System detailliert beschrieben.
2 Begriffsbestimmung
Release
Ein Release wird durch einen String der Form V.R.M angegeben: Version, Release und Modification-Level.
Neue Versionen werden in Abständen von ca. 2-3 Jahren freigegeben. Neue Releases werden in Abständen von ca. einem Jahr erstellt. Der Modification-Level wird erhöht, wenn wesentliche Neuerungen zu einem schon freigegebenen Release hinzukommen.
Softwareaktualisierung
Logische Einheit die Versionen von Entwicklungsobjekten zwischen Systemen transportiert. Zu jeder Softwareaktualisierung entstehen zwei Dateien, das Code-Refresh (Endung .cr) und das Source-Refresh (Endung .sr)
Jede Softwareaktualisierung lässt sich durch Release, ID und Ursprungsrepository (Exportpräfix, z. B. babel) eindeutig identifizieren. Partner können Softwareaktualisierungen erzeugen, um kundenspezifische Änderungen und eigene Standard-Erweiterungen ausliefern.
Softwareaktualisierungen enthalten Fehlerkorrekturen/Erweiterungen, die für ein bestimmtes Release durchgeführt werden. Pro Release können beliebige viele Softwareaktualisierungen erzeugt werden.
Zwei Klassen von Softwareaktualisierungen werden unterschieden: System-Code (SYS-Softwareaktualisierungen) und Anwendungs-Code (APP-Softwareaktualisierungen). SYS-Softwareaktualisierungen umfassen die Entwicklungsobjekte aus den Namensräumen unterhalb von „com.cisag.pgm“ und „com.cisag.sys“, sowie unterhalb der zugehörigen Unternamensräume aus „com.cisag.archive“, „com.cisag.dbu“ und „com.cisag.nls“. Alle anderen Entwicklungsobjekte werden mit APP-Softwareaktualisierungen transportiert. Im speziellen sind das alle Entwicklungsobjekte, die nicht von der Standardentwicklung dieser Software angelegt wurden. Im Gegensatz zu APP-Softwareaktualisierungen enthalten SYS-Softwareaktualisierungen keine Entwicklungsobjekte vom Typ Java-Klasse. Diese sind für den System-Code in der Systemengine enthalten.
3 Beschreibung
Die Versionen der Entwicklungsobjekte können mit einem oder mehreren Labeln versehen werden. Labels werden benutzt, um einen Releasestand zu kennzeichnen oder Entwicklungsobjekte an eine Softwareaktualisierung zu binden. Es werden drei Typen von Labeln unterschieden:
- Release-Label, dieser Typ dient nur zur Kennzeichnung eines Releasestands.
- Export-Label, bindet eine Version an eine Softwareaktualisierung vom Typ Export. Export-Labels werden automatisch vom System an die Versionen gebunden.
- Import-Label, bindet eine Version an eine Softwareaktualisierung vom Typ Import. Import-Labels werden automatisch vom System an die Versionen gebunden.
Bevor ein Release freigegeben wird, sind Entwicklungsobjekte mit einem Release-Label zu versehen. Damit wird der Stand festgehalten, der sich nach einer Neuinstallation des Standard-Systems beim Partner oder Kunden wiederfindet. Alle Fehlerbehebungen, die in der Folge vorgenommen werden, basieren auf dem gelabelten Stand.
Ein Export-Label stellt die Verknüpfung zwischen einer Softwareaktualisierung und den darin enthaltenen Entwicklungsobjekten her. Beim Generieren der Code-Refresh- und Source-Refresh-Datei werden alle gelabelten Entwicklungsobjekte berücksichtigt.
Bei der Installation von Softwareaktualisierungen werden alle im Archiv eingespielten Entwicklungsobjekte mit einem Import-Label versehen. Damit wird eine Verknüpfung zwischen installierten Softwareaktualisierungen und zugehörigen Entwicklungsobjekten hergestellt.
In der Anwendung Entwicklungsobjekte gibt es eine Sicht, in der die Labels zum geladenen Entwicklungsobjekt über alle Versionen angezeigt werden. Durch die Typisierung der Labels ist gut zur erkennen, welche Version mit welcher Softwareaktualisierung ausgeliefert bzw. installiert wurde.
4 Release-Labels
Ein Release dient zum Labeln von Entwicklungsobjekten und als Aufhänger von Softwareaktualisierungen.
Die aktiven Versionen aller Entwicklungsobjekte können mit einem Release-Label versehen werden. Bei „echten“ Releases (V.R.M) wird grundsätzlich der Entwicklungsstand vor dem Release-Abschluss festgehalten. Daneben können beliebige Stände gelabelt werden. Die ist beispielsweise sinnvoll, bevor ein Entwicklungssystem abgespalten oder ein Auslieferungssystem erstellt wird. Derzeit haben Release-Labels nur informellen Charakter.
Es wird immer die aktive und nicht die aktuelle Version des Entwicklungsobjekts mit einem Label versehen. Ist ein Objekt in Bearbeitung, so wird eine Warnung ausgegeben und das Label ebenfalls an die aktive Version gehängt. Gelöschte Entwicklungsobjekte werden ebenfalls gelabelt.
Nach Abschluss des Labelings ist das Release freizugeben Ein freigegebenes Release kann weder gelöscht noch geändert werden, d.h. der gelabelte Entwicklungsstand ist damit festgeschrieben. Ein „echtes“ Release (V.R.M) wird zudem noch aktiviert. Da lediglich ein aktives Release existieren darf, wird der Status des zuvor aktiven Releases auf „Freigegeben“ gesetzt.
Vorgehensweise zur Erstellung eines Release-Labels „wrkreldef“ ein Release definiert (siehe auch Dokument Mit Releasedefinitionen arbeiten). Danach werden alle aktiven Versionen der Entwicklungsobjekte mit einem Label zu versehen. Beim Labeln der Entwicklungsobjekte sollte keine Entwicklungsaufgabe offen sein, da die aktiven Versionen mit Labeln versehen werden, nicht die in Entwicklungsaufgaben gesperrten Versionen. Das Labeln der aktiven Version erfolgt durch das Tool „wrkrellbl“. Anschließend wird mit „wrkreldef“ das Release freigeben bzw. aktiviert.