Nach dem initialen Rollout eines Projekts im Management Server / Delivery Server Umfeld (früher RedDot CMS und LiveServer) müssen Änderungen am System sorgsam geplant werden. Da es sich in der Regel um ständig verfügbare Webseiten handelt, können Auszeiten, Inkonsistenzen und mögliche Fehler nicht akzeptiert werden. Ebenfalls müssen fertige Entwicklungen häufig durch die Marketing- oder Rechtsabteilung freigegeben werden, bevor sie der Öffentlichkeit präsentiert werden dürfen. In der Softwareentwicklung werden für solche Anforderungen getrennte Entwicklungs- und Produktivsysteme genutzt. Dies lässt sich auch im Management Server / Delivery Server Umfeld umsetzen. Ein bewährtes Vorgehen hierzu wird in diesem Dokument beschrieben.

1. Entwicklungsumgebung
für den Open Text
Management Server
(früher RedDot CMS)
Umsetzung einer Umgebung für
Entwicklung/Test/Produktion
Juli 2012
Autor: Hilmar Bunjes (hilmar.bunjes@erminas.de)
Version: 1.0

2. Abstract
Nach dem initialen Rollout eines Projekts im Management Server / Delivery Server Umfeld
(früher RedDot CMS und LiveServer) müssen Änderungen am System sorgsam geplant
werden. Da es sich in der Regel um ständig verfügbare Webseiten handelt, können
Auszeiten, Inkonsistenzen und mögliche Fehler nicht akzeptiert werden. Ebenfalls müssen
fertige Entwicklungen häufig durch die Marketing- oder Rechtsabteilung freigegeben
werden, bevor sie der Öffentlichkeit präsentiert werden dürfen. In der Softwareentwicklung
werden für solche Anforderungen getrennte Entwicklungs- und Produktivsysteme genutzt.
Dies lässt sich auch im Management Server / Delivery Server Umfeld umsetzen. Ein
bewährtes Vorgehen hierzu wird in diesem Dokument beschrieben.
erminas GbR, Nadorster Str. 60, 26123 Oldenburg +49-(0)441/939 252 090 www.erminas.de
Seite 2

3. Inhalt
1 VORTEILE EINER MEHRSTUFIGEN ENTWICKLUNGSUMGEBUNG 4
2 AUFBAU UMGEBUNG MIT DEM MANAGEMENT SERVER 4
3 VON DER ENTWICKLUNG ZUM PRODUKTIVSYSTEM 5
4 AKTUALISIERUNG DER ENTWICKLUNGS- UND TESTUMGEBUNG 7
5 EINSATZ DES DELIVERY SERVER 8
6 BEHANDLUNG VON CSS UND JAVASCRIPT DATEIEN 8
7 ALTERNATIVE ENTWICKLUNG MIT TEMPLATEVARIANTEN 8
8 ZUSAMMENFASSUNG 9
erminas GbR, Nadorster Str. 60, 26123 Oldenburg +49-(0)441/939 252 090 www.erminas.de
Seite 3

4. 1 Vorteile einer mehrstufigen
Entwicklungsumgebung
Ohne mehrstufige Entwicklungsumgebungen müssen Änderungen direkt im
Produktivsystem umgesetzt werden. Dies führt schnell zu Auszeiten, Inkonsistenzen und
Fehlern im Webauftritt und damit zu einer Beschädigung der öffentlichen Wahrnehmung.
Mehrstufige Entwicklungsumgebungen entkoppeln die Entwicklung, das Testen und den
Produktivbetrieb. Entwicklung und Testen finden dennoch in einer Umgebung statt, die der
Produktivumgebung gleicht oder zumindest ausreichend ähnelt. Es lässt sich zur
Entwicklungszeit bereits das spätere Systemverhalten nachvollziehen.
Eine solche Umgebung besteht aus mindestens zwei (Entwicklung und Produktion) oder
drei (Entwicklung, Test und Produktion) Umgebungen, die nach Möglichkeit identisch
aufgebaut sind. Auf die abgeschlossene Entwicklung folgt die Migration in die
Testumgebung. Nach der erfolgten Abnahme wird in die Produktionsumgebung migriert.
Der prinzipielle Aufbau sieht wie folgt aus:
Entwicklung Test Produktion
Durch ein solches Vorgehen können Entwickler unabhängig von der live geschalteten
Webseite Änderungen vornehmen, ohne die publizierten Seiten negativ zu beeinflussen.
Größere Änderungen lassen sich problemlos entwickeln und danach testen, bevor sie
online gestellt werden.
Es muss ein Prozess definiert werden, wie Änderungen hin zum Produktionssystem
übernommen werden können. Ebenfalls muss die Rückrichtung behandelt werden, damit
die Entwicklung und der Test möglichst ähnlich der Produktionsumgebung sind. Direkte
Änderungen am Produktionssystem werden bei diesem Vorgehen in der Regel nicht
durchgeführt (außer bei zeitkritischen Problemen).
2 Aufbau Umgebung mit dem Management
Server
Ein Management Server ohne weitere externe Systeme benötigt einen Windows Server und
einen SQL Server bzw. Oracle Datenbankserver. Generell sollten der Windows Server und
erminas GbR, Nadorster Str. 60, 26123 Oldenburg +49-(0)441/939 252 090 www.erminas.de
Seite 4

5. der Datenbankserver auf zwei getrennten Maschinen laufen. Sofern dies aus Lizenz- oder
Ressourcengründen nicht für die Entwicklungs- und Testumgebungen möglich ist, kann ggf.
auf die Trennung verzichtet werden. In diesem Fall sollte jedoch vorher getestet werden, ob
die Performance der Systeme dann noch akzeptabel ist.
In vielen Projekten werden zusätzlich zum Management Server externe Systeme und
Abhängigkeiten wie Dokumenten-/Assetmanagement, versionsverwaltete Dateien und
eingebundene Inhalte verwendet. Hierbei muss im Einzelfall entschieden werden, ob auch
für diese eine Aufteilung in separate Entwicklungs- und Testsysteme sinnvoll und
notwendig ist und welche Kosten dadurch entstehen. Wenn die externen Abhängigkeiten
Teil des Entwicklungsprozesses sind, ist eine Aufteilung unumgänglich.
Neben dem Aufbau der Umgebung müssen zwei Prozesse definiert werden: Die Migration
von Änderungen in Richtung Produktivsystem und das Update der Entwicklungs- und
Testsysteme. Diese Prozesse werden in den folgenden zwei Kapiteln beschrieben.
3 Von der Entwicklung zum Produktivsystem
Der Prozess von der Entwicklung zum Produktivsystem erfolgt in Release-Zyklen. In einem
Zyklus werden alle Änderungen, die übertragen werden sollen, gesammelt und dann in
einem Schritt migriert. Die Zeiten zwischen den Releases können dabei entweder starr sein
(z.B. jeden Monat) oder auch flexibel (z.B. sobald bestimmte Anpassungen fertig sind). Zur
Vereinfachung der Migration sollte sichergestellt sein, dass zum Zeitpunkt des Releases
keine Entwicklungsarbeiten an zu migrierenden Änderungen mehr unfertig vorliegen.
Änderungen an Templates, Servereinstellungen, CSS/JS-Dateien und Programmierungen
werden am Entwicklungssystem vorgenommen und wandern über das Testsystem in die
Liveumgebung. Der Management Server bietet von Haus aus leider keine Mechanismen für
die Migration dieser Änderungen an, wie dies über Transportpakete im SAP-Umfeld
geboten wird. Die notwendigen Migrationsobjekte müssen je nach Projektanforderungen im
Vorfeld definiert werden. Unter anderem können betroffen sein:
 Contentklassen (inkl. Elemente und Templates)
 Workflows, Berechtigungspakete, Publizierungspakete
 CSS/JS Dateien (sofern nicht in den Contentklassen)
 Eingebundene Skripte (z.B. PHP) und Bibliotheken (z.B. DLLs)
 Plugins
 Assets/Dokumente
 Konfigurationsdateien vom Management Server und IIS
 Einstellungen im Betriebssystem (wie Datenquellen)
erminas GbR, Nadorster Str. 60, 26123 Oldenburg +49-(0)441/939 252 090 www.erminas.de
Seite 5

6. Die CSS/JS-Dateien, eingebundene Skripte/Bibliotheken, Plugins, Assets und
Konfigurationsdateien können meist einfach kopiert werden. Die
Betriebssystemeinstellungen lassen sich teilweise automatisiert, ansonsten auch manuell
übertragen. Die Contentklassen, Workflows und Pakete können manuell über Exporte und
manuelles Anlegen erstellt werden. Dies wird jedoch sehr aufwändig, wenn mehrere
Elemente betroffen sind, nur Teile von Änderungen übernommen werden sollen oder nicht
alle Änderungen bekannt sind. Ebenfalls ändert sich beim Import und der Neuanlage die
GUID (eindeutige Identifizierung der Elemente), was bestehende Verknüpfungen wie Seiten
zu Contentklassen und Vorbelegung von Contentklassen aufhebt. Diese Verbindungen
müssen anschließend zeitraubend manuell nachgepflegt werden.
Sinnvollerweise sollte daher für die Migration ein Werkzeug wie das CMS Sync Tool
verwendet werden, welches einen Vergleich von Contentklassen, Workflows und Paketen
ermöglicht. Hiermit kann garantiert werden, dass keine Änderung übersehen wird.
Änderungen können bidirektional in kleinstmöglichen Schritten (z.B. Zeilen oder
Elementattribute von Contentklassen) übernommen und ebenfalls in der Versionshistorie
nachverfolgt werden. Beliebig viele Änderungen können in einem Schritt zusammengefasst
werden. Durch Anpassung der Elemente statt einer Neuanlage bleiben die GUIDs und die
damit verbundenen Verknüpfungen und Vorbelegungen ebenfalls erhalten.
Der eigentliche Prozess läuft dann folgendermaßen ab:
Deaktivierung der Publizierung vom Zielsystem
Migration der externen Abhängigkeiten
Migration der Management Server Projekte
(z.B. mit CMS Sync Tool) und Assets
Test des Projekts im SmartEdit und Preview
Aktivierung der Publizierung vom Zielsystem
und ggfs. Testpublizierung
Vollpublizierung der Projekte
Prozess: Aktualisierung Produktionsumgebung
Eine gute Dokumentation für diesen Prozess ist in jedem Fall unabdingbar, insbesondere,
um auch neue Mitarbeiter schnell einarbeiten zu können. Eine Checkliste ist hierfür ein
bewährtes Mittel. Ebenfalls nützlich sind gemeinsame Dokumente bzw. Wiki-Seiten, in
denen spezielle Anforderungen für das Release, wie Änderungen am Betriebssystem oder
IIS, aufgeführt werden. Hierdurch verringert sich das Risiko, etwas zu vergessen, auf ein
Minimum.
erminas GbR, Nadorster Str. 60, 26123 Oldenburg +49-(0)441/939 252 090 www.erminas.de
Seite 6

7. 4 Aktualisierung der Entwicklungs- und
Testumgebung
Nach dem erfolgten Release sollten das Entwicklungs- und Testsystem aktualisiert werden,
damit diese genau dem Stand des Produktivsystems entsprechen. Dies vereinfacht die
weitere Entwicklung und ggf. die Fehlerbehebung am Produktivsystem. Die Aktualisierung
umfasst neben den Management Server Projekten auch die extern angebundenen Systeme
und Abhängigkeiten. Eine gute Dokumentation ist auch für diesen Schritt wichtig. Der
folgende Prozess eignet sich für die Aktualisierung der Management Server Projekte:
Publizierungsprozesse und Jobs abschalten
Leeren der Caches (u.a. Navigation und Page Cache)
Papierkorb leeren und ggf. nicht-verlinkter Seiten löschen
Ausschalten der RedDot Dienste auf allen Systemen
Export der Projektdatenbanken (inkl. Archiv) vom Produktivserver
und Import in Entwicklungs-/ Testsystem mittels Datenbanktools
Start der RedDot Dienste auf allen Systemen
Anpassung Publizierungsziele auf Entwicklung/Test
Entfernen der E-Mail Benachrichtigung aus den Workflows auf
Entwicklung/Test
Leeren der Caches auf Entwicklung/Test
Prozess: Aktualisierung Entwicklungsumgebung
Nach der erfolgten Migration sollte im SmartEdit getestet werden, ob die Seiten wie
gewünscht angezeigt und im Anschluss daran auch korrekt publiziert werden. Hierfür ist
eine Liste der Seiten nützlich, die spezielle Funktionalitäten, wie extern eingebundene
Systeme/Dateien, haben. Ebenfalls sollte zur Überprüfung der Datenbankverbindung
geprüft werden, ob Änderungen an den Seiten durchgeführt werden können und diese auch
richtig versioniert werden.
erminas GbR, Nadorster Str. 60, 26123 Oldenburg +49-(0)441/939 252 090 www.erminas.de
Seite 7

8. 5 Einsatz des Delivery Server
Beim Einsatz des Delivery Server sollte dieser ebenfalls in die Entwicklungsumgebung
miteinbezogen werden. Neben einer Aufteilung in drei getrennte Systeme ist, je nach
Nutzung des Delivery Server, auch denkbar, Entwicklung und Test gemeinsam auf einem
Server mit verschiedenen Projekten (z.B. Webseite_Dev und Webseite_Test) zu
kombinieren. Der Produktionsserver sollte aus Performance- und Sicherheitsgründen
jedoch separat bleiben. Die Migration von Änderungen lässt sich über Transportpakete
mittlerweile recht einfach durchführen. Je nach Nutzung des Delivery Server kann jedoch
schon eine Vollpublizierung mit Löschen der Caches ausreichend für die Migration sein.
6 Behandlung von CSS und JavaScript Dateien
CSS und JavaScript Dateien müssen häufig speziell behandelt werden. Es lassen sich drei
typische Szenarien differenzieren:
 Direkt im CMS: Die CSS und JavaScript Dateien liegen als Contentklassen im
Management Server vor und werden auch direkt als Seite eingebunden. In diesem
Fall ist keine spezielle Behandlung notwendig (aus Performancegründen sollte
diese Lösung jedoch vermieden werden).
 Direkt im CMS mit Dateisystempublizierung: Die CSS und JavaScript Dateien
liegen als Contentklassen vor, werden jedoch ins Dateisystem publiziert und von
dort als Dateien in die Seiten eingebunden. In diesem Fall muss nach der
Migration jeweils eine Publizierung ins Dateisystem vorgenommen werden.
 In Versionsverwaltung: Die CSS und JavaScript Dateien liegen in einer
Versionsverwaltung vor und werden von dort aus verteilt. In diesem Fall sollte der
zu transportierende Commit mit einem aussagekräftigen Tag gekennzeichnet
werden (z.B. Releasenummer) und in das Zielsystem exportiert oder von diesem
ausgecheckt werden.
7 Alternative Entwicklung mit Templatevarianten
Wenn die Projekte sehr einfach gehalten sind, keine externen Abhängigkeiten vorliegen
und nur Änderungen an den Templates durchgeführt werden, kann die Nutzung von
Templatevarianten eine Alternative sein. In diesem Fall werden Änderungen immer an einer
Templatevariante durchgeführt, die nicht live geschaltet ist.
Für die Einrichtung muss die Template- und Projektvariante angelegt werden, ebenso wie
die entsprechenden Publizierungsziele für die Entwicklungsvariante. Die Entwicklung findet
dann in der neuen Variante statt und zur Migration der Änderungen wird entweder die
Zuordnung Projekt-/Templatevariante angepasst oder das Template per Copy&Paste
übernommen. Zur Entwicklungszeit kann über die Benutzereinstellung die
erminas GbR, Nadorster Str. 60, 26123 Oldenburg +49-(0)441/939 252 090 www.erminas.de
Seite 8

9. Entwicklungsvariante als Standardanzeige genutzt werden, sodass im CMS direkt die
Entwicklung sichtbar ist.
Auch wenn diese Alternative nach einer Möglichkeit klingt, sich die weiteren Server zu
ersparen, so gibt es doch einige gravierende Nachteile. Änderungen und Entwicklungen
können nur an den Templates vorgenommen werden. Anpassungen an externen
Abhängigkeiten und weitere Änderungen im CMS wirken sich immer auf alle Nutzer des
Produktivsystems und ggf. auch auf die veröffentlichte Webseite aus. Inhaltsanpassungen
und das Anlegen neuer Seiten sind in der Regel nicht möglich, da die Webseite damit direkt
geändert werden würde. Nicht zu unterschätzen ist ebenfalls die Gefahr, versehentlich in
der falschen Templatevariante eine Änderung durchzuführen. Aus diesen Gründen ist im
Allgemeinen von dieser Entwicklungsvariante abzuraten.
8 Zusammenfassung
Die Nutzung einer zwei- oder dreistufigen Entwicklungsumgebung ist eine sinnvolle
Methode, die Entwicklung zu vereinfachen und Fehler in Produktivsystemen zu vermeiden.
In der Softwareentwicklung ist dies ein gängiges Vorgehen und bietet ebenfalls im
WebCMS-Umfeld große Vorteile. Auch wenn der Management Server keine vorgefertigte
Lösung anbietet, ist eine solche Umgebung jedoch relativ einfach einzurichten. Neben einer
guten Dokumentation des Prozesses ist der Einsatz von Werkzeugen, wie des CMS Sync
Tools, sehr empfehlenswert. Die höheren Lizenz- und Hardwareausgaben für die
Entwicklungs- und Testumgebung werden meist recht schnell durch verbesserte
Entwicklungsabläufe und zuverlässigere Webauftritte ausgeglichen.
erminas GbR, Nadorster Str. 60, 26123 Oldenburg +49-(0)441/939 252 090 www.erminas.de
Seite 9

10. Über erminas
erminas ist ein junges Oldenburger Unternehmen mit Wurzeln in der Region. Wir bieten
effiziente und bedienbare Software-Lösungen. Unsere Schwerpunkte sind Open Text Web
Solutions/RedDot-Lösungen und individuelle Softwareentwicklung im Bereich Web,
performancekritische Systeme und großen Datenmengen. Zusätzlich bieten wir
Schulungen, Projektmanagement nach GPM/IPMA und Agile Softwareentwicklung an.
Unsere Mitarbeiter sind bestens ausgebildet und Experten auf Ihren Gebieten. Für eine
fundierte Grundlage sorgt, neben Studium und Promotion, die Erfahrung in nationalen und
internationalen Projekten. Im Bereich der Webentwicklung sind unsere Kerntechnologien
Open Text Web Solutions (ehemals RedDot), ASP.NET (MVC) und Java/JEE.
Zu unseren Kunden gehören mehrere DAX und NASDAQ Unternehmen, sowie kleine und
mittlere Unternehmen aus der Region. Von der Projektmitarbeit bis zur eigenständigen
Umsetzung von Projekten decken wir ein breites Spektrum ab.
Wir möchten, dass Ihre Software bedienbar und effizient ist. Wenn Sie dies auch möchten:
 Rufen Sie uns an: 0441/939 252 090
 Schreiben Sie uns eine E-Mail: info@erminas.de
 Besuchen Sie uns: http://www.erminas.de
erminas GbR, Nadorster Str. 60, 26123 Oldenburg +49-(0)441/939 252 090 www.erminas.de
Seite 10