Qual è il punto di messa in scena?

Pensavo di averlo capito, ma dopo aver letto la consegna continua (libro eccellente) sono un po 'confuso. Parlano di avere server per:

• sviluppo
• varie forme di test automatizzati
• test di accettazione dell'utente (UAT), ovvero sedersi con il cliente e dimostrarlo a loro, e lasciargli fare test esplorativi. I tester interni potrebbero anche utilizzare questa configurazione per i test esplorativi.
• messa in scena
• produzione.

Avevo sempre pensato che la messa in scena fornisse la funzione UAT, ma sembra che la messa in scena sia un livello separato. Quindi in quello schema, quale funzione fornirebbero i server di gestione temporanea?

La stadiazione metterebbe in atto tutti i sistemi di prodotto, ma non li userebbe ancora. Quando entreranno in uso sarebbe "produzione". Dovresti mettere tutto a posto come verrà usato, testare, quindi ruotare l'interruttore.

L'UAT utilizza comunemente ambienti di "test" che sono significativamente diversi dall'hardware / software / configurazione che verranno utilizzati nella produzione.

Ad esempio, dove lavoro, i clienti testano tutto in un ambiente VM in esecuzione sui nostri server. Quando il loro sistema sarà attivo, sarà in esecuzione sul loro hardware, presso la loro struttura, probabilmente integrandosi con i loro sistemi esistenti; non avrà assolutamente nulla a che fare con i nostri server o l'ambiente di test (tranne che il codice e alcune configurazioni sono state copiate da lì ...)

Lavoro nel team di gestione delle versioni di una società Internet molto grande. Usiamo essenzialmente il processo che hai descritto sopra e abbiamo scelto quel processo di proposito. Nella nostra metodologia, la stadiazione funge da meccanismo di ramificazione per un livello finale di test in produzione.

Ovviamente vuoi fare tutti i test prima di andare in produzione, ma in un ambiente ampio e complesso con molti utenti, questo è un obiettivo molto difficile da raggiungere. In particolare, è praticamente impossibile caricare adeguatamente il software di prova nel QA. I test funzionali sono molto più facili da automatizzare rispetto ai test di carico. Quando hai migliaia di utenti che colpiscono i tuoi server, le cose falliscono in modi strani e difficili da prevedere.

Quindi, ecco cosa facciamo:

• Sviluppo
  • include integrazione continua e test automatizzati
• test di rilascio
  • il mio gruppo analizza il rilascio stesso
  • revisione dei registri di installazione
  • test di rollback
• QA
  • test di accettazione dell'utente

Questo è il punto in cui si dirama tra messa in scena e produzione. Usiamo un modello di treno per le versioni, con un nuovo treno che parte ogni poche settimane. Anche i treni numerati vanno ai server di gestione temporanea (che sono in produzione). I treni dispari non lo fanno.

Tra i treni pari, gli sviluppatori hanno la possibilità di inviare singole modifiche ai server di gestione temporanea ( ovviamente dopo che tali modifiche sono state testate dal QA). Ciò consente loro di verificare che il loro software funzioni come previsto in un ambiente di produzione reale. Questo è generalmente riservato ai componenti che sono considerati a maggior rischio, non spingiamo ogni piccolo pezzo in scena.

Quindi, tutti capiscono che quando inizia il prossimo treno pari, spazzerà via ciò che è sui server di gestione temporanea e li riporta alla linea di base del treno. Gli sviluppatori assicurano che le loro modifiche siano entrate nel treno o decidono che non sono ancora pronte per l'uso generale, nel qual caso tali modifiche vengono semplicemente cancellate sui server di gestione temporanea.

Per riassumere, la risposta breve (almeno per noi) è che è impossibile testare completamente sistemi complessi nel QA. La stadiazione offre un modo sicuro per eseguire test di produzione limitati.

Su una nota correlata, ecco le mie diapositive da una presentazione che ho appena dato su come funziona il nostro processo di rilascio.

La spiegazione più semplice per la gestione temporanea è testare il processo di distribuzione e testare utilizzando l'origine dati reale. Alcuni sistemi combinano la gestione temporanea con i loro ambienti di test, ma per i sistemi su larga scala il processo di distribuzione potrebbe essere molto complesso o potrebbero essere necessari ulteriori passaggi di test una volta effettuato il collegamento all'origine dati live / di produzione. In questi casi, un ambiente di gestione temporanea consente di testare il processo di distribuzione e verificare la presenza di bug dell'ultimo minuto utilizzando dati attivi, quindi una volta verificato che le cose funzionano, è possibile passare rapidamente dall'ambiente di stage all'ambiente di produzione.

Un esempio di questo potrebbe essere Windows Azure, che richiede 5-25 minuti per distribuire una nuova versione, ma è possibile distribuire in un ambiente di gestione temporanea, eseguire test e quindi scambiare istantaneamente gli ambienti di produzione e gestione temporanea .

Ho appena trovato questo articolo sugli ambienti di stadiazione che dice

La gestione temporanea è il luogo in cui convalidi le incognite dei tuoi sistemi.

L'articolo merita una lettura completa.