Testare più versioni in accettazione

3

Introduzione Sto lavorando a una società di software che costruisce software come servizio. Attualmente abbiamo la versione x.y in produzione e x.z in accettazione. Diciamo che troviamo un bug critico sulla produzione e vogliamo testare la correzione su un ambiente di accettazione. Non so come lavorare con questo.

Opzioni

  1. Crea un secondo ambiente acc per x.y
  2. Sovrascrivi l'attuale ambiente di accettazione con x.y
  3. Risolvilo in x.z e distribuisci il più presto possibile su acc e prod
  4. Altro

Per me l'opzione 1 è la più sicura, ma non vedo nessun altro farlo (forse non sto guardando abbastanza bene). Come fanno le altre persone a fare questo? C'è qualche documentazione su questo?

    
posta user369117 25.03.2017 - 01:50
fonte

3 risposte

2

Tutto dipende da quanto è facile cambiare l'ambiente di accettazione.

Se la distribuzione in ambiente di accettazione è semplice ...

... ad esempio se devi solo sostituire gli eseguibili, puoi prendere in considerazione opzione 2 :

  • sovrascrive l'accettazione corrente
  • effettua il test
  • distribuisci la versione corretta
  • ridistribuisci (o esegui il rollback) la versione corrente in fase di sviluppo
  • continua lo sviluppo dell'accettazione

Se la distribuzione all'accettazione è più delicata ...

Sfortunatamente molte applicazioni aziendali complesse sono più delicate da implementare: potrebbe essere necessario installare un set di librerie o plugin dinamici dipendenti, o potrebbe essere necessario aggiornare alcuni file di configurazione, ecc .... Questo rende rischioso tornare indietro e avanti

Lo showstopper è quando c'è un database, e una versione diversa potrebbe far fronte in modo diverso con i dati persistenti. L'accettazione prevalente potrebbe in questo caso portare a incongruenze persistenti.

Pertanto, l'approccio più sicuro è scegliere l'opzione 1 . Questa è la procedura standard per l'aggiornamento dei principali sistemi ERP, quando l'intera azienda dipende dall'ambiente di produzione. Lì, l'accettazione del clone viene persino creata all'inizio dell'aggiornamento, solo nel caso di ...

Questo approccio è anche il più costoso. Ma se la tua azienda ha un datacenter professionale, dovrebbero essere in grado di virtualizzare tale ambiente e ripristinare le vecchie immagini con estrema facilità e senza enormi costi generali.

Se i rischi sono bassi ...

Ultimo ma non meno importante, una valutazione del rischio potrebbe considerare che la patch è una modifica minore senza rischi reali. In questo caso, una procedura di eccezione potrebbe portare a uno sviluppo diretto (opzione 3). Ma anche se si tratta di una pratica conosciuta, non posso raccomandare questo per i sistemi critici, tranne in rare eccezioni dove non c'è altra alternativa.

    
risposta data 25.03.2017 - 12:35
fonte
2

Questa è sempre una questione di soldi. Se non è una domanda sul denaro, inquadra comunque i termini del denaro.

Se il costo per creare un ambiente è basso, ad es. girando dozzine di macchine virtuali da script di build, quindi rendili quando necessario. Il costo è basso e paga per i benefici.

Se il costo di creare un ambiente è elevato, ad es. montare una scimmia antigraffio di scorta o inserirla in una nuova portaerei, allora non lo farai. Scegli "aggiusta in x.z" perché è la risposta ovvia.

Al di fuori dei casi estremi, con una vaga idea di "quanto costa un costo di creazione di un ambiente", "quanto costa questo bug al giorno" e "quanto costa per un cliente essere inattivo" può migliorare notevolmente la scelta dei compromessi.

Le equazioni cambiano man mano che la tua azienda cambia. Una progressione comune per i servizi software è quella di hackerare in diretta quando ci sono alcuni sperimentatori sul tuo alpha, distribuire automaticamente da GIT sui tuoi primi clienti, quindi aggiungere la distribuzione solo dopo i test, quindi aggiungere la distribuzione con il rollback automatico sugli arresti anomali, quindi aggiungi distribuzioni progressive con rollback automatico al declino delle metriche chiave. La cura e il costo extra sono giustificati in ogni fase dal maggior costo delle interruzioni.

Motivo con numeri. Preferibilmente dollari.

    
risposta data 25.03.2017 - 18:11
fonte
0

Hai bisogno di più ambienti.

Ho lavorato in luoghi con oltre 50 ambienti di test; che era un po 'eccessivo a mio parere, ma ha funzionato per loro.

Penso che sia necessario almeno 2 se si sviluppano continuamente funzionalità. 1 per distribuire e testare continuamente la versione di sviluppo e 1 per testare rilasci, hotfix, retrocompatibilità, stress test ecc durante lo sviluppo.

Quindi probabilmente vuoi anche un ambiente demo che i venditori possono usare per mostrarlo ai potenziali clienti, magari uno con i servizi derisi in modo da poter eseguire rapidamente i test dell'interfaccia utente?

Una volta implementate le installazioni automatizzate nell'infrastruttura cloud, la tentazione è sempre quella di aggiungere sempre di più! Ma ricorda, qualcuno deve mantenerli tutti e questo può essere un rompicoglioni

    
risposta data 25.03.2017 - 17:47
fonte

Leggi altre domande sui tag