Come si affronta la gestione delle versioni per un'app Web (SaaS)?

Question

Qual è l'approccio migliore per il rilascio di una nuova versione di un'app Web ospitata e con quale frequenza di solito si rilascia? Scegli una data arbitraria, ad esempio ogni settimana, mese, ecc. Per implementare una serie accumulata di correzioni (magari utilizzando un approccio simile a L'approccio di Joel alle date di spedizione )? Aspettare molto più a lungo sembra sconfiggere parte del vantaggio principale di un'app ospitata. D'altra parte, non vorrai implementare costantemente nuove funzionalità che potrebbero confondere l'utente (ovvero se ci fosse qualcosa di diverso ogni volta che effettuava l'accesso).

Fino a poco tempo fa la mia esperienza è stata principalmente con applicazioni desktop o desktop installate. Sono curioso di vedere che tipo di gestione delle versioni le persone usano con un'app ospitata.

Answer 1

L'approccio di Google è probabilmente il migliore per l'utente finale, ma ha un costo di complessità.

Distribuiscono nuove versioni (e talvolta solo singole modifiche) su una base abbastanza costante (spesso quanto quotidianamente, a seconda del progetto). Ma ecco il kicker: solo una piccola parte degli utenti riceve la nuova versione.

Google ha un gran numero di utenti per i suoi grandi prodotti, quindi è pratico inserire regole come " 5% degli utenti dovrebbe vedere questa funzione " ;.

Possono quindi analizzare i risultati e pianificare la loro prossima versione, forse per un altro 15% della popolazione di utenti.

Answer 2

Per quanto gli ingegneri vogliano definire una routine da vivere, sarà davvero guidato dalle esigenze aziendali dietro al sistema. Dipende anche dalla natura degli aggiornamenti, ecc ...

Gli aggiornamenti di contenuto e HTML non dovrebbero essere un grosso problema da eliminare. Le modifiche alle applicazioni DOVREBBERO essere un grosso problema e passare attraverso le routine di test stabilite su un sito di anteprima prima di essere caricate dal vivo.

Una cosa è certa che devi avere un "pulito" molto modo per distribuire (e annullare la distribuzione) delle modifiche. È inoltre necessario un "facile". modo per rivedere e controllare le modifiche prima che diventino attive.

Uso di un mix di " git " e "rsync" ci consente il controllo totale sul processo. Tutte le modifiche al nostro progetto sono sviluppate in un ramo che è stato ramificato dalla "Produzione" ramo. Prima che qualsiasi modifica possa essere pubblicata, la "Produzione" il ramo deve essere completamente unito. L'atto di andare in diretta sta semplicemente fondendo il ramo appropriato in "Produzione". e risincronizzarlo sui server live. Git rende tutto molto semplice.

Ciò garantisce che le modifiche in corso non possano essere in conflitto con altre modifiche in corso.

Da quando è stato adottato questo sistema, la nostra routine di implementazione è notevolmente aumentata in termini di efficienza e chiarezza. A proposito, le nostre implementazioni vanno da più volte al giorno a una volta ogni diversi mesi. Tutto dipende. Preferirei un ciclo 1-2 alla settimana per un progetto attivo.

Answer 3

Rilascio anticipato e spesso è ciò che faccio e ciò che facciamo dove lavoriamo. Blog anche sui nostri aggiornamenti ogni volta che li realizziamo. Probabilmente è più facile per te se esegui il rollup di tutti gli aggiornamenti in un unico aggiornamento alla volta (per il QA, il rollback, ecc.) Nel miglior modo possibile. Dal punto di vista dell'utente, non credo che ci siano problemi con molti aggiornamenti. Purché non siano aggiornamenti errati. Penso che ci sia un problema se aspetti un anno intero o sei mesi e converti tutti i tuoi aggiornamenti in un'unica versione. Questo è ciò che ha ucciso un progetto su cui lavoravo (un popolare feedreader di cui probabilmente hai sentito parlare). La gente pensava che fossimo morti e la percezione divenne realtà. Siamo stati abbandonati. Quindi sono tutto per i programmi di rilascio di Firehose.

Answer 4

Ogni due settimane dovrebbe essere sufficiente, ma questo dipende molto dal tuo mercato.

Answer 5

A Planbox (SaaS di gestione dei progetti Agile basato sul web) rilasciamo ogni giorno. Possiamo farlo perché la maggior parte della nostra logica applicativa e tutta la nostra logica di presentazione sono nel front-end (Javascript). Anche l'HTML viene generato tramite Javascript utilizzando un motore di template. Ma il backend (PHP) e la sua API REST raramente cambiano. Questo ci consente di inviare nuove versioni del client in qualsiasi momento senza interrompere la compatibilità.

Se riesci a passare a tale architettura, risparmierai tonnellate di tempo e otterrai molta efficienza.