Clansuite Community Forum

 
Willkommen Gast. Bitte einloggen oder registrieren.
Haben Sie Ihre Aktivierungs E-Mail übersehen?

Einloggen mit Benutzername, Passwort und Sitzungslänge
 
Seiten: [1]   Nach unten
  Drucken  
Autor Thema: Auto Updater  (Gelesen 600 mal)
0 Mitglieder und 2 Gäste betrachten dieses Thema.
paulbr
Developer
*****
Offline Offline

Beiträge: 126


« am: November 13, 2010, 01:28:01 »

Ich mach mal einen neues Thema dafür, da dies in dem Modul: Forum eig. nichts zu suchen hat.

Wenn ich das richtig verstehe, so wird das auf shell ebene installiert?
Was machst du bei einzelnen core files, da gibbed ja keine info.xml?

Nicht jeder Clansuite betreiber kennt sich mit techniken und Programmierung aus, es muss eine
Simple und für ihn einfache Lösung sein.

Randbemerkung:
Gerade in den Alpha/Beta Phasen werden ständig neue Updates vorhanden sein.
Ob hier bereits ein Auto Upload Sinn macht glaube ich kaum.


Ich hatte mir das im groben so Vorgestellt  Zwinkernd

Benötigt werden 2 Module:
  • Update-Generator Modul (zusammenstellen des updates)
  • Update-Import Modul (installieren des updates)1)

Auf der Clansuite.com (welche ja durch das svn immer aktuell sein sollte), ein Update-Generator
nutzen, welcher mittels Add neue corefiles versionen und/oder Moduleversionen
in einer liste schreibt. Diese kann man dann automatisch mittels eines Moduls zu einer package-datei
und einer Info datei z,B. update.xml zusammen stellen lassen.
Die Info datei beinhaltet einen index der package dateien sowie einen Update-Key-Schlüssel und die
clansuite Release-version die dafür benötigt wird. Auch könnte man hier eine Abhängigkeit einzelner
Dateien zueinander festlegen, welche der Importer dann prüfen muss.
Die beiden files werden dann in einem speziellen update ordner gestellt.
Vorherige Update Pakete erhalten den Update-Key-Schlüssel als Name und verbleiben als Archive.

Die einzelnen Clanseiten, welche nun Clansuite verwenden prüfen mittels cron, z.b. wöchentlich,
ob in diesem update ordner eine update.xml vorhanden ist und downloaden diese.
Zuerst wird nun geprüft, ob der Update-key-Schlüssel bereits existiert,also das Update bereits
Installiert ist. Wenn ja passiert nichts und update.xml wird gelöscht, wenn nein wird das package downgeloadet.
Wenn der Admin sich nun einlogt, bekommt er eine Nachricht, das ein Update vorhanden ist.
Es wird ihm nun eine Liste mit allen core files und/oder modulen angezeigt (aus update.xml), welche er manuel an- bzw. abwählen kann.
Man muss hier berücksichtigen, das evtl. einzelne Clanbetreiber änderungen an Modulen vornehmen,
ein automatisches Update selbiger überschreibt diese sonst.

Das ausgewählte wird nun aus dem package entpackt, installiert und ein Update-Protokoll in seiner DB gespeichert. So kann er auch später noch, nicht installierte Updates, nachinstallieren.
Zusätzlicher Vorteil: Man kann im Rahmen des Supports sehen welche Updates nicht Installiert wurden und so evtl. schneller Probleme/Fehler finden.
Egal welche Variante man benutzt, die Module haben eine versionsnummer, die core files brauchen diese aber auch. Es sollten deshalb alle Core dateien eine Versionsinfo erhalten. Das SVN-Build ist dazu eher weniger geeignet.

So in etwa war meine grobe Vorstellung die ich von dem Updater hatte.

1)
Das könnte man auch als Schnittstelle für ein Import-Modul machen.
Die Clansuite benötigt früher oder später sowieso ein Import/Export-Modul um diverse
Daten welche in csv, xml, txt... format vorliegen zu importieren/exportieren.

@todo: Auf diese Art wäre auch ein Webinstaller denkbar, der sich das aktuelle Release package holt und Live Online installiert.

gruss
paul
Gespeichert
thunderm00n
Designer
*****
Offline Offline

Beiträge: 107


« Antworten #1 am: November 13, 2010, 01:33:20 »

Auch wenn ich kein Programmierer im eigentlichen Sinne bin (eher ein weiteres Augenpaar bei der Fehlersuche) habe ich das Konzept dahinter denke ich verstanden  Lächelnd
Gespeichert

greetz Thunderm00n

Ein Rechtschreibfehler (auch Fehlschreibung genannt) bezeichnet eine Schreibweise eines Wortes oder Satzzeichens, die laut der allgemein üblichen Orthographie falsch ist.
Meine Rechtschreibfehler unterliegen der General Public License und dürfen frei verwendet werden.
Jens-A. Koch
Maintainer
*
Offline Offline

Beiträge: 574

One-Man Team


« Antworten #2 am: November 13, 2010, 03:27:27 »

Also im Grunde sind unsere Ideen in etwa gleich - nur die konkrete Umsetzung ist etwas anders.

Shell
Zitat
Wenn ich das richtig verstehe, so wird das auf shell ebene installiert
Man kann natürlich auf Shell-Ebene gehn, um die Updates auch manuell einzuspielen,
aber eigentlich wird alles über das Backend laufen. Die Aufrufe von der Shell sind ja nur Weiterleitungen an die PEAR Skripte. Das Backendinterface geht mit Kommandoaufrufen daher direkt auf den Packagemanager - die Oberfläche basiert auf dem PEAR_Frontend_Web.

Export und Import Funktion wirds geben.
Update-Generator Modul = Export = Module einpacken und für manuellen Upload vorbereiten.
Update-Import Modul  = Import = Module installieren.

Update-Generator
Zitat
Auf der Clansuite.com (welche ja durch das svn immer aktuell sein sollte), ein Update-Generator
nutzen, welcher mittels Add neue corefiles versionen und/oder Moduleversionen
in einer liste schreibt. Diese kann man dann automatisch mittels eines Moduls zu einer package-datei und einer Info datei z,B. update.xml zusammen stellen lassen.
Nichts anderes macht der Packagemanager auf dem Server - er legt eine Registry für alle verfügbaren Dinge an und hält diese Liste zum Abruf bereit. Der lokale Packagemanager (installierte Clansuite) holt sich diese Liste und übernimmt die Versionkontrolle und die Prüfung auf Abhängigkeiten und deren Auflösung.

Besondere Update-Keys wollte ich nicht einführen. Ein Versionsnummernvergleich reicht aus.

User-Modifikationen
Zitat
Man muss hier berücksichtigen, das evtl. einzelne Clanbetreiber änderungen an Modulen vornehmen, ein automatisches Update selbiger überschreibt diese sonst.
Klar, wenn User die Dateien verändern, wirds problematisch.
Erstmal gilt Backup bevor Update. Dann bleiben schonmal die Modifkationen erhalten.
Das Wiederanpassen bzw. die Modifikation nach Aktualisierung wieder einpflegen, muss der User dann schon selbst machen. Also der Core und die beiden Themes "standard" und "admin" werden immer überschrieben. Module kann der User ja auswählen.

Themes kann man ableiten/clonen - das sollte man den User dann auch vermitteln, dass man nicht direkt auf den "System"themes arbeitet. Arbeiten am Core kann man machen, muss dann aber in Kauf nehmen, dass man Änderungen wieder einpflegen muss.

Für User-Modifikationen an Modulen kann ich nur Vorschlagen, dass man evtl. die Klasse des Moduls erweitern und Hooks nutzen könnte - wobei diese User-Änderungen in zusätzlichen Dateien liegen (die ja nicht zum Module gehören und daher auch vom Update nicht betroffen sind). Damit wäre es möglich die Module zu updaten und User-Änderungen beizubehalten.

Änderungen im Templatebereich sind fast nur manuell nachpflegbar. Helfen könnte man dem User mit einer Diff-Anzeige bzw. Versionunterschiedsanzeige. Es gibt kaum Systeme die sowas machen oder anbieten.
SMF arbeitet beispielsweise mit den Anweisungen Suche/Ersetze auf allen Dateien. Wenn man dort eine Modifikation gemacht hat, die einen der gesuchten Strings verändert, dann wird das Update nicht eingespielt. Für die Entwickler der einfachste Weg - für die User eine ewige Suche.

Versionsnummern
Zitat
Egal welche Variante man benutzt, die Module haben eine versionsnummer, die core files brauchen diese aber auch. Es sollten deshalb alle Core dateien eine Versionsinfo erhalten. Das SVN-Build ist dazu eher weniger geeignet.
Ja, die Versionnummer für Module haben wir in der Modulebeschreibungsdatei.
Für Theme-Packages können wir auf die theme_info.xml zurückgreifen.

Für den Core gehen mehrere Dinge - wir können ja mal abwägen, was die bessere Lösung wäre.
a) Wir schreiben " // Version: 0.1 " als String in jede Datei und ändern diesen String beim Tagging einer Version. Für die Version-Überprüfung kann man dann preg_matchen.
b) Wir setzen in jede Core-Klasse eine Methode getVersion() { return '1.2.3'; }. Hier muss man nur über alle Core-Klassen laufen und die Methode aufrufen, um einen Versionsvergleich durchzuführen.
c) Wir nehmen den SVN-ID Tag bzw. dort die SVN-Revisionsnummer als Anknüpfungspunkt.
d) Wir packen den gesamten Core in ein Package mit der Tag-Versionsnummer.(Dann aktualisiert man den Core immer als Ganzes.)

Gruß Jens
Gespeichert

Keine Supportanfragen per PN oder Mail. Fragen bitte nur im Forum stellen (Wie man Fragen richtig stellt).
paulbr
Developer
*****
Offline Offline

Beiträge: 126


« Antworten #3 am: November 13, 2010, 04:44:44 »


Ich merks schon, die gedanken gehn in die selbe Richtung, ist alles nur eine Frage der Umsetzung  Zwinkernd

Zitat
Änderungen im Templatebereich sind fast nur manuell nachpflegbar. Helfen könnte man dem User mit einer Diff-Anzeige bzw. Versionunterschiedsanzeige.

Das sollten wir nicht berücksichtigen. Ich sag mal so: Wenn ein User so dumm ist, bestehende Themen
durch Anpassung zu überschreiben, ist er selbst Schuld.
Der User sollte IMMER ein Theme welches er anpassen und dann verwenden möchte clonen und unter neuen Namen ablegen.
So wird das Clansuite Theme nicht verändert und kann ohne bedenken mit aktualisiert werden.

Core dateien sollten immer überschrieben werden, da dies der kernel des Systems ist.
Wenn ein User hier nicht alles mit dem Update aktualisiert, läuft ggfs. die clansuite nicht mehr.
Für den Core sollte daher auch gar nicht erst die Möglichkeit bestehen teile davon beim Updaten
herauszunehmen.

Bei Modulen ist es wichtig das er das kann. Nicht jeder will jedes Modul einsetzen, daher auch gar nicht erst Installieren wollen.

Ich bin sogar der Meinung man sollte die Module bis auf den Standard-Modulen (core-module) welche jede Clanseite
immer benötigt, separieren und durch Installion bei Bedarf (als Plugins/Addons) hinzufügen.
Dafür müssten die Module allerdings gekapselt werden und ein Installer-Script beinhalten.
Ein Globaler Clansuite Installer könnte dann diese Module Installieren.

Der Installer müsste dann:
  • das Modul an den richtigen ort kopieren
  • die Administration entsprechend um das Modul erweitern
  • die Datenbank um die Module-Tabellen ergänzen/updaten
  • doctrine records generieren und im Moduleordner abspeichern

Es wird früher oder später User-Hacks geben und dann wird es ohne vernünftigen Module-Installer zu
Problemen kommen.

gruss
paul
Gespeichert
Seiten: [1]   Nach oben
  Drucken  
 
Gehe zu:  


Powered by SMF 1.1.16 | SMF © 2006-2009, Simple Machines

Google visited last this page Mai 08, 2012, 03:33:43