[Typo3-german] Staging System in Typo3

christian reiter cr at n-o-s-p-a-m-cxd.de
Tue Dec 13 21:20:01 CET 2005


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?

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)?

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.

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.

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.

Usw.

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

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

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.

Grüsse,

Christian Reiter

> Aber wo wir gerade dabei sind: Warum will man das haben?
>
> [ ] Schlipsträger haben das entschieden, weil $kommerzielleKonkurrenz
> das auch kann.
>
> [ ] Ist in JSR 1239943 definiert  und in der letzten ix-Sonderausgabe
> als zentrales Merkmal für B2E und B2B-ECMS-Systeme genannt worden
>
> [ ] Zwei teure Webserver müssen ja auch genutzt werden.
>
> [ ] ???
>





More information about the TYPO3-german mailing list