Spostando il codice in produzione senza rompere le funzionalità esistenti? [chiuso]

-1

Come si può spostare il codice di sviluppo / test in produzione e non finire per rompere la funzionalità nell'ambiente di produzione? Sto lavorando con un'azienda di piccole dimensioni, quindi non hanno un budget per un ambiente di test.

Il mio obiettivo è spostare il codice in produzione e non compromettere l'esperienza dell'utente. Dato che in un ambiente di produzione, non posso davvero creare record fittizi da elaborare, perché l'applicazione coinvolge l'interazione con fornitori terzi.

Qualche suggerimento? Per questo particolare esempio, diciamo web, MS.Net, non cloud. Ma anche se si tratta di una best practice generale su come spostare il codice, sarei interessato a impararlo. Un sacco di persone di livello C che non sono techies, si aspettano che le cose funzionino senza intoppi, quindi quando le cose si rompono, inizia un dito puntato.

    
posta OOP Newbie 21.09.2014 - 20:22
fonte

2 risposte

4

L'unico modo per ridurre il rischio di rompere le cose in produzione è testare le nuove versioni prima della distribuzione. Punto. E se il tuo budget per i tester è piccolo, prova a creare il maggior numero possibile di test automatici. Scopri le unit test, il test di integrazione automatica, TDD e allena la tua squadra con queste tecniche: queste sono cose che possono essere stabilite perfettamente in una piccola squadra. E se ritieni che i test siano ancora costosi, confronta questo con i costi quando la produzione si interrompe per un giorno.

Tuttavia, nessun test può comportare il rischio di rompere completamente le cose a 0. Quindi quello che dovresti sempre avere è una buona strategia di fallback - se si scopre che la nuova versione ha rotto qualcosa inaspettatamente, dovresti sempre avere la possibilità per tornare alla versione precedente del software il prima possibile. Questo è principalmente un compito organizzativo, ad esempio: assicurati che ogni release sia archiviata da qualche parte, assicurati che le persone che sanno installare il software o la versione precedente non vadano in vacanza il giorno dopo la distribuzione, assicurati che il database sia immediatamente salvato prima della distribuzione, semplificare il processo di installazione e così via.

Ecco una vecchia domanda PSE che si occupa della domanda su cosa fare quando le cose si rompono in produzione. Nota che questo post presuppone che sia un ambiente di test.

    
risposta data 21.09.2014 - 21:28
fonte
1

they don't have a budget for a Test environment

Se hanno il budget per un ambiente live e uno sviluppatore, possono trovare il budget per un ambiente di test. Il costo degli errori nell'ambiente live è più costoso rispetto al pagamento di un ambiente di test in anticipo. Un ambiente di test può essere un clone ridimensionato di un ambiente live. In una configurazione virtuale come AWS, i sistemi di test possono essere disattivati quando non sono in uso, con un costo di $ 0 la maggior parte del tempo.

Collabora anche con i fornitori di terze parti per utilizzare i loro ambienti di test o almeno impostare i dati di test nel loro ambiente live.

    
risposta data 21.09.2014 - 22:08
fonte

Leggi altre domande sui tag