Entwicklungsumgebung  für den Open Text Management Server (früher RedDot CMS)
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

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

  • 511 views
Uploaded on

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......

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
511
On Slideshare
511
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
1
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Entwicklungsumgebung für den Open Text Management Server (früher RedDot CMS) Umsetzung einer Umgebung für Entwicklung/Test/ProduktionJuli 2012Autor: Hilmar Bunjes (hilmar.bunjes@erminas.de)Version: 1.0
  • 2. AbstractNach dem initialen Rollout eines Projekts im Management Server / Delivery Server Umfeld(früher RedDot CMS und LiveServer) müssen Änderungen am System sorgsam geplantwerden. Da es sich in der Regel um ständig verfügbare Webseiten handelt, könnenAuszeiten, Inkonsistenzen und mögliche Fehler nicht akzeptiert werden. Ebenfalls müssenfertige Entwicklungen häufig durch die Marketing- oder Rechtsabteilung freigegebenwerden, bevor sie der Öffentlichkeit präsentiert werden dürfen. In der Softwareentwicklungwerden für solche Anforderungen getrennte Entwicklungs- und Produktivsysteme genutzt.Dies lässt sich auch im Management Server / Delivery Server Umfeld umsetzen. Einbewä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. Inhalt1 VORTEILE EINER MEHRSTUFIGEN ENTWICKLUNGSUMGEBUNG 42 AUFBAU UMGEBUNG MIT DEM MANAGEMENT SERVER 43 VON DER ENTWICKLUNG ZUM PRODUKTIVSYSTEM 54 AKTUALISIERUNG DER ENTWICKLUNGS- UND TESTUMGEBUNG 75 EINSATZ DES DELIVERY SERVER 86 BEHANDLUNG VON CSS UND JAVASCRIPT DATEIEN 87 ALTERNATIVE ENTWICKLUNG MIT TEMPLATEVARIANTEN 88 ZUSAMMENFASSUNG 9erminas GbR, Nadorster Str. 60, 26123 Oldenburg +49-(0)441/939 252 090 www.erminas.de Seite 3
  • 4. 1 Vorteile einer mehrstufigen EntwicklungsumgebungOhne mehrstufige Entwicklungsumgebungen müssen Änderungen direkt imProduktivsystem umgesetzt werden. Dies führt schnell zu Auszeiten, Inkonsistenzen undFehlern im Webauftritt und damit zu einer Beschädigung der öffentlichen Wahrnehmung.Mehrstufige Entwicklungsumgebungen entkoppeln die Entwicklung, das Testen und denProduktivbetrieb. Entwicklung und Testen finden dennoch in einer Umgebung statt, die derProduktivumgebung gleicht oder zumindest ausreichend ähnelt. Es lässt sich zurEntwicklungszeit bereits das spätere Systemverhalten nachvollziehen.Eine solche Umgebung besteht aus mindestens zwei (Entwicklung und Produktion) oderdrei (Entwicklung, Test und Produktion) Umgebungen, die nach Möglichkeit identischaufgebaut sind. Auf die abgeschlossene Entwicklung folgt die Migration in dieTestumgebung. Nach der erfolgten Abnahme wird in die Produktionsumgebung migriert.Der prinzipielle Aufbau sieht wie folgt aus: Entwicklung Test ProduktionDurch ein solches Vorgehen können Entwickler unabhängig von der live geschaltetenWebseite Änderungen vornehmen, ohne die publizierten Seiten negativ zu beeinflussen.Größere Änderungen lassen sich problemlos entwickeln und danach testen, bevor sieonline gestellt werden.Es muss ein Prozess definiert werden, wie Änderungen hin zum Produktionssystemübernommen werden können. Ebenfalls muss die Rückrichtung behandelt werden, damitdie Entwicklung und der Test möglichst ähnlich der Produktionsumgebung sind. DirekteÄnderungen am Produktionssystem werden bei diesem Vorgehen in der Regel nichtdurchgeführt (außer bei zeitkritischen Problemen).2 Aufbau Umgebung mit dem Management ServerEin Management Server ohne weitere externe Systeme benötigt einen Windows Server undeinen SQL Server bzw. Oracle Datenbankserver. Generell sollten der Windows Server underminas 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- oderRessourcengrü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, obdie Performance der Systeme dann noch akzeptabel ist.In vielen Projekten werden zusätzlich zum Management Server externe Systeme undAbhängigkeiten wie Dokumenten-/Assetmanagement, versionsverwaltete Dateien undeingebundene Inhalte verwendet. Hierbei muss im Einzelfall entschieden werden, ob auchfür diese eine Aufteilung in separate Entwicklungs- und Testsysteme sinnvoll undnotwendig ist und welche Kosten dadurch entstehen. Wenn die externen AbhängigkeitenTeil des Entwicklungsprozesses sind, ist eine Aufteilung unumgänglich.Neben dem Aufbau der Umgebung müssen zwei Prozesse definiert werden: Die Migrationvon Änderungen in Richtung Produktivsystem und das Update der Entwicklungs- undTestsysteme. Diese Prozesse werden in den folgenden zwei Kapiteln beschrieben.3 Von der Entwicklung zum ProduktivsystemDer Prozess von der Entwicklung zum Produktivsystem erfolgt in Release-Zyklen. In einemZyklus werden alle Änderungen, die übertragen werden sollen, gesammelt und dann ineinem 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). ZurVereinfachung der Migration sollte sichergestellt sein, dass zum Zeitpunkt des Releaseskeine Entwicklungsarbeiten an zu migrierenden Änderungen mehr unfertig vorliegen.Änderungen an Templates, Servereinstellungen, CSS/JS-Dateien und Programmierungenwerden am Entwicklungssystem vorgenommen und wandern über das Testsystem in dieLiveumgebung. Der Management Server bietet von Haus aus leider keine Mechanismen fürdie Migration dieser Änderungen an, wie dies über Transportpakete im SAP-Umfeldgeboten wird. Die notwendigen Migrationsobjekte müssen je nach Projektanforderungen imVorfeld 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 undKonfigurationsdateien können meist einfach kopiert werden. DieBetriebssystemeinstellungen lassen sich teilweise automatisiert, ansonsten auch manuellübertragen. Die Contentklassen, Workflows und Pakete können manuell über Exporte undmanuelles Anlegen erstellt werden. Dies wird jedoch sehr aufwändig, wenn mehrereElemente betroffen sind, nur Teile von Änderungen übernommen werden sollen oder nichtalle Änderungen bekannt sind. Ebenfalls ändert sich beim Import und der Neuanlage dieGUID (eindeutige Identifizierung der Elemente), was bestehende Verknüpfungen wie Seitenzu Contentklassen und Vorbelegung von Contentklassen aufhebt. Diese Verbindungenmüssen anschließend zeitraubend manuell nachgepflegt werden.Sinnvollerweise sollte daher für die Migration ein Werkzeug wie das CMS Sync Toolverwendet werden, welches einen Vergleich von Contentklassen, Workflows und Paketenermöglicht. Hiermit kann garantiert werden, dass keine Änderung übersehen wird.Änderungen können bidirektional in kleinstmöglichen Schritten (z.B. Zeilen oderElementattribute von Contentklassen) übernommen und ebenfalls in der Versionshistorienachverfolgt werden. Beliebig viele Änderungen können in einem Schritt zusammengefasstwerden. Durch Anpassung der Elemente statt einer Neuanlage bleiben die GUIDs und diedamit 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 ProduktionsumgebungEine 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 einbewährtes Mittel. Ebenfalls nützlich sind gemeinsame Dokumente bzw. Wiki-Seiten, indenen spezielle Anforderungen für das Release, wie Änderungen am Betriebssystem oderIIS, aufgeführt werden. Hierdurch verringert sich das Risiko, etwas zu vergessen, auf einMinimum.erminas GbR, Nadorster Str. 60, 26123 Oldenburg +49-(0)441/939 252 090 www.erminas.de Seite 6
  • 7. 4 Aktualisierung der Entwicklungs- und TestumgebungNach dem erfolgten Release sollten das Entwicklungs- und Testsystem aktualisiert werden,damit diese genau dem Stand des Produktivsystems entsprechen. Dies vereinfacht dieweitere Entwicklung und ggf. die Fehlerbehebung am Produktivsystem. Die Aktualisierungumfasst neben den Management Server Projekten auch die extern angebundenen Systemeund Abhängigkeiten. Eine gute Dokumentation ist auch für diesen Schritt wichtig. Derfolgende 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 EntwicklungsumgebungNach der erfolgten Migration sollte im SmartEdit getestet werden, ob die Seiten wiegewünscht angezeigt und im Anschluss daran auch korrekt publiziert werden. Hierfür isteine Liste der Seiten nützlich, die spezielle Funktionalitäten, wie extern eingebundeneSysteme/Dateien, haben. Ebenfalls sollte zur Überprüfung der Datenbankverbindunggeprüft werden, ob Änderungen an den Seiten durchgeführt werden können und diese auchrichtig 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 ServerBeim Einsatz des Delivery Server sollte dieser ebenfalls in die Entwicklungsumgebungmiteinbezogen werden. Neben einer Aufteilung in drei getrennte Systeme ist, je nachNutzung des Delivery Server, auch denkbar, Entwicklung und Test gemeinsam auf einemServer mit verschiedenen Projekten (z.B. Webseite_Dev und Webseite_Test) zukombinieren. Der Produktionsserver sollte aus Performance- und Sicherheitsgründenjedoch separat bleiben. Die Migration von Änderungen lässt sich über Transportpaketemittlerweile recht einfach durchführen. Je nach Nutzung des Delivery Server kann jedochschon eine Vollpublizierung mit Löschen der Caches ausreichend für die Migration sein.6 Behandlung von CSS und JavaScript DateienCSS und JavaScript Dateien müssen häufig speziell behandelt werden. Es lassen sich dreitypische 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 TemplatevariantenWenn die Projekte sehr einfach gehalten sind, keine externen Abhängigkeiten vorliegenund nur Änderungen an den Templates durchgeführt werden, kann die Nutzung vonTemplatevarianten eine Alternative sein. In diesem Fall werden Änderungen immer an einerTemplatevariante durchgeführt, die nicht live geschaltet ist.Für die Einrichtung muss die Template- und Projektvariante angelegt werden, ebenso wiedie entsprechenden Publizierungsziele für die Entwicklungsvariante. Die Entwicklung findetdann in der neuen Variante statt und zur Migration der Änderungen wird entweder dieZuordnung Projekt-/Templatevariante angepasst oder das Template per Copy&Pasteübernommen. Zur Entwicklungszeit kann über die Benutzereinstellung dieerminas 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 dieEntwicklung sichtbar ist.Auch wenn diese Alternative nach einer Möglichkeit klingt, sich die weiteren Server zuersparen, so gibt es doch einige gravierende Nachteile. Änderungen und Entwicklungenkönnen nur an den Templates vorgenommen werden. Anpassungen an externenAbhängigkeiten und weitere Änderungen im CMS wirken sich immer auf alle Nutzer desProduktivsystems und ggf. auch auf die veröffentlichte Webseite aus. Inhaltsanpassungenund das Anlegen neuer Seiten sind in der Regel nicht möglich, da die Webseite damit direktgeändert werden würde. Nicht zu unterschätzen ist ebenfalls die Gefahr, versehentlich inder falschen Templatevariante eine Änderung durchzuführen. Aus diesen Gründen ist imAllgemeinen von dieser Entwicklungsvariante abzuraten.8 ZusammenfassungDie Nutzung einer zwei- oder dreistufigen Entwicklungsumgebung ist eine sinnvolleMethode, die Entwicklung zu vereinfachen und Fehler in Produktivsystemen zu vermeiden.In der Softwareentwicklung ist dies ein gängiges Vorgehen und bietet ebenfalls imWebCMS-Umfeld große Vorteile. Auch wenn der Management Server keine vorgefertigteLösung anbietet, ist eine solche Umgebung jedoch relativ einfach einzurichten. Neben einerguten Dokumentation des Prozesses ist der Einsatz von Werkzeugen, wie des CMS SyncTools, sehr empfehlenswert. Die höheren Lizenz- und Hardwareausgaben für dieEntwicklungs- und Testumgebung werden meist recht schnell durch verbesserteEntwicklungsablä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 erminaserminas ist ein junges Oldenburger Unternehmen mit Wurzeln in der Region. Wir bieteneffiziente und bedienbare Software-Lösungen. Unsere Schwerpunkte sind Open Text WebSolutions/RedDot-Lösungen und individuelle Softwareentwicklung im Bereich Web,performancekritische Systeme und großen Datenmengen. Zusätzlich bieten wirSchulungen, Projektmanagement nach GPM/IPMA und Agile Softwareentwicklung an.Unsere Mitarbeiter sind bestens ausgebildet und Experten auf Ihren Gebieten. Für einefundierte Grundlage sorgt, neben Studium und Promotion, die Erfahrung in nationalen undinternationalen Projekten. Im Bereich der Webentwicklung sind unsere KerntechnologienOpen Text Web Solutions (ehemals RedDot), ASP.NET (MVC) und Java/JEE.Zu unseren Kunden gehören mehrere DAX und NASDAQ Unternehmen, sowie kleine undmittlere Unternehmen aus der Region. Von der Projektmitarbeit bis zur eigenständigenUmsetzung 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.deerminas GbR, Nadorster Str. 60, 26123 Oldenburg +49-(0)441/939 252 090 www.erminas.de Seite 10