Software-Change-Management-Prozess 

Einsatzmöglichkeiten

Der Software-Change-Mangement-Prozess der SAP beschreibt den Ablauf einer Softwareentwicklung von der lokalen Entwicklung bis zum Deployment auf einem zentralen Produktivsystem.

Überblick über den Software-Change-Management-Prozess

Für den produktiven Einsatz von Applikationen müssen Sie eine Systemlandschaft bestehend aus DTR-Workspaces und SAP J2EE Engines aufgebaut werden, die verschiedene Rollen übernehmen, wie Entwicklung (development), Konsolidierung (consolidation), Test (test) und Produktion (production). Die lokalen Entwicklungen fließen dann gemäß der Systemrollen bis in das produktive System.

Wenn innerhalb des Software-Change-Management-Leitfadens von Workspaces gesprochen wird, sind immer DTR-Workspaces gemeint.

Voraussetzungen

Sie arbeiten mit dem SAP NetWeaver Developer Studio und dem Design Time Repository (DTR).

Um das Deployment aus dem SAP NetWeaver Developer Studio heraus durchführen zu können, müssen Sie für jedes System ein eigenes Developer Studio konfigurieren.

Sie können alle Funktionen des DTR über den Kommandozeilen-Client ausführen. Sie haben aber auch die Möglichkeit, das DTR-Administrator-Plugin zu verwenden. Dann können Sie alle notwendigen Administrationsaufgaben über die graphische Benutzeroberfläche des SAP NetWeaver Developer Studios durchführen.

Ablauf

Workspaces konfigurieren

Software Change Management beginnt mit dem zentralen Anlegen der Workspaces im Design Time Repository (DTR) für die Entwicklung im Szenario „Java-Projekte mit zentraler Quelldateienablage“.

Projekte/Konfigurationen anlegen oder importieren

Die Entwicklung selbst beginnt mit dem Anlegen lokaler Projekte oder Development-Configurations auf dem Entwicklungsrechner.

Szenario 1:

Die Entwickler synchronisieren ihr SAP NetWeaver Developer Studio mit der Workspace-Struktur des DTR und richten sich darunter ein Entwicklungsprojekt im SAP NetWeaver Developer Studio ein. Für den Fall, dass bereits Projekte zentral definiert wurden, können die Entwickler die bestehenden Projekte in ihre Umgebung importieren.

Siehe auch: Szenario „Java-Projekte mit zentraler Quelldateienablage“ - Projekte anlegen

Lokale Entwicklungsumgebung synchronisieren

Im nächsten Schritt synchronisieren die Entwickler ihre lokale Entwicklungsumgebung mit dem DTR und laden die notwendigen Ressourcen (Dateiordner, Quelltextdateien, Metadaten) auf ihren Rechner. Anschließend können Sie Quelltexte ändern. Die Änderungen sammeln Sie in einer Activity, die als Ablage logisch zusammenhängender Entwicklungen dient.

Weitere Informationen zu Activities finden Sie unter Modifikationen einer versionierten Ressource.

Lokal entwickeln und testen

Im anschließenden Entwicklungsprozess entwickeln und testen die Entwickler ihre Änderungen lokal, bis ein stabiler Stand erreicht ist.

Änderungen einchecken

Nach erfolgreichem Test der Änderungen im lokalen J2EE Server checken die Entwickler die geänderten Ressourcen in den Entwicklungs-Workspace (DEV-Workspace) des DTR ein. Danach sind die Quelltexte für alle anderen Entwickler sichtbar und stehen dem Build für das zentrale Entwicklungssystem zur Verfügung.

Build und Deployment auf zentralem Entwicklungssystem durchführen

...

Der Systemadministrator synchronisiert den zentralen Entwicklungsserver zu festgelegten Zeitpunkten mit allen Änderungen im DEV-Workspace des DTR.

Dann startet der Systemadministrator den Build und das Deployment aus dem SAP NetWeaver Developer Studio heraus.

Weitere Informationen finden Sie unter Build und Deployment auf zentralem Testsystem durchführen.

Änderungen in Konsolidierungs-Workspace integrieren

In diesem Schritt übernimmt der Systemadministrator alle Änderungen, die die Entwickler im DEV-Workspace eingecheckt haben, in den Konsolidierungs-Workspace (CONS-Workspace). Dafür sollten die Systemadministratoren einen Zeitplan definieren, der festlegt, zu welchen Zeitpunkten die Änderungen übernommen werden.

Übernehmen Sie die Änderungen nur, wenn der zuvor erfolgte Build und das Deployment im zentralen Entwicklungssystem erfolgreich waren.

Für die Übernahme verwendet der Systemadministrator die Funktion Integrate to... in der DTR-Perspektive des SAP NetWeaver Developer Studio oder den DTR-Kommandozeilen-Client. Der Integrationsschritt übernimmt die Änderungen, die in einer Activity gesammelt wurden und integriert die Activity in den zugewiesenen Workspace.

Weitere Informationen finden Sie unter Änderungen in den Konsolidierungs-Workspace integrieren.

Entwicklungsstand im CONS-Workspace einfrieren

Einen erfolgreich konsolidierten Stand können Sie festhalten, indem Sie dokumentieren, welche Activity zuletzt integriert wurde. Jede Activity erhält für einen Workspace, dem sie hinzugefügt wird, eine fortlaufende Nummer (Integration Sequence Number, ISN), die zusammen mit der Workspace-URL eine eindeutige Version des Workspace ergibt.

Die höchste ISN kennzeichnet die zuletzt integrierte Activity. Um einen stabilen Stand des CONS-Workspace wiederherzustellen, müssen Sie Sync to date... auf den Zeitstempel der entsprechenden Activity durchführen.

Wir empfehlen eine Liste über konsolidierte Softwarestände zu führen, die anhand der Activity-ISN und der Workspace-URL eindeutig identifiziert sind. Gleichzeitig dokumentiert die Liste auch den Entwicklungsfortschritt.

Weitere Informationen finden Sie unter Entwicklungsstände einfrieren.

Build und Deployment auf zentralem Testsystem durchführen

Analog zu dem Build und Deployment auf das zentrale Entwicklungssystem führt der Systemadministrator den Build- und Deployment-Vorgang auf das zentrale Testsystem aus. Dafür synchronisiert er den aktiven Stand aus dem CONS-Workspace.

Qualitätssicherung der neuen Softwareversion durchführen

Nach erfolgreichem Deployment in das zentrale Testsystem erfolgt ein Test der geänderten Applikationen und eine Abnahme durch ein QA-Team.

Softwareänderungen in das Produktivsystem übernehmen

Nach QA-Test der geänderten Software übernimmt der Systemadministrator die Sourcen aus dem CONS-Workspace, führt einen Build durch und führt mit dem Ergebnis das Deployment auf den produktiven SAP Web Application Server durch.

Für das produktive System benötigen Sie keinen DTR-Workspace, weil in der produktiven Umgebung keine Sourcen geändert werden dürfen. Die Wartung von Systemständen ist unter Wartung und Support Packages beschrieben.

Nach der Übernahme in die Produktion kann der Systemadministrator die nächsten Änderungen der Software in die Konsolidierung übernehmen.