Con quale frequenza dovrebbero essere implementate le applicazioni interne? [chiuso]

Nel mondo del software commerciale, le pianificazioni di rilascio sono legate a:

1. Timeline di sviluppo (Quanto tempo è necessario per creare ogni versione o patch?)
2. Test e timeline QA (Quanto tempo è necessario per testare, qualificare e certificare che l'app funzioni correttamente su tutte le piattaforme e in tutte le modalità in cui verrà normalmente utilizzata, spesso include "integrazione", " stress, "e" accettazione "test, non solo unit test)
3. Cicli di vendita e marketing (Quanto tempo ci vuole per creare o accettare la nuova versione?)
4. Cicli di aggiornamento del cliente (quanto spesso i clienti desiderano nuove versioni? A che punto dei loro cicli economici possono accettare nuove versioni / funzionalità? I rivenditori, ad esempio, bloccano tutti gli aggiornamenti non urgenti durante l'intero mese "di Natale stagione ")
5. Integrazione di training e supporto (Quanto tempo è necessario per documentare nuove funzionalità / correzioni, addestrare sia gli utenti interni che gli utenti finali e far sì che il tuo team di supporto acceleri sulle modifiche?)

Tradizionalmente le versioni sono un grande affare, sia per lo sviluppatore del software che per i clienti. Quindi i cicli di rilascio di 1-3 anni tra versioni "principali" sono stati comuni, con rilasci "minori" o "punti" ogni 3-6 mesi e patch di emergenza in base alle necessità.

I negozi di Cloud e SaaS (software come servizio) sono l'estremo opposto, spesso aggiornano "slipstream" senza mai dire a nessuno (forse il personale di supporto, ma non sempre anche in quel momento). Conosco negozi che effettuano aggiornamenti una volta alla settimana, in un giorno fisso. Gli altri si aggiornano più volte al giorno.

Sei un piccolo negozio con un'app interna, quindi non esiste un vero ciclo di vendita / marketing. Non sembra esserci alcun supporto ufficiale o test / funzione QA tra utenti e sviluppo. I tuoi cicli di sviluppo sembrano brevi e le tue implementazioni facili. Quindi puoi eseguire l'iterazione con la stessa rapidità consentita dalla tua community di utenti.

Essendo stati in questa situazione, alcuni suggerimenti:

1. Solo perché non hai un test ufficiale / organizzazione QA non significa che devi evitare i test. Per favore, per favore, si prega di avere una suite di test automatizzata che si esegue prima di ogni rilascio. Questo può farti risparmiare un mondo di dolore in seguito.
2. Solo perché puoi silenziosamente "slipstream" nuove funzioni o patch non significa che dovresti. In realtà, non dovresti. Avere una versione reale o un numero di rilascio su OGNI versione. Ciò renderà più facile rintracciare gli errori. (Vedi ad esempio versioning semantico per informazioni dettagliate su come strutturare i numeri di rilascio.)
3. Avere una pagina Web dell'app o "sull'app questa app" che mostra gli aggiornamenti recenti della versione. Mostrare agli utenti ciò che è "nuovo e notabile" è una delle cose che i progetti open source aggiornati velocemente hanno imparato ad aumentare la fiducia e il comfort degli utenti con il processo di aggiornamento.

Stai facendo la domanda sbagliata.

»La frequenza con cui devono essere implementate le applicazioni interne« ha molte implicazioni che sono svantaggiose, ad es. se hai un ciclo di rilascio - diciamo 1 settimana - ci sono forse piccole ma importanti modifiche, che devono aspettare 6.x giorni alla prossima versione.

Sarebbe una buona pratica rilasciare tutte le volte che si ha qualcosa da rilasciare: che a volte potrebbe essere una volta ogni due giorni o due volte al giorno; a seconda del tuo flusso di lavoro. Se disponi di funzionalità che non sono sufficientemente testate, puoi implementare opzioni-toggle (ad esempio, i valori di configurazione in un DB che de- / attiva caratteristiche). Quindi potresti facilmente passare alla produzione. E se ti rendi conto che la nuova funzione non si comporta come volevi, puoi tornare indietro con la stessa rapidità con cui avvii l'interruttore delle funzioni.

My fear is that the expectation is starting to be created that tweaks can be done and pushed out the same day.

Perché dovrebbe essere un problema? Se puoi fare la correzione, perché aspettare di rilasciarlo?

Even if I can fix a small bug or add a small feature and deploy within an hour that could be perpetuating the habit of walking up to my desk and staff saying "Can we move x to this side of the page by tomorrow?"

La stessa domanda: perché questo è un problema?

L'unico problema che hai è comunicazione . Devi guadagnare credibilità: se dici, potrebbe essere risolto entro 10 minuti e tu lo spingerai alla produzione in 10 minuti, tutto andrà bene. Ma d'altra parte, se dici che ci vogliono 5 giorni, dovresti avere così tanta credibilità, che tutti sanno, che ci vogliono 5 giorni. Sei responsabile, hai fissato le scadenze. E tu sei responsabile di comunicarlo. Questo è spesso un processo doloroso per entrambe le parti - ma alla fine: entrambe le parti vincono. Come professionista, devi comunicare, per quanto tempo ci vuole qualcosa. La gestione non scrive software, gli utenti non scrivono software, scrivono software.

What can I expect to see as I continue in my career in terms of internal applications? Are there best practices for deployment of internal tools? Are they treated any differently?

Non posso prevedere, dove stai andando. Ma in alcune parti del settore, quello che ho descritto vagamente è noto come un processo chiamato dispiegamento continuo e guadagna sempre più attenzione.

Sospetto strongmente che la risposta dipenda interamente da quanto doloroso (o indolore) sarà l'aggiornamento di 30 persone alla versione più recente.

Più facilmente esegui l'upgrade, meglio sarà con un programma di rilascio rapido. Più è doloroso, più beneficerai di un programma di rilascio regolare.

Dipende solo da te.