Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Entwicklungsumgebung
              für den Open Text
            Management Server
            (früher RedDot CMS)
       ...
Abstract
Nach dem initialen Rollout eines Projekts im Management Server / Delivery Server Umfeld
(früher RedDot CMS und Li...
Inhalt
1      VORTEILE EINER MEHRSTUFIGEN ENTWICKLUNGSUMGEBUNG                            4
2      AUFBAU UMGEBUNG MIT DEM...
1 Vorteile einer mehrstufigen
  Entwicklungsumgebung
Ohne mehrstufige Entwicklungsumgebungen müssen Änderungen direkt im
P...
der Datenbankserver auf zwei getrennten Maschinen laufen. Sofern dies aus Lizenz- oder
Ressourcengründen nicht für die Ent...
Die CSS/JS-Dateien, eingebundene Skripte/Bibliotheken, Plugins, Assets und
Konfigurationsdateien     können      meist    ...
4 Aktualisierung der Entwicklungs- und
  Testumgebung
Nach dem erfolgten Release sollten das Entwicklungs- und Testsystem ...
5 Einsatz des Delivery Server
Beim Einsatz des Delivery Server sollte dieser ebenfalls in die Entwicklungsumgebung
miteinb...
Entwicklungsvariante als Standardanzeige genutzt werden, sodass im CMS direkt die
Entwicklung sichtbar ist.


Auch wenn di...
Über erminas
erminas ist ein junges Oldenburger Unternehmen mit Wurzeln in der Region. Wir bieten
effiziente und bedienbar...
You’ve finished this document.
Download and read it offline.
Upcoming SlideShare
Pink Panter
Next
Upcoming SlideShare
Pink Panter
Next
Download to read offline and view in fullscreen.

1

Share

Entwicklungsumgebung für den Open Text Management Server (früher RedDot CMS)

Download to read offline

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.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Entwicklungsumgebung für den Open Text Management Server (früher RedDot CMS)

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  • hbunjes

    Mar. 2, 2013

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.

Views

Total views

937

On Slideshare

0

From embeds

0

Number of embeds

4

Actions

Downloads

3

Shares

0

Comments

0

Likes

1

×