[Typo3-german] Staging System in Typo3

[Michael Scharkow]

christian reiter wrote:
> Hmm, diese Argumente würde ich jetzt mal nicht so lächerlich machen.
> "Schlipsträger" leben oft mit IT-Vorgaben, an die sie sich halten. Wenn die
> global lauten, immer Live und Testserver trennen, will Typo3 dann gar nicht
> mehr mitspielen, weil das "Schlipsträgerei" ist, oder will man die
> Anforderung erfüllen, ohne den Kunden erst in ein Umerziehungslager zu
> schicken?

Hi Christian,

endlich mal einer, der mitspielt :)

1. Die von Dir genannten IT-Vorgaben fallen nicht vom Himmel und 
können/müssen daher von technisch kompetenten Leuten hinterfragt werden. 
Dass die Entscheider davon nicht immer Ahnung haben müssen, ist doch 
ganz natürlich.

2. TYPO3 ist kein Allheilmittel für jedes Problem. Wenn die Anforderung 
"Live- und Testserver" lautet (wobei mit Testserver in unserem Fall ja 
*keine* Entwicklungsumgebung gemeint ist, sondern der Server, auf dem 
alle Inhalte erstellt werden) und nicht debattierbar ist, dann halt ich 
es für grob fahrlässig, ersteinmal reflexartig "geht natürlich" zu sagen 
und nachher hier in den Listen nach Lösungen zu fragen.

3. Wenn eine Anforderung kommt, die mit Budget X nicht zu lösen ist, 
dann ist es weder herablassend noch besserwisserisch, dem Kunden zu 
sagen, dass TYPO3 das nicht kann. Wenn z.B. jemand ein Portal haben 
will, in dem sämtliche Inhalte von FE-Usern erstellt werden sollen, dann 
kann ich ihm nicht guten Gewissens zu TYPO3 raten.

> Was ist denn zB mit einem Kunden, der sämtliche Entwicklungsoberflächen und
> noch nicht freigegebenen Seiten per definition nur auf Servern erlaubt, die
> die Seiten per SSL und per Firewall auf bestimmte IPs beschränkt ausliefern
> (gibt es)?

Kein Problem: BE nur für IP-Range X und per SSL freigeben, ob mit oder 
ohne Paketfilter.

> Oder was ist, bezüglich Konflikte durch BE/FE Nutzung, zu einem durchaus
> relevanten Problem zu sagen: Es ist nämlich wneiger das Problem, dass das
> Herumklicken im BE so wahnsinnig viele Ressourcen braucht, sondern dass bei
> gewissen Änderungen - zB experimentieren mit einer neuen Navigationsstruktur
> etc- es schnell passiert dass mal der ganze FE Cache gelöscht wird - was
> dann u.U die FE User mit gähnend langsamem Seitenaufbau oder Page is being
> generated belohnt.

Workspaces, auf *einem* Server

> Genauso gilt es dass man auch einmal neue Extensions zusammen mit dem Kunden
> evaluieren will, am Rendering etwas ändern will etc und das will der Kunde
> evtl. nicht sofort auf dem Liveserver sehen? Weil es ja gelegentlich auch
> unerwünschte Effekte geben mag.

Testsystem auf eigenem Server, ggf. mit Daten aus dem Produktionssystem 
füttern. Hat aber nichts mit Staging zu tun.

> Und, was ist mit der Möglichkeit, nicht nur tt_content und andere
> datenbankgestützte Elemente zu einer Überarbeitung vom Liveserver
> rückzurufen, sondern auch die dazugehörigen PDFs, Bilder etc. Sei nun der
> Kunde wegen einer solchen seite incl PDFs und Grafiken in
> Überarbeitungsnotstand gekommen (zB Abmahnung eines Konkurrenten), so soll
> natürlich auf keinen Fall dieses Material weiter auf dem Liveserver
> erreichbar sein (sonst Kohle abdrücken...), andererseits muss die
> Rechtsabteilung der Schlipsträger natürlich auf dem Testserver das
> beanstandete Material sehen können um mit der Bearbeitung fortzukommen. Das
> hebt hervor, wie wertvoll es sein kann, zwei völlig getrennte fileadmin
> Hierarchien für Live und Testserver zu haben, damit Dateien, die es live
> nicht mehr geben soll, dort auch wirklich ausgemerzt werden können.

Ja, das ist mal ein überzeugendes Argument. Abhängig von der Menge der 
Daten kann man natürlich die Seiten auch einfach verstecken und die 
Dateien aus dem Webspace nehmen, aber das ist zugegebenermaßen hässlich.

Vermutlich ist es aber immer noch leichter, Workspaces dahingehend zu 
hacken, statische Dateien aus deaktivierten Workspaces aus dem Webspace 
zu nehmen oder per .htaccess zu schützen, als ein echtes 
Mehr-Server-Staging (mit Rückruf und Transaktionen) zu implementieren.

> (im übrigen braucht es dabei natürlich nicht unbedingt gleich immer 'Zwei
> teure Webserver ' denn es kann ja auch auf einer Maschine laufen, aber mit 2
> DB´s und 2 Virtual Hosts. Im übrigen haben manche der sehr konservativen
> "Schlipsträger" Kunden erstaunlich alte und schwache Webserver weil die
> Zyklen für Neuanschaffungen sich deutlich verlängert haben. Da ist zT noch
> 400 Mhz Ultrasparc Kit unterwegs.)

Ich meinte auch gar nicht unbedingt getrennte Server, sondern nur 
getrennte Installationen (mit eigenem Filesystem und DB).

> Aus meiner Sicht sollte man sich über Leute, die solche Kundenanforderungen
> gerne erfüllen mögen, nicht einfach nur lustig machen.

Über Leute, die *zusagen*, solche Kundenanforderungen zu erfüllen, es 
dann aber nicht können, darf man sich doch durchaus lustig machen, oder?

> Klar kann man auch sagen - Dafür ist Typo3 nicht das richtige Tool, nimm
> etwas anderes, eben $kommerzielleKonkurrenz mit JSR 1239943 Compliance. Das
> macht aber das Pitchen nicht leichter, und ich sehe nicht warum man sich
> ideologisch darauf versteifen sollte, den  Wunsch so etwas umsetzen zu
> können zu verketzern.

Wie ich oben schon schrieb: Das ist keine ideologische, sondern ein 
hochgradig pragmatische Entscheidung. Wenn man das Problem nicht lösen 
kann, muss man entweder den Kunden überzeugen, dass die Vorgaben nicht 
sinnvoll sind, oder man muss eben ein Tool nehmen, dass die Vorgaben 
erfüllt.

Die Tatsache, dass wir nach so vielen Jahren und unzähligen Versuchen 
immer noch kein zuverlässiges und komfortables Staging haben, mag ein 
Indiz dafür sein, dass das Problem nicht so einfach zu lösen ist, 
und/oder dass nicht so starker Bedarf auf Kundenseite bestand, der sich 
in entsprechendem Sponsoring niederschlagen würde.

Viele Grüße,
Michael