nikosch

Ein CVS kann das sicher auch leisten. Problematisch sind immer Daten wie Bilder, CSS etc. Hier ist eine gute Dateistruktur vonnöten, um die nicht in der neuen Version doppelt vorhalten zu müssen.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Mister Ad

vollkommenegal

Es ist schon so, wie Asipak es schrieb: Mit "neuer Prozess" meinte ich das Starten eines Skriptes mit einem Formular, um neue Daten einzugeben bzw. Daten zu ändern.
Dieser Prozess endet, sobald das Formular abgeschickt und die Daten in die DB geschrieben wurden.

Was "diese Aktionen voneinander unterscheidet" ist das bereits von mir erwähnte $_POST, das beim Absenden eines Formulars mit Daten gefüllt ist.

Das Update-Verfahren auf der Dateiebene ist dahingehend suboptimal, weil es (wie nikosch schon schrieb) nicht nur um die Skript-Dateien geht. Täglich werden zahlreiche PDFs erzeugt, die in der zweiten Dateistruktur mitkopiert werden müssten.

Allein dieses Kopieren würde mehrere Minuten dauern und dürfte erst gestartet werden, wenn wiederum alle User die Finger von der Tastatur nehmen würde.
(Aber die Idee an sich ist super. Hätten wir damals beim Erstellen der Datei-Ebene berücksichtigen müssen... *hmpf*)

cya

agrajag

Klar CVS, SVN oder irgendeine Versionsverwaltung ist sowieso Pflicht. Capistrano tut letztilch nichts anderes als dein Repository auschecken, Dateien hochladen und immer wiederkehrende Aufgaben automatisieren.

Daten die nicht in der Versionsverwaltung sind (beispielsweise irgendwelche Uploads/Bilder von Usern oder riesige PDFs) müssen eben auch "reingesymlinkt" werden. Heißt: Ich lege irgendwo ein /shared-Verzeichnis an, dort rein kommt der ganze Kram der bei jeder Version gleich ist. Wenn ich bspw. ein Verzeichnis /upload habe wo Benutzer ihre Dateien hochladen können lege ich /shared/upload an. Immer wenn ich jetzt eine neue Version deploye muss ich am Ande nur innerhalb des neuen /release/version-xyz/ einen Symlink "upload" anlegen der auf dieses shard/upload zeigt.
Klingt erstmal umständlich - aber das machst du ja nicht händisch sondern automatisiert.

__________________
Today you...Tomorrow me.

bionickid

ergänz kurz for dem update die serverseitige form validierung durch eine "update läuft" meldung. dadurch bleiben die form-daten erhalten.
update ausführen validierung wieder rausnehmen.

systemunabhängige daten auf jeden fall in ein content od. shared verzeichnis.

nikosch

Das ist aber ein Denkfehler. Deswegen habe ich gefragt: Ein Formularaufruf ist erstmal nur ein GET-Request. Und, Ein Formularaufruf ist auch noch gar kein Zeichen, ob auch wirklich Daten eingegeben werden, sprich, ob ein aktiver Prozess geschieht. Du hast also gar keine Kontrolle darüber, ob da jemand arbeitet oder sich derjenige standardmässig das Form aufruft und gerade beim Mittagessen ist. HTTP bietet weder Zustände noch periodische Kontrolle von Seiten, es ist ein reines Abfrage-Antwort-Protokoll.
Zudem ist das auch vollkommen wurscht, solange die Formularaction sowieso über den Frontcontroller läuft, kannst Du ohnehin nur alles oder nichts ändern.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Chriz

Ich habe schändlicherweise nur den Anfangspost gelesen ..

Wir machen das bei Upgrades so, dass wir natürlich alle per Messaging-System informieren, d.h. bei einem neuen Request bekommt der Benutzer sofort einen Hinweis auf die Nachricht, außerdem gehen Mails raus. Wir haben da allerdings eine gewisse Vorwarnzeit.

Vor dem Upgrade werden alle User (außer uns Admins) gebannt, d.h. wenn jemand trotzdem weiterarbeitet, wird er beim nächsten Request ausgeloggt - ABER - ausloggen heißt bei uns nur, dass sich das Controller-Plugin meldet, sprich es gibt keine Weiterleitung, sondern statt dem eigentlichen Inhalt wird der Login angezeigt. Die Idee war einmal bei uns - und das könntest du dir überlegen - einen Post-Request im ausgeloggten Zustand zu speichern (serialize($_POST) und ab in die Session damit). Loggt sich der Benutzer nun mit der selben Session erfolgreich ein - wenn also unser Upgrade erfolgreich war und kein Benutzer mehr gebannt ist - könnte man in der Session (bleibt ja die selbe, ist halt nur "eingeloggt") diesen serialisierten $_POST auslesen an eine entsprechende HttpRequest-Klasse (cURL, Zend_Controller_Request_Http, ..) übergeben und die Anfrage erneut abschicken. Da die URL ja dank des Controller-Plugins die selbe geblieben ist, sollte es möglich sein, die Arbeit wie gewohnt fortzufahren. Natürlich musst du beim Wegsichern des $_POST-Array unterscheiden, ob es nun ein erneuter erfolgloser Login-Request war, oder eben der initial gescheiterte.

Wir haben die Idee verworfen, weil eigentlich keiner mehr arbeiten sollte, wenn wir es groß vorher angekündigt hatten, außerdem könnte damit die Session zugemüllt werden.

Tut mir Leid, falls dir das schon vorgeschlagen wurde, ich hatte einfach keine Lust drei Seiten nachzulesen

__________________
"Nuschel ich?" - "Was?"

vollkommenegal

Danke, Chriz, für Deine Ausführungen.

Nee, ist schon okay. Was ich allerdings witzig finde: Du beschreibst über mehrere Zeilen einen interessanten Prozess und als Abschluss dann "Wir haben die Idee verworfen,..."

cya