FAQ |
Kalender |
![]() |
#1 | ||
|
|||
Flitig postare
|
Jag håller på att utveckla en applikation som består av flera moduler. Användaren av applikationen ska kunna ladda ner och installera moduler och dessa moduler vill jag kunna uppdatera automatiskt när det släpps en ny version av modulen.
Jag har tänkt mig följande logik: 1. Ladda ner en zip-fil med filer som har ändrats i modulen. 2. Skriva över filerna på servern med filerna i zip-filen. Är detta ett bra tillvägagångssätt, eller finns det andra bättre sätt att göra detta på? Jag tar gärna emot tips och idéer från personer som har utvecklat automatisk uppdatering av applikation. Applikationen programmeras i PHP. |
||
![]() |
![]() |
![]() |
#2 | |||
|
||||
Bara ett inlägg till!
|
Utan att själv ha utvecklat något liknande så skulle jag nog vilja ha med någon sorts signaturverifiering som visar att paketet inte modifierats av någon elakartad tredjepart.
Samt att det tas en automatisk backup av de filer/tabeller som ska skrivas över utifall att något händer. |
|||
![]() |
![]() |
![]() |
#3 | ||
|
|||
Mycket flitig postare
|
Citat:
|
||
![]() |
![]() |
![]() |
#4 | |||
|
||||
Har WN som tidsfördriv
|
Wordpress använder zip-filer för både core, plugins och teman ungefär på det sättet du beskriver.
Nu har jag inte koll på exakt hur det fungerar, men jag tror det fungerar ungefär såhär. Om man är inloggad som admin skickar WP ibland(vet inte hur ofta eller vad som triggar) en request till wordpress.org med information om vilken version man har av core samt alla teman och module som finns i installationen. Wordpress.org jämför sedan versionsnumret(utvecklarna sätter det här versionsnumret själva). Om det finns en nyare versioner(högre versionsnummer) får man en notifiering om detta. Därefter kan man välja att uppdatera och då laddas zip-filerna upp på installationens server via FTP/SFTP. Därefter packas de upp och skriver över de befintliga filerna. Under den här tiden sätts WP i maintenance-läge vilket gör att ingen kan nå sidan förens detta är klart. Att spara en backup av den gamla versionen tycker jag låter som en mycket bra idé så att man enkelt kan göra en rollback om något skulle gå fel. |
|||
![]() |
![]() |
![]() |
#5 | ||
|
|||
Medlem
|
Jag skulle nog låta användarna göra en manuell uppdatering, för att hålla det enkelt,
d.v.s skriva över filer utifrån en installationsdokumentation. Det är även trevligt om alla filer som berörs av en patch/uppdatering ligger i en mappstruktur som motsvarar applikationens. Tex: css/module/module_x.css js/module/module_x.css php/module/module_x.css På så vis slipper man leta upp olika filer och göra flera uppladdningar.. Vaf gäller databas ändringar skulle jag ha två filer : structure.sql data.sql Viktigt också att hantera transaktioner om det är större db ändringar. Personligen skulle jag undvika automatisk backup av filer och db, det känns svårt att verifiera att det funkar om det handlar om stora databaser exempelvis |
||
![]() |
![]() |
![]() |
#6 | ||
|
|||
Klarade millennium-buggen
|
Man ska ALDRIg tvinga användare att hålla på och kopier afiler och köra script manuellt, en enkel klick sen ska allt skötas automatiskt...
|
||
![]() |
![]() |
![]() |
#7 | ||
|
|||
Medlem
|
Citat:
Att skriva en uppdaterings funktion som kan hantera filöverskrivningar, skrivrättighter i mappar, databasstruktur och data ändringar, backuphantering av db och filer samt en felhantering av detta på ett användarvänligt sätt är inte direkt så enkelt.. |
||
![]() |
![]() |
![]() |
#8 | ||
|
|||
Administratör
|
Är det en modulär applikation med rätt många moduler och de ofta kan vara dåligt underhållna håller jag med Conny - one-click är ett måste. Annars kommer knappt några att uppdatera inom en rimlig tidsram.
För att förenkla en sådan kan du låta backup-återställning osv vara en lite omständigare process (att användaren själv får lägga in sql-dumpar och undansparade filer från backup). Dock måste du vara noga med kontrollerna för att scriptet har alla rättigheter som krävs för uppdatering (kunna skriva till backup-katalogen, komma åt database, kunna skriva över alla filer i uppdateringens fillista) för annars kommer det allt som oftast sluta misslyckat.
__________________
eldefors.com - Personlig (teknik)-blogg |
||
![]() |
![]() |
![]() |
#9 | ||
|
|||
Klarade millennium-buggen
|
Citat:
En vanlig användare ska ALDRIG tvingas till några som helst onödiga arbetsmoment för att uppdatera sin applikation, för då kommer de att göra fel eller strunta i det. Eller så måste de hyra in en konsult som gör jobbet. Konsekvensen blir att de väljer en annan programvara som är enklare att hantera. Det är bara vi programmerare och extremt avancerade användare som vill "ha kontroll" på vad som sker "under huven", alla andra vill "att det ska fungera helautomatiskt och felfritt i alla väder". Fullständigt automatisk uppdatering när man startar applikationen är det enda som funkar någorlunda säkert. Sen får man som utvecklare se till att det inte finns något som kan gå fel, och de fel som uppträder ska hanteras automatiskt. Eventuellt med helautomatisk återrapportering till din egen supportrutin. En vanlig användare ska helst aldrig ens behöva veta att något är fel i dennes applikation. Om man har en enklare Lite-version av sin programvara och en annan mer avancerad som användaren måste betala för så måst eman tänka igenom så det funkar ihop med Lite-versionen om exempelvis dessa programvaror kommunicerar på något sätt. De ska även funka ihop om det är olika versioner. Fär den som har lite versionen kanske uppgraderar men då ska int eden som betalar tvingas uppgradera bar aför att kunna kommunicera med den Lite-verion av senare version. http://Teamviewer.com har gjort det misstaget med en annars suverän programvara. Senast redigerad av Conny Westh den 2013-02-26 klockan 07:47 |
||
![]() |
![]() |
![]() |
#10 | ||
|
|||
Medlem
|
Visst är det bättre för en användare med one-click, absolut.
Men frågan är också "return on investment". Är det värt i detta läge för Hensod att göra en automagisk funktion, kanske, kanske inte. Om man ska göra det bra kommer det absolut vara tidskrävande. Men vilken är användaren, jag skulle ändå säga att användaren när man ska uppdatera en site typiskt är en person med minst -viss- teknisk kompetens och inte den faktiska beställaren av systemet (ja om det nu inte är samma person). Man ser många " automatiska " uppdateringsfunktioner där man ändå först måste ta en back up på databasen från phpmyadmin och kolla att man har rätt version av x eller y. Och vad händer om man måste göra en rollback för att ens automatiska funktion inte funkade på just en viss konfigurering på en shared host. |
||
![]() |
![]() |
Svara |
|
|