Dovresti la versione delle applicazioni web?

Se rivendi la stessa applicazione web a più clienti, dovresti assolutamente eseguirne la versione.

Se si tratta di un sito web che viene installato sempre e solo in una posizione, la necessità è meno grave, ma probabilmente non potrebbe danneggiarla. Saresti meno sensibile ai problemi del fuso orario e anche a questo. La diagnosi di un problema in una versione 1.0.2.25 di una libreria è molto più interessante rispetto alla ricerca della build della libreria il 3 novembre 2010 alle 11:15

Se puoi automatizzare il numero di versione sulle DLL della tua applicazione, non ti farebbe male. Ti aiuterà a tenere traccia delle versioni.

In generale, le app Web vengono rilasciate solo in una posizione in cui la si ospita, quindi non è così importante come dire un'applicazione desktop. Può essere d'aiuto con i rollback, la tracciabilità dei bug (ad esempio la versione in cui si trovava) e tenendo traccia della differenza tra server di sviluppo, di staging e di produzione, se applicabile.

Cercherò di automatizzarlo, è il tipo di cosa che puoi impostare una sola volta e usarla se / quando ti serve.

I tuoi utenti non si preoccupano dei numeri di versione poiché hanno sempre la versione più recente e più grande, ma devi a te stesso (e al tuo team) sapere esattamente quale versione viene eseguita dal vivo. Alla fine la tua fonte di sviluppo non è sincronizzata con il codice live e quindi sicuramente deve saperlo. Quindi etichetta i tuoi rilasci nell'albero svn / git e contrassegna l'app web con quel tag.

Oltre a quello che hanno detto gli altri, aggiungerei che il controllo delle versioni è importante anche dal punto di vista del marketing. Una nuova versione è qualcosa di nuovo che può essere commercializzato ai clienti potenziali o esistenti. Permette ai clienti di sapere che qualcosa è "nuovo" e vedere che le cose vanno avanti. Fornisce piacevoli raggruppamenti di nuove funzionalità. E sembra più professionale.

Dico che per qualsiasi cosa tranne una semplice applicazione web, dovresti eseguirla. Qui ci sono due nozioni leggermente diverse:

1. applicazione nel suo complesso
2. singoli file

Indipendentemente dalla situazione, ritengo che i file debbano avere numeri di versione (o di revisione) individuali. Idealmente, questo sarebbe gestito automaticamente dal tuo sistema di controllo della versione. Come è stato affermato da altri, è più facile fare riferimento al numero di versione di un file che alla sua data e ora.

Se hai (o potresti avere) più di un'installazione live dell'applicazione, dovrebbe essere versionata nel suo complesso. Questa è anche una buona pratica se si dispone di ambienti di sviluppo e test separati (come probabilmente dovrebbe). Ogni numero di versione dell'applicazione (o versione) fa riferimento a una raccolta di singoli file con numeri di versione specifici. Affrontare tutto questo è un onere aggiuntivo, è più semplice effettuare il check-out di una versione specifica rispetto ai singoli file a specifici numeri di revisione.

Questo mi fa pensare a una nozione in linguistica. Si dice che se non puoi esprimere qualcosa in una lingua, non puoi pensarci (in quella lingua). Penso alla parola tedesca "Schadenfreude". È molto più facile pensare (e parlare) di questa nozione di "provare gioia per la sfortuna di qualcun altro" facendo riferimento a quella parola, che alla sua definizione. Questo è il motivo per cui la parola è entrata in uso nella lingua inglese.

Allo stesso modo, i numeri di versione rendono più facile parlare (e pensare) della tua applicazione e dei suoi file in stati specifici. Se sei un team di una sola persona, lavorando su una sola applicazione, probabilmente non fa una grande differenza. Tuttavia, poiché le cose si complicano, è meglio che tu abbia queste etichette disponibili per l'uso.

Dovresti eseguire la versione della tua applicazione web con l'id di build dal tuo server di build e avere quell'id incluso in tutte le segnalazioni di bug.

Questo ti permetterà di tornare indietro nel tempo nel caso dovessi correggere un bug segnalato su una versione precedente non attualmente presente in produzione.

Dalla tua domanda è chiaro che hai in mente una semplice applicazione web

• accessibile solo da una GUI Web e non da un'API Web (-service) . Se hai utenti che accedono all'applicazione utilizzando un'API hai bisogno per la versione. Se modifichi l'API, interrompi i client, quindi devi mantenere una versione diversa dell'API allo stesso tempo.

• Solo una istanza in esecuzione al momento . Anche se hai solo il web man, se hai più installazione devi sapere quale cliente sta eseguendo quale versione.

• Con tempo di attesa accettabile per l'aggiornamento della versione live. Esiste un possibile problema enorme che è il database . Cambiamenti importanti con le versioni più recenti vengono con modifiche nella struttura sottostante dei dati. Se hai una sola versione in esecuzione al momento, probabilmente dovrai disattivare la vecchia versione, aggiornare il database e attivare la nuova versione. Che si traduce in tempi di fermo dell'applicazione. Questo può essere accettabile in base al numero e al tipo di utenti.

• Uso interno solo con base di installazione limitata?
• O potrebbe avere più versioni in the wild?

Abbiamo solo il primo, quindi usiamo il numero di versione solo per controllare il post-rilascio. Non dobbiamo tenere traccia di molte versioni in uso contemporaneamente.

Se la tua applicazione web è composta da più moduli, sia in client che in server, ogni modulo dovrebbe essere sottoposto a versionamento. E ogni combinazione di versioni di moduli su client e server deve avere un ID univoco, un id che dovrebbe essere presente in tutti i messaggi di registrazione e di errore.

Usando questa convenzione, sarà sempre possibile ricreare lo stato in cui si trovava l'app web in un dato momento.

Secondo me, dal momento che le webapps in questi giorni sono costruite usando linguaggi dinamici su entrambi i lati, server e client, non ci dovrebbero essere motivi per ricaricare un'app web aggiornata a meno che l'utente non riavvii il browser o ricarichi manualmente la pagina.

Solo le parti o i moduli aggiornati nell'app Web devono essere ricaricati senza influire sullo stato generale dell'applicazione.

Perché potresti chiedere? Beh, applicando ciò, l'app web sarà più roboust, corretta e probabilmente più facile da mantenere. Se l'app web richiede sempre l'aggiornamento simultaneo di server / client, probabilmente non è costruita nel modo giusto.

Sì, dovresti metterlo in versione! E ci dovrebbe essere un tag nel tuo sistema di controllo di revisione (come subversion, git, mercurial, ecc.) Che corrisponde al numero di versione.

Il tag ti consente di tornare indietro e creare un ramo. Ad esempio: la versione di produzione corrente ha un bug, ma non è possibile risolverlo perché il codice sulla tua macchina non è pronto per il lancio. Se lo hai taggato nel tuo RCS, puoi diramarlo in quel tag e correggere il bug nella versione esatta del codice in esecuzione in produzione.

Personalmente penso che dovresti comunque la versione, ma un grande vantaggio della versione di applicazioni web specifica per i siti Web è che può rendere molto più facile la gestione dei cambiamenti nel contenuto statico.

Ad esempio, supponiamo che tu abbia un file mysite.css che ha una data di scadenza molto futura (che generalmente vuoi fare in modo che sia memorizzato nella cache del browser su ciascuna pagina). Se poi modifichi uno stile in quel file, nessuno che sia stato sul tuo sito prima lo vedrà a meno che non faccia qualcosa per cancellare quel file dalla loro cache.

Se stai facendo il versioning del tuo sito anche se potresti cambiare tutti i riferimenti css nella tua build con qualcosa come mysite.css? v = 1234 che ti permetterà di mantenere la data di scadenza lontana e non preoccuparti delle modifiche future come nel la prossima build sarà mysite.css? v = 1235.

Sì, dovresti. Per ragioni di distribuzione qui indicate da altre risposte.

Ma vedo, perché stai facendo la domanda. L'approccio delle app Web è guidato dai costi. Il suo opposto rispetto all'approccio legacy shrinkwrap, in cui i costi includono supporti fisici, distribuzione, installazione, documentazione cartacea, formazione e supporto tecnico. Tutto ciò che può essere escluso, dovrebbe essere escluso.

Per essere chiari, suppongo che tu stia parlando di un numero di versione visibile all'utente di qualche tipo e non rinunciando al controllo della versione in fase di sviluppo. (se pensi di non aver bisogno del controllo della versione in fase di sviluppo, allora hai torto, hai bisogno del controllo della versione).

Per un progetto single-hosted non è strettamente necessario, perché se sorgono delle domande puoi sempre dare un'occhiata all'host e confermare ciò che è realmente in esecuzione. È un po 'carino, però, perché potrebbe tornare utile una o due volte. Spetta a te decidere se sarà utile o meno.

Per un progetto con più host, non è davvero opzionale. Diversi host finiranno per avere versioni diverse e dovrai essere in grado di distinguerli a loro volta.