Sono stato istruito dal mio project manager che è necessario evitare frequenti installazioni in PROD o server di test. Ma non capisco perché? Portiamo la nostra copia di prova su PROD a ogni sprint, ma improvvisamente il cliente chiede una semplice modifica all'applicazione esistente che richiederebbe una nuova distribuzione. Quando ogni cosa era ben testata e approvata dal QA. perché dovremmo evitare una frequente distribuzione?
Come è stato fatto universalmente?
Se si sta parlando di un'applicazione Web ospitata, gli utenti non hanno una possibilità di dire quando ottengono gli aggiornamenti. Cioè, sono costretti ad aggiornare ogni volta che fai un push alla produzione.
Se le tue modifiche cambiano drasticamente le regole di sistema o l'interfaccia utente, dovresti assolutamente considerare di raggruppare le tue versioni e farlo meno frequentemente. È molto frustrante per gli utenti dover continuamente imparare di nuovo come utilizzare gli strumenti su cui si basano e viola il principio dell'interfaccia utente di farli sentire in grado di controllare il proprio computer / software.
se la ri-distribuzione richiede tempi di inattività, il cliente potrebbe non essere soddisfatto di ciò. Inoltre dipende dalla frequenza se è settimanale o mensile. Il mio ultimo progetto ha una finestra di interruzione regolare al 2 ° sabato di ogni mese con l'approvazione del cliente. Puoi verificare la presenza di eventuali finestre di interruzione accettate con il tuo cliente.
Ci sono sempre casi in cui si trovano problemi in prod. I deployment back to back possono rendere MOLTO più difficile in molti casi determinare l'effettiva origine dei problemi. A parte questo, distribuirò tutte le volte che tutti sono a loro agio.
D'altra parte, il cliente è il capo, se lo vuole distribuito ora senza test che è lì opzione e a meno che non ci sia qualcosa di irreversibilmente pericoloso che puoi spiegare loro riguardo al cambiamento hai poco ricorso ma per documentare la richiesta, l'approvazione e assicurarti di avere un modo per tornare indietro se non gradiscono il risultato.
Non avrai sempre un buy-in totale del processo dal client.
Perché dovrebbero essere evitate le frequenti modifiche al prod? Perché possono causare problemi di prestazioni e problemi degli utenti. Gli utenti devono essere consapevoli delle modifiche che potrebbero interessarli in modo particolare se il roll to prod potrebbe comportare un sacco di risultati delle prestazioni nel database e causare così rallentamenti. Perché agli utenti non piace quando vengono bloccati per un aggiornamento solo quando devono eseguire il libro paga. Gli utenti utilizzano spesso l'applicazione tutto il giorno ogni giorno, diventano irritabili quando si verificano molte modifiche in un breve periodo di tempo e si lamentano con i loro capi che si lamentano con il capo del tuo capo che urlerà al tuo capo.
Anche i lanci di prodotti sono rischiosi. È il posto raro che mette effettivamente alla prova l'utilizzo del livello di produzione (in molti casi non testano il codice anche nei database delle dimensioni della produzione), quindi le cose che sembrano funzionare bene in QA possono causare l'arresto dell'intero sistema in un ambiente di produzione. Quindi meno volte vai a pungolare con il nuovo codice meno volte il tuo capo è a rischio di essere chiamato sul tappeto.
Leggi altre domande sui tag project-management web-applications deployment