Autoupdate: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
| Zeile 1: | Zeile 1: | ||
// Verwirklichtes Konzept: | // Verwirklichtes Konzept: | ||
// | // | ||
| Zeile 42: | Zeile 10: | ||
// post_event 'PLEASE_DISCONNECT'; | // post_event 'PLEASE_DISCONNECT'; | ||
// * auch einen event 'PLEASE_DOWN' schaffen, der den Applikationen signalisiert, | // * auch einen event 'PLEASE_DOWN' schaffen, der den Applikationen signalisiert, | ||
// das in wenigen Minuten heruntergefahren werden muss. z.B. | // das in wenigen Minuten heruntergefahren werden muss. z.B. K?e so ein XMLRPC | ||
// Server keine neuen Verbindungen mehr annehmen! '9998' | // Server keine neuen Verbindungen mehr annehmen! '9998' | ||
// * OrgaMon sollte dem Benutzer die Aufforderung zum Beenden anzeigen | // * OrgaMon sollte dem Benutzer die Aufforderung zum Beenden anzeigen | ||
// * Update-Prozess von Orgamon: OrgaMon schreibt Batch, ruft den batch auf, beendet | // * Update-Prozess von Orgamon: OrgaMon schreibt Batch, ruft den batch auf, beendet | ||
// sich selbst. Der batch ruft sleep, um sicherzustellen das OrgaMon beendet ist. | // sich selbst. Der batch ruft sleep, um sicherzustellen das OrgaMon beendet ist. | ||
// Danach das Setup, dieses | // Danach das Setup, dieses ?hreibt den exe, ruft diesem im Anschluss auf! | ||
// * Eine neue ftp/web-"Update?" Aktion sollte nachsehen | // * Eine neue ftp/web-"Update?" Aktion sollte nachsehen k?n, ob Updates vorliegen! | ||
// | // spä´¥stens bei Tagesabschluss sollte das gemacht werden! | ||
// * Ein Updateadmin sollte das downgeloadete Update | // * Ein Updateadmin sollte das downgeloadete Update f?e freischalten k?n. | ||
// * Szenario | // * Szenario ?gen: Wie kann der Updateadmin ein "m?risches" Update wieder | ||
// entfernen will, er will sicherstellen dass alle wieder auf die alte Version | // entfernen will, er will sicherstellen dass alle wieder auf die alte Version | ||
// | // zur?en, das autoupdate verhindern! OrgaMon darf nicht mehr "nerfen" das | ||
// eine neue Version vorliegt. Der Admin soll einfach "unstable" Revisions | // eine neue Version vorliegt. Der Admin soll einfach "unstable" Revisions | ||
// markieren | // markieren k?n. Beim Start sollten "zu neue" Orgamons eine Warnmeldung ausgeben | ||
// bzw. gleich die richtige Version | // bzw. gleich die richtige Version dr?stallieren (Programmversion>Datenbank- | ||
// Version/empfohlene Version) | // Version/empfohlene Version) | ||
// * Ein Updateadmin sollte das fertig downgeloadete Update signalisiert bekommen | // * Ein Updateadmin sollte das fertig downgeloadete Update signalisiert bekommen | ||
// er gibt diese Version frei oder nicht. | // er gibt diese Version frei oder nicht. | ||
// * | // * W䨲end das Datenbank-Update noch l䵦t, muss verhindert werden dass sich | ||
// Clients mit der Datenbank verbinden. Dies | // Clients mit der Datenbank verbinden. Dies k?e einfach durch eine vorhandene | ||
// "Sperr"-Datei im Anwendungsverzeichnis erfolgen. Es wird ein Warte-Dialog aus- | // "Sperr"-Datei im Anwendungsverzeichnis erfolgen. Es wird ein Warte-Dialog aus- | ||
// | // gef?bis das Update abgeschlossen ist. | ||
// * In einer | // * In einer zuk?en Version k?e das DB-Update einfach mal versucht werden, | ||
// dabei | // dabei m?aufgezeichnet werden, welche Update-Schritte durchliefen, und bei | ||
// welchen es zur DB-Fehlermeldung "Object in use" kam. Kam es erstmalig zu diesem | // welchen es zur DB-Fehlermeldung "Object in use" kam. Kam es erstmalig zu diesem | ||
// Fehler, muss der down der anderen Clients erzwungen werden. (dadurch wird es | // Fehler, muss der down der anderen Clients erzwungen werden. (dadurch wird es | ||
Version vom 19. September 2005, 09:06 Uhr
// Verwirklichtes Konzept: // // * In es ein metadata relevantes Update, so wird in der Tabelle Revision ein '9999' // eingetragen. Dieses bleibt solange bestehen, bis der Updatevorgang abgeschlossen // oder fehlgeschlagen ist. Connects sollten in dieser Zeit unterbleiben! // * Frisch connectierte OrgaMon sollten im Update-Check geparkt werden, bis // das db-update abgeschlossen ist. Es wird dabei im Sekundentakt immer wieder // nach dem Wert 9999 gesehen! // * Sieht die Datenbank beim insert den Wert '9999' so feuert sie den event // post_event 'PLEASE_DISCONNECT'; // * auch einen event 'PLEASE_DOWN' schaffen, der den Applikationen signalisiert, // das in wenigen Minuten heruntergefahren werden muss. z.B. K?e so ein XMLRPC // Server keine neuen Verbindungen mehr annehmen! '9998' // * OrgaMon sollte dem Benutzer die Aufforderung zum Beenden anzeigen // * Update-Prozess von Orgamon: OrgaMon schreibt Batch, ruft den batch auf, beendet // sich selbst. Der batch ruft sleep, um sicherzustellen das OrgaMon beendet ist. // Danach das Setup, dieses ?hreibt den exe, ruft diesem im Anschluss auf! // * Eine neue ftp/web-"Update?" Aktion sollte nachsehen k?n, ob Updates vorliegen! // sp䴥stens bei Tagesabschluss sollte das gemacht werden! // * Ein Updateadmin sollte das downgeloadete Update f?e freischalten k?n. // * Szenario ?gen: Wie kann der Updateadmin ein "m?risches" Update wieder // entfernen will, er will sicherstellen dass alle wieder auf die alte Version // zur?en, das autoupdate verhindern! OrgaMon darf nicht mehr "nerfen" das // eine neue Version vorliegt. Der Admin soll einfach "unstable" Revisions // markieren k?n. Beim Start sollten "zu neue" Orgamons eine Warnmeldung ausgeben // bzw. gleich die richtige Version dr?stallieren (Programmversion>Datenbank- // Version/empfohlene Version) // * Ein Updateadmin sollte das fertig downgeloadete Update signalisiert bekommen // er gibt diese Version frei oder nicht. // * W䨲end das Datenbank-Update noch l䵦t, muss verhindert werden dass sich // Clients mit der Datenbank verbinden. Dies k?e einfach durch eine vorhandene // "Sperr"-Datei im Anwendungsverzeichnis erfolgen. Es wird ein Warte-Dialog aus- // gef?bis das Update abgeschlossen ist. // * In einer zuk?en Version k?e das DB-Update einfach mal versucht werden, // dabei m?aufgezeichnet werden, welche Update-Schritte durchliefen, und bei // welchen es zur DB-Fehlermeldung "Object in use" kam. Kam es erstmalig zu diesem // Fehler, muss der down der anderen Clients erzwungen werden. (dadurch wird es // zum kritischen Update!). Ab der ersten exception kann ja nun wieder angesetzt // werden! // * Die SQL-Scripts, die von Release zu Relase die Datenbank Struktur // hochziehen, nach aussen transparenter machen (in der !*_Info.html!), da doch das // Interesse an der Datenbank-Struktur bei siemens da zu sein scheint. // die Datei befindet sich im Verzeichnis "MyApplicationPath". format: // * Nach manchen SQL-Script Befehlen wird "reconnect" notwendig, dies kann im // hebu - Projekt nachgewiesen werden. Ev. mal einen Test-Case daraus machen! // *