FFF9EE66239D4D38AAC6E72728D17764
  • Thomas Pollinger
  • 19.02.2018
  • DE

Umstellung auf Asset Folder - Teil 1: Vorbereitungen

Am vergangen Wochenende haben wir auf der Usergroup Management Server Instanz, den Asset Manager auf den Asset Folder umgestellt. Dabei sind mir einige Dinge aufgefallen, welche man besser als Vorbereitung für die Umstellung durchführt.
 

Dokumente lesen

Es gibt verschiedene Dokumente, welche man sich vorher in Ruhe ansehen sollte. Dazu gehören:


Hinweis: Der neue Asset-Folder unterstützt derzeit noch keine Versionierung!


Überblick verschaffen

Als nächstes ist es hilfreich sich einen Überblick zu verschaffen, was denn der IST-Zustand im Projekt ist.

  • Welche Variante wird aktuell eingesetzt?
    • Asset Manager mit Datenhalten auf Festplatte.
    • Asset Manager mit Datenhalten auf Festplatte inkl. Versionierung.
    • Asset Manager mit Datenhaltung in Datenbank.
    • usw.
  • Welche Datenmengen liegen aktuell im Asset-Manager?
  • Ist genügend Plattenplatz auf dem Datenbanksystem, für die Konvertierung?
  • Liegen evtl. noch Assets auf der Platte, welche man zuvor bereinigen kann?
  • Habe ich ein Single- oder ein Master-/Child-Projektsetup?
  • Werde noch andere Ordnertypen verwendet, ausser Asset Manager?
  • Muss oder sollte ich ggfs. vorher auf den letzten Softwarestand updaten?
  • usw.

 

Einstellungen prüfen

Der neue Asset-Folder, genauso wie der neue Template-Editor, nutzen einen Webservice. Dieser hat auch einen Session-Timeout konfiguriert, welcher per Default auf 6 Minuten steht. Das führt leider zu unschönen Meldungen, wenn die restlichen Session-Timeouts größer eingestellt sind. Dies sollte zuvor angeglichen werden und wird im Artikel Gewusst wie! "Session-Timeout im Template-Editor oder AssetFolder?" beschrieben.

Weitere notwendige Einstellungen sind mir aktuell nicht bekannt. Falls jemand dennoch weitere kennt, die notwendig sind – bitte melden, gerne im Slack oder per Mail.

 

Vorbereitungen planen

Da man eine Asset Manager zu Asset Folder Konvertierung nicht ohne Datensicherung zurückrollen kann. Sollten gewissenhaft bestimmte Planungen durchgeführt werden.

  • Wann soll die Konvertierung durchgeführt werden?
  • Kann kurz vor Konvertierung ein komplettes Backup der Projekt-Datenbanken erstellt werden?
  • Habe ich im Falle eines Problems genügend Zeit für ein Rollback?
  • Welche Personen werden für die Konvertierung benötigt?
  • Müssen auf der physischen oder virtuellen Infrastruktur noch Erweiterungen durchgeführt werden?
  • Wieviele Projekte sind betroffen?
  • Liegen s.g. Master-/Child-Projekte vor, welche zeitgleich umgestellt werden oder handelt es sich nur um Einzel-Projekte?
  • und sicherlich noch weitere Punkte, anhängig der Umgebung und Infrastruktur.

 

Empfehlungen

Aus meiner heutigen Sicht sind die folgenden Punkte hilfreich und teilweise sogar notwendig:

  • Publizierung für die betroffenen Projekte über eine Projektsperrung unterbinden.
  • Alle Anwender sollten vom Management Server abgemeldet sein.
  • Datensicherungen durchführen, ggfs. sogar einen Projektexport.
  • Sicherstellung der notwendigen Kapazitäten auf dem DB-Server.
  • Alle notwendigen Zugriffsrechten vorhalten, egal ob selbst oder durch Dritte.
  • Am besten außerhalb von den Kernarbeitenszeiten die Konvertierung durchführen.
  • ggfs. die Assets, bei Datenhaltung auf Platte, auch nochmals sichern.

 

Wenn man das alles so liest, könnte man meinen es ist eine aufwändige Angelegenheit. Dem ist aber nicht so, denn die eigentliche Konvertierung ist automatisch. Das einzige was man haben sollte, ist Geduld, genug Kaffee und Zeit.

Jedoch sollte man auf mögliche auftretende Probleme gut vorbereitet sein. Denn es ist gibt nichts unschöneres, als wenn z.B. bei der Konvertierung der Plattenplatz auf dem Datenbank-System vollläuft, ein zu alter Softwarestand installiert ist oder man nicht die notwendigen Berechtigungen seitens der IT hat.

Damit die Konvertierung ein gemütlicher Spaziergang wird, sollte man sich einfach gut vorbereiten. Und mögliche Szenarien durchdenken, noch offene Punkte klären und wenn mögich mit einem anderen Test-Projekt die Konverterung zuvor durchspielen.

Denn jede Installation, Umgebung und Projektstruktur hat ihre Eigenarten, welche ggfs. zu Problemen führen können. Doch das ist kein reines Management Server Problem, sondern findet man überall in der IT wieder.

Wie man nun die Konvertierung durchführt, welche nachgelagerten Schritte notwendig sind und was man dann noch alles optimieren kann – folgt im nächsten Artikel, mit dem Titel: Umstellung auf Asset Folder - Teil 2: Konvertierung. ;)


Über den Autor:
Thomas Pollinger

... ist Senior Site Reliability Engineer bei der Vodafone GmbH in Düsseldorf. Seit dem Jahr 2007 betreut er zusammen mit seinen Kollegen die OpenText- (vormals RedDot-) Plattform Web Site Management für die deutsche Konzernzentrale.

Er entwickelt Erweiterungen in Form von Plug-Ins und PowerShell Skripten. Seit den Anfängen in 2001 (RedDot CMS 4.0) kennt er sich speziell mit der Arbeitweise und den Funktionen des Management Server aus.