Hey,
ich bin gerade dabei, ein eigenes Update System zu schreiben und hatte vorhin den Einfall, dass ich hier vielleicht mal fragen könnte, was ihr noch so für Ideen habt, weil es einfacher ist, sowas jetzt umzusetzen, als das dann später zu maschen. Hier sind meine Anforderungen an das Update System, die ich auf jeden Fall umsetzen werde:
Das ganze wird dann eine Mischung aus nUpdate, UpdateSystem.Net und meinen eigenen Ideen. Ich hatte auch kurz überlegt, z. B. nUpdate zu forken, aber das ist doch etwas ziemlich anderes, bei Plattformunabhängikeit schreibe ich den Code am liebsten komplett selber. Hat noch jemand Ideen?
*Topic verschoben*
ich bin gerade dabei, ein eigenes Update System zu schreiben und hatte vorhin den Einfall, dass ich hier vielleicht mal fragen könnte, was ihr noch so für Ideen habt, weil es einfacher ist, sowas jetzt umzusetzen, als das dann später zu maschen. Hier sind meine Anforderungen an das Update System, die ich auf jeden Fall umsetzen werde:
- Kein FTP(S) oder SFTP für das normale arbeiten -> alles wird über serverseitige Scripte (PHP) geregelt
- Hat den Vorteil, dass nicht unbedingt ein FTP Server laufen muss. Außerdem sind somit nicht die FTP Daten erforderlich; sollten die Schlüssel gestohlen werden, könnte der Angreifer höchstens Updates löschen (und nicht den kompletten Server, was der Fall wäre, wenn die FTP Daten gestohlen werden)
- Delta Patching (also Dateien, die nur die wirklichen Änderungen enthalten, was zu deutlich kleineren Updates führt)
- Saubere Versionssprünge
- Jede Datei hat eine eigene Zeile in der Tabelle. Sollte nun der Benutzer von Version 1.0.0 auf 5.0.0 springen wollen, würde das Script nur die Unterschiede zwischen den beiden Updates untersuchen. Rollbacks, Repair sowie Downgrades sind dadurch auch möglich
- Tasks werden korrekt geordnet/es muss angegeben werden, ob ein Task auch ausgeführt werden soll, wenn die Version übersprungen wird
- Lizenzüberprüfung soll möglich sein / das Update System muss gut in kommerzielle Projekte integriert werden können
- Administrative Funktionen wie Rollbacks, Delayed Publishing, sauberes Bearbeiten von Updatepakten, Zwangsupdates, etc. sind verfügbar
- Verschiedene Dateien für verschiedene Architekturen (x64, x86, Mono, etc.) im selben Updatepaket
- Kompatibel zu portablen Programmen
- Plattformunabhängigkeit für die Library
- Mono kompatibel und eine Portable Class Library (da muss ich mich aber erst noch einlesen)
- Ausführliche Statistiken zu Benutzeraktivität hinsichtlich Updates (wann suchen Nutzer updates, welche Nutzer benutzen aktuell welche Version, wann wurde welches Update heruntergeladen, welche Benutzer sind gerade aktiv)
- Semantic Versioning
- Markdown unterstütze, mehrsprachige Changelogs
- Ein Server, mehrere Projekte
- Mirror Server
- Man kann beliebig viele Server für jedes Projekt auswählen. Alle Server werden bei jedem Start synchronisiert
- Es müssen nie alle Server online sein, die Server, die offline waren, werden einfach beim nächsten Start auf den aktuellen Stand gebracht
- Server können geklont werden
- Sicherheit (also die Standardsachen wie Updates signieren etc.)
- Keine Grenzen beim expandieren, 1000 Updatepakete sollen kein Problem für die Performance sein
- Vereinfachungen beim Erstellen von Updatepaketen, also dass z. B. direkt überprüft werden kann, welche Dateien sich verändert haben; die Changelog Sprachen aus dem letzten Update werden übernommen, usw.
Das ganze wird dann eine Mischung aus nUpdate, UpdateSystem.Net und meinen eigenen Ideen. Ich hatte auch kurz überlegt, z. B. nUpdate zu forken, aber das ist doch etwas ziemlich anderes, bei Plattformunabhängikeit schreibe ich den Code am liebsten komplett selber. Hat noch jemand Ideen?
*Topic verschoben*
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Marcus Gräfe“ ()