Staging

Samstag, 29. April 2006 22:40:47

Oups, jetzt hat man mich gerade übel erwischt. Der bereits erwähnte Admin, offensichtlich Typo3-Fan, hat mich ein wenig in Bedrängnis gebracht. Die neueste Typo3 Version würde "Staging" vernünftig unterstützen und ezpublish könne das nicht.

Ist mir etwas peinlich, aber ich wusste zunächst gar nicht genau, was er meint. OK, mittlerweile hab ichs verstanden, leider spuckte mir der Search-Engine auf ez.no nichts zu dem begriff "staging" aus und nun stehe ich auf dem Schlauch... wie siehts aus bei ezpublish damit?

Gibt es dazu irgendein Dokument irgendwo?

Danke!

Sonntag, 30. April 2006 12:42:12

Hi!

Sorry Tobias, staging ist leider nicht nur das Hochladen von HTML Seiten (http://en.wikipedia.org/wiki/Staging_%28websites%29).
Was machst du bei einem Forum? Hier kannst du mit dem Static Cache leider nichts anfangen.

Die Lösung liegt hier im Detail.
Zuerst einmal: echtes, vollintegriertes Staging gibt es bei eZ publish nicht.
Wenn man sich aber die Definition von Wikipedia anschaut, ist einem schnell klar, was das Ziel sein sollte: Vorschau,Test und Review von Inhalten vor der Publikation.

Hier gibt es mehrere denkbare Lösungsansätze, die abhängig von einigen Eckbedingungen einsetzbar wären.

Greifen wir zunächst die Idee von Tobias auf. Static Cache lässt sich sicherlich so einrichten, dass der Staging Server eine eZ publish Installation ist und der Produktiv Server nur HTML Seiten ausgibt. Per Cronjob/Script werden die StaticCache Seiten hochgeladen.
Das eignet sich besonders für rein statische, hoch frequentierte Seiten.

Handelt es sich um eine dynamische Seite, sollte man einige Features von eZ publish zum Einsatz bringen.
Sofern es einen definierten Publikationsprozess gibt, sollte man diesen in einem Workflow abbilden. z.B. Person A schreibt eine News, Person B liest Korrektur und publiziert.
Sowohl A als auch B können im Admininterface eine Live Preview bekommen und so den News sehen, wie er später angezeigt wird.
Bevor B aber nicht zur Publikation freigegeben hat sieht man im Frontend nichts.
Nachteil: Während der Bearbeitung sieht nur A den Artikel, Während der Freigabe nur Personen, die wie B in einer ganz bestimmten Benutzergruppe sind. Dort können aber alle Publizieren, was ja auch nicht immer gewünscht ist.

Sollten mehrere Personen vorschauen dürfen, kann man sich die "Verstecken" Funktion zur Hilfe nehmen. Im Admin Interface können alle den Artikel sehen und vorschauen. Nachteil: Jeder kann den Artikel sichtbar machen. Daher eigenet sich diese Variante eher nur für technisch Versierte.

Für Fortgeschrittene bleibt auch die Möglichkeit einen eigenen Preview Siteaccess einzurichten.

Fazit: Wichtig ist es die Anforderungen zu kennen, die an Staging gestellt werden. Was will der Kunde erreichen, wo liegen die Schwerpunkte. Dann kann man gemeinsam ein Konzept erarbeiten, das technisch machbar,einfach zu bedienen und zu verstehen ist, den Kunden zufrieden macht und funtioniert.

Bei einem Auto sagt man ja auch nicht: Dein Auto hat kein Vierradantrieb, deswegen kann man damit nichts anfangen und du solltest unbedingt zu einer anderen Marke wechseln. Dass man Vierradantrieb in der Großstadt nicht benötigt, wurde hier wohl nicht bedacht...

Sonntag, 30. April 2006 22:09:25

Hi, da haben wir wohl Potential für Verbesserungen entdeckt? Was sagt denn die Roadmap zu dem Thema?

Es geht im Prinzip um eine Vorschau der Site, wie diese nach Änderungen aussehen würde, wobei hier meistens nicht nur der Ersteller neuer Inhalte und ein "Freigeber" von Inhalten beteiligt sind, sondern oftmals auch Leute, die nur vor Veröffentlichung einen Blick drauf werfen sollen.

Eine einfache Umsetzung wäre eine Subdomain preview.example.com - diese sollte nicht öffentlich zugänglich sein, was leicht über eine htaccess-Datei erledigt werden kann.

Irgendein Knopf muss dann im Admin-Interface existieren, der die Änderungen der Preview-Site auf die Live-Site überträgt.

Zu beachten ist hier, dass sowas nicht auf Content-Objekt-Ebene passieren sollte, denn die Preview der Änderungen kann viele unterschiedliche Änderungen der Site beinhalten, also würde man sich auf Objekt-Ebene unter Umständen totklicken, um alle Neuerungen freizugeben.

Aus reinen HTML-Szenarien kann ich mir einfache Lösungen mit rsync vorstellen. Wahrscheinlich kann man auch zwei ezp-sites aufsetzen, wobei immer nur in einer die Änderungen durchgeführt werden und die zweite als live-site synchronisiert wird, naja, das gibt dann Probleme, wenn auf der Live-Site INSERTS exstieren... eine einfache Kopie der Preview-Site wäre also nicht die Lösung, es gehört ein wenig mehr dazu...

Wie genau wurde die Umsetzung mit "Preview Siteaccess" aussehen?

Übrigens vermisse ich beim Schreiben dieser Message drei Sachen: eine "Zitat"-Funktion und eine Ansicht dessen, was schon im Thread geschrieben wurde, um sich darauf beziehen zu können... und natürlich den "Preview-Button"!