Sviluppare con fiducia senza un vero ambiente di sviluppo

12

Di recente sono stato assunto per un progetto che prevede la collaborazione con e intorno a diversi sistemi "enterprise" di terze parti. A causa di quello che immagino sarebbe il costo e lo sforzo astronomici necessari per costruire una replica sufficientemente fedele dell'ambiente di produzione, la prospettiva di avere un vero ambiente di sviluppo sembra svanire in modo sottile.

Questo ovviamente non è l'ideale. Il lato positivo, immagino che debbano esserci persone là fuori che testano e implementano in modo sicuro software in ambienti non replicabili come questo, e probabilmente posso seguire le loro orme.

Come lo fanno quelli che affrontano efficacemente questo tipo di situazioni?

testing development-process

— Jason Swett
fonte

1

La virtualizzazione, con ambienti "simili a" ecc. In sostanza, prova a replicare ciò che puoi, su scala minore, per coprire almeno la maggior parte delle "parti mobili" del sistema.

— Oded,

6

Devi fare affidamento sulla correttezza dell'API del sistema aziendale e fare molti test di integrazione, magari con alcuni account di prova.

— Robert Harvey,

@RobertHarvey è morto qui. Qualcuno dovrebbe spiegarlo in una risposta, ma questo è esattamente ciò di cui hai bisogno. In assenza di un ambiente per testare manualmente il sistema, tutto ciò che puoi fare è testare automaticamente il codice.

— Jimmy Hoffa,

1

Va bene, quindi forse un buon punto di asporto è che se non si può avere un ambiente di sviluppo completo, i conti di prova in produzione possono essere la cosa migliore da fare.

— Jason Swett,

9

Questo succede sempre nel mondo reale. Conosco un tizio che scrive app che controllano gigantesche serre agricole: ventilazione, riscaldamento, controllo dell'umidità, lo chiami. Non ha una "serra di prova", ma ha un programma di simulazione fornito dalla società che costruisce i sistemi hardware reali. Se il codice funziona correttamente con il simulatore, si presume che funzioni correttamente con l'attrezzatura reale. In rare occasioni il simulatore risulta essere sbagliato, ma questo è il problema dell'azienda serra-hardware da affrontare, perché non simula correttamente.

— Ross Patterson
fonte

L'OP non sembra avere la garanzia di un "simulatore". Inoltre, nel tuo caso, il datore di lavoro del tuo collega probabilmente potrebbe richiedere un risarcimento se il simulatore fallisce. Cosa può fare l'OP in una situazione simile? Dare fastidio alla compagnia assicurativa?

— K.Steff,

4

Se l'OP non ha un simulatore, deve acquisirne uno - beg / rubare / prendere in prestito / costruire - non importa. Quanto deve essere bravo un simulatore - questo è qualcosa che deve decidere, e se ne sente il bisogno, può / dovrebbe parlare con una compagnia assicurativa di una piccola cosa chiamata indennizzo.

— Mattnz,

3

Queste sono situazioni in cui la documentazione API, i documenti di controllo dell'interfaccia e gli emulatori sono fondamentali. In una società per cui ho lavorato in precedenza, ciò è effettivamente accaduto, ciò sarebbe accaduto frequentemente all'interno di un progetto durante alcune fasi di integrazione in cui un segmento era pronto, ma altri erano dietro, ha un'altra funzione su cui si sta lavorando o per qualche altro motivo che non è stato possibile implementare l'ultima versione del loro segmento al nostro sistema di test. Quindi sì, avevamo effettivamente una replica fedele del nostro ambiente di produzione su cui abbiamo testato; tuttavia, in pratica tutti i segmenti non erano mai pronti nei tempi previsti, ma le interfacce erano state concordate e bloccate prima dell'inizio dello sviluppo ed erano stati creati emulatori che potevano per la maggior parte imitare il comportamento degli altri segmenti.

Come ha affermato un'altra risposta, l'emulatore è ciò che consentirà di eseguire i test prima della distribuzione. Un buon emulatore; tuttavia, dipende da interfacce e documentazione ben definite.

— Fred Thomsen
fonte

1

Sono in tali situazioni tutto il tempo.

Sicuramente non è necessario interagire con l'intera applicazione, ma probabilmente alcune interfacce di qualche tipo. Assicurati di avere la documentazione confermata e dettagliata delle interfacce, quindi imposta i mock di queste interfacce solo per verificare che il tuo codice aggiunto / modificato funzioni nel modo previsto.

Puoi anche fare un ibrido. Prova a replicare le parti che puoi piuttosto facilmente fare, quindi "connettiti" ai sistemi reali (se ciò è possibile nella tua situazione). L'ho fatto con un certo successo - in alcuni casi in cui la mia logica e il software server sono stati eseguiti localmente, ma avevo ancora una connessione al sistema ERP reale per verificare le invocazioni ecc. Non è l'ideale, ma le cose raramente lo sono.

Dato che hai solo un sistema di produzione con cui lavorare - tieni presente che non puoi contare solo i tempi di sviluppo risparmiati sull'impostazione di una replica, ma devi tenere conto del rischio aziendale di utilizzare codice ampiamente non testato con dati aziendali in tempo reale. Il tuo codice sarà meno affidabile del codice testato su una replica. I sistemi possono essere inattivi per qualche tempo? Possono essere ripristinati in caso di corruzione dei dati? Quanto costa?

Una best practice nelle imprese è creare una replica (o forse più di una) della produzione nel momento in cui l'ambiente di produzione è installato. In quel momento, il costo aggiuntivo non sarà così grande.

— Petter Nordlander
fonte

1

Il nostro sistema funziona con una serie di grandi sistemi esterni. Combiniamo i seguenti approcci quando li testiamo se non disponiamo di una configurazione end-to-end completa:

Registra e riproduci dati reali. Registra dati reali (richieste / risposte da sistemi esterni reali), parametrizzali se necessario e riproduci
Costruisci o acquista un simulatore che funge da sistema esterno
DSL per la generazione di dati di test. Per i sistemi basati sui dati, scrivere DSL di alto livello per generare dati di test.

— dzieciou
fonte