Non farlo.
Attenersi ai normali processi di aggiornamento attualmente utilizzati dalla maggior parte delle aziende per aggiornare software client o lato server.
Spetta agli utenti attivare il processo di aggiornamento quando devono essere aggiornati. È ancora più vero per un sito Web, per diversi motivi (alcuni dei motivi si applicano anche ai software client-side):
-
Sicurezza: come utente, non voglio che qualcuno di cui non mi fidi aggiorni il mio sito web in qualsiasi momento senza chiedere il mio permesso,
-
Privacy: se gli aggiornamenti accedono al database, in che modo gli utenti possono essere sicuri che i loro dati non verranno utilizzati maliziosamente dalla tua azienda?
-
Rendimento: se la maggior parte dei miei utenti è connessa dalle 14:00 alle 21:00 e non ci sono alcune o poche connessioni tra le 3:00 e le 5:00, voglio che gli aggiornamenti avvengano nel bel mezzo della notte , non quando tutti i visitatori stanno usando il mio sito web. Cosa succede se si avvia l'aggiornamento alle 16:00?
-
Gestione del rischio: cosa succede se durante un aggiornamento, il mio sito web non funziona? Che cosa succede se lo noto solo dopo una settimana e trovo che è il tuo aggiornamento che hai fatto senza alcun permesso che lo ha causato? Vuoi compensare la perdita finanziaria?
-
Compatibilità: cosa succede se ho apportato alcune modifiche o aggiunto alcuni plug-in che non sono compatibili con i tuoi aggiornamenti?
Quindi non farlo, o essere pronto per essere citato in giudizio e vedere i tuoi clienti che ti lasciano.
imagine that we want to add a module to these sites
Cosa succede se l'utente non ha bisogno di questo modulo? Meno codice lato server significa meno buchi di sicurezza. Se l'utente non ha bisogno di una funzionalità aggiuntiva, non ci sono motivi per costringerlo ad avere questa funzione abilitata sul suo sito web.
C'è un'eccezione: soluzioni ospitate con codebase unificato. Considera i seguenti casi:
Caso 1:
- Nome di dominio di terzo livello (mywebsite.example.com) o reindirizzamento facoltativo da un nome di dominio di secondo livello,
- Soluzione ospitata,
- Nessuno scripting sul lato server,
- Nessun plug-in esterno (ovvero plug-in che non sono già ospitati),
- Nessun accesso diretto all'origine o ai dati (ad esempio non è possibile accedere direttamente ai dati del database, né eseguire backup e salvarli localmente), ecc.
- Impossibilità di migrare il sito Web a un altro hosting,
- Personalizzazione limitata alle opzioni in un pannello di configurazione,
- Annuncio forzato incorporato nelle pagine del sito web (facoltativamente rimosso se paghi).
Caso 2:
- Nome di dominio di secondo livello (mywebsite.com) o nome di dominio di terzo livello (a seconda del prezzo),
- Soluzione ospitata,
-
Forse scripting lato server ,
- Forse plugin esterni,
- Possibilità di creare query SQL e / o dati di backup localmente ,
- Possibilità di scaricare tutto il necessario per migrare il sito Web a un altro hosting ,
- Possibilità di personalizzare il sito web caricando contenuti aggiuntivi (fogli di stile, immagini, ecc.) ,
- Forse pubblicità forzata incorporata nelle pagine del sito web (facoltativamente rimossa se paghi).
Che cosa fa la differenza?
- Nel primo caso, abbiamo una soluzione generica che cerca di soddisfare tutte le esigenze. Se i tuoi bisogni sono diversi, vai via, il nostro sito non fa per te. Siamo i proprietari del servizio , quindi accetti di usarlo così com'è oppure ne cerchi un altro.
- Nel secondo caso, abbiamo un nucleo generico che puoi utilizzare per creare qualcosa che soddisfi le tue esigenze. Ora sei il proprietario del sito web .
Dietro le quinte, potrebbe avere un impatto enorme sull'architettura della soluzione:
- Nel caso di una soluzione generica, non ci sono file ospitati separatamente per ogni sito web. Se esiste un file CSS per un modello specifico, questo file è ospitato una volta . Per ognuna delle migliaia di "siti web". Se esiste un file PHP contenente una classe che viene utilizzata da ogni sito web, esiste un solo file PHP per server .
- Nel caso di un core generico, d'altra parte, potrebbe non esserci un hosting unificato (anche se potrebbe essere un'opzione, ma, beh, quando costruisco il mio sito web ospitato sul mio server, non lo faccio t host JQuery, ma usa invece Google CDN, quindi è la stessa cosa). Ciò consente al cliente di modificare un file specifico senza influire sugli altri clienti.
Si vede che nel primo caso gli aggiornamenti per utente non funzionano e non possono essere implementati. Come fornitore di servizi, puoi aggiornare tutti tutti in una volta, poiché tutti condividono gli stessi file. Non è possibile chiedere l'autorizzazione agli utenti o lasciare che l'utente specifico pianifichi l'aggiornamento. Ma in questa situazione di hosting, ci si aspetta che gli utenti vengano aggiornati passivamente, quindi è ok.