Spingere il codice non testato, non provato, non utilizzato alla produzione con una prospettiva di utilizzo futuro

0

Innanzitutto, lasciatemi affermare chiaramente che sono completamente contrario a questo, ho problemi reali con codice inutile, obsoleto, non testato, merdoso, specialmente quando finiscono su un sistema di produzione. Il mio background è in build e release management / devops e ora sto lavorando come consulente tecnico a supporto di un team di sviluppo in outsourcing.

Lo scenario è questo;

Abbiamo un sistema MI che ha pubblicato i dati da circa 200 tabelle di origine in 200 tabelle di destinazione in base a una singola stored procedure "dinamica" che genera ed esegue le istruzioni MERGE (per ogni tabella). Il contenuto di queste istruzioni MERGE è guidato da varie tabelle di configurazione (da origine a destinazione a livello di colonna).

Anche se non sono un fan completo di questo modo di fare le cose, è in vigore dalla prima release (anni) e funziona ed è ben collaudato, e sorprendentemente ben scritto dato cosa / come fa.

Esiste un progetto separato che ha l'obiettivo di rivedere il sistema nel suo complesso e apportare miglioramenti delle prestazioni ove possibile. Assolutamente nessun problema con l'obiettivo qui.

Come parte di questo progetto, c'è stata una discussione che forse l'affermazione MERGE dinamica potrebbe essere più performante come una stored procedure statica. Forse potrebbero esserci dei miglioramenti memorizzando nella cache i dettagli di esecuzione, ecc. Io non sono un DBA, ma l'idea generale sembra fattibile. Possiamo fare un'analisi approfondita di ogni tabella e, se possibile, sintonizzare (aggiungere ulteriori indici).

Sebbene la conversione di alcuni elementi dinamici potrebbe avere senso, forse questo non è adatto a tutti e aggiungere gli artefatti e convertire tutti in statico è un sovraccarico che potrebbe non essere necessario. Quindi, per supportare questo, abbiamo discusso un'estensione del framework di configurazione esistente che consente un passaggio tra dinamico e statico. Tutto bene qui finora.

Passiamo quindi all'argomento del test e alla convalida della prestazione su larga scala. Generalmente l'approccio a questo era soddisfacente, ma ci sarebbe stato un ritardo nell'ottenere un ambiente adatto, con un set di dati adeguato (stiamo parlando di miliardi o righe / terabyte di dati)

Recentemente ho scoperto che l'intenzione è di implementare l'estensione al framework di configurazione e spingere questo live, senza veri test e nessuna convalida dei guadagni in termini di prestazioni. La ciliegina sulla torta per me è che non sarà effettivamente abilitato.

Il nostro processo di implementazione è attualmente piuttosto complesso e i rilasci alla produzione vengono eseguiti in modo standard indipendentemente dal payload. C'è una versione pianificata tra qualche mese e queste modifiche saranno pubblicate. La prossima versione non ha un programma go-live. Tutte le modifiche come questa avvengono come una distribuzione DACPAC, quindi se ci sono cambiamenti o meno, il processo confronterà il DACPAC con la produzione per ciascun componente.

Quindi, tra questa versione e quella successiva, queste modifiche esisteranno, non testate, ma inutilizzate, mentre viene eseguita l'analisi. Una volta completata, la prossima versione aggiornerà i dati di configurazione e tutti gli artefatti di supporto.

Sembra che stia combattendo una battaglia persa per convincere il project manager (tecnico) della terza parte che questo non è un buon approccio e abbiamo semplicemente chiesto perché non poteva essere rilasciato una volta che l'analisi è stata fatta, in la prossima versione (se applicabile ancora)

In genere sono curioso di sapere se sono troppo soggettivo per questo e non è davvero un grosso problema. Ho appena inviato un'altra email a una vasta cerchia di persone che hanno chiarito le mie preoccupazioni e sarà interessante vedere la risposta, suppongo che sarà sulla stessa linea di ciò che stiamo facendo comunque.

Qualche idea o commento?

Grazie

    
posta ChrisBint 19.07.2017 - 11:02
fonte

4 risposte

3

La tua soluzione tecnica esatta e l'implementazione sembrano un po 'di nicchia. Ho comunque lavorato per un'azienda in cui mettere qualcosa in diretta in uno stato spento era comune. Nel nostro caso si trattava di un'applicazione winforms con un flag nel database o di un file di configurazione che poteva attivare e disattivare la funzione, ma spero che alcune delle mie esperienze possano aiutare con i problemi che stai vedendo qui.

THE GAIN

Una volta che il codice è stato pubblicato, anche se non viene utilizzato, è un segno di spunta in una casella e la distribuzione è stata almeno dimostrata. Questo, tuttavia, è l'unico lato positivo.

THE PAIN

Revisioni minori interrompono la nuova funzionalità

Una volta che il grande cambiamento è entrato, a volte anche il più semplice cambiamento successivo può far svelare questo. Poiché il grande cambiamento non è in realtà dal vivo, spesso viene perso nei test o non è considerato nei progetti successivi.

YAGNI

Non dovresti scrivere codice se non ne hai bisogno. Se ne hai bisogno, dovresti distribuirlo. Se hai ritardato l'attivazione del nuovo codice, potrebbero essere venuti alla luce nuovi requisiti, il che significa che il codice avrebbe potuto e avrebbe dovuto essere scritto meglio.

Debito tecnico

Questo in qualche modo è il peggior risultato. Il nuovo codice non è mai attivo. Le priorità maggiori arrivano e il nuovo codice è parcheggiato. È troppo rischioso eseguirne il backup e quindi rimane nella distribuzione, intasando il codice base e la risorsa di hogging.

Performance

Anche se la nuova funzione non è visibile. A volte l'elaborazione correlata avviene ancora dietro le quinte, il che significa che l'applicazione degrada. Per quanto riguarda l'utente, questo è perdere-perdere. Non ci sono nuove funzionalità eppure il sistema sta funzionando più lentamente.

L'avanzamento non riesce

A causa di piccole modifiche successive o circostanze impreviste sul sistema live, a volte lo switchover fallisce semplicemente. Lo scenario migliore qui è che puoi semplicemente spegnerlo di nuovo ma se i dati sono interessati potresti avere un grosso problema a portata di mano.

SOMMARIO

Come tutte le cose di questo genere, se si spegne - sembra pura brillantezza. L'uscita è arrivata in anticipo e un interruttore magico rende la nuova funzionalità appena funzionante. Ma succede raramente in questo modo. Anche se così fosse, i rari guasti dovrebbero immediatamente impostare campanelli d'allarme che denotano una scarsa pratica di implementazione.

    
risposta data 19.07.2017 - 12:00
fonte
1

... single 'dynamic' stored procedure that generates and executes MERGE statements ...

... dynamic MERGE statement might be more performant ...

... the intention is to ... push this live, with no real testing, and no validation of the performance gains.

Domanda: importa se questa "alternativa" non testata rovina i dati o viene eseguita molte volte più lentamente del metodo corrente?

Dubito che uno di questi sia accettabile e che entrambi / diventerebbero evidenti nel test.

So between this release and next, these changes will exist, untested, but unused, while the analysis is performed. Once complete, the next release will update the configuration data and any supporting artefacts.

Non sarà "inutilizzato".

sarà eseguito, in produzione e aggiornando i dati mentre lo fa, al fine di capire se funziona e, supponendo che lo faccia, se c'è qualche migliore / peggiore dell'originale.

I appear to be fighting a losing battle with regards to convincing the (technical) project manager of the third party that this is not a good approach and have simply asked why it could not be released once the analysis has been done, in the next release (if applicable still)

O, in altre parole, perché non può essere testato prima di essere messo in produzione?

Potrebbero argomentare che la dimensione dei dati che stai operando preclude l'uso di un ambiente di test, ma ciò suggerirebbe anche che i tuoi ambienti di test non sono rappresentativi della produzione, e questo è un altro problema.

    
risposta data 19.07.2017 - 13:09
fonte
0

I miei pensieri non dovrebbero mai essere mandati in produzione senza una raffica di test, nemmeno i test unitari standard. Questo non è diverso. È proprio questa supposizione che niente andrà storto creando spazi in cui gli insetti possono penetrare all'interno. Anche se non non ci sono bug, istanze ripetute come questa indicano solo che è una domanda di quando non se .

Forse non puoi impedire che questo entri in produzione, ma puoi mettere il piede in basso per assicurarti che venga testato, considerando che il tuo consiglio tecnico ha qualche peso in merito.

Ancora meglio, questo sviluppo dovrebbe essere in un ramo fino al giorno in cui questo sarà effettivamente utilizzato nella produzione in modo che non ci sarebbe alcun impatto se le modifiche non fossero mai realmente necessarie. E, naturalmente, se e quando i cambiamenti devono essere portati in produzione, le modifiche devono essere integrate nel bagagliaio, verificate di nuovo una volta di più in stati disabilitati e abilitati, spinte alla produzione disabilitate e abilitate in un momento opportuno. Questo non eliminerà del tutto la possibilità di bug, ma dovrebbe certamente minimizzare i problemi.

    
risposta data 19.07.2017 - 12:42
fonte
0

Sono in gran parte d'accordo con i miei colleghi Nulla dovrebbe mai essere messo in produzione senza essere stato accuratamente testato, tuttavia questo è l'idealista in me che parla, il lato realistico di me dice che succede e succede molto. c'è il rischio che, se il codice non viene commentato correttamente, si potrebbero avere problemi di produzione, ma il guadagno è che il rilascio può andare avanti rapidamente senza risme di test di regressione. Tuttavia, riprendendo questo approccio, riempiendo il database con un sacco di codice ridondante che potrebbe non essere mai utilizzato, non è una buona pratica.

Non penso che tu stia superando la situazione e sono d'accordo con i tuoi principi, ma penso che tu debba giungere a un accordo pragmatico sulla via da seguire.

    
risposta data 19.07.2017 - 15:32
fonte

Leggi altre domande sui tag