Architettura per mantenere / eseguire più versioni della stessa strategia / funzionalità nell'applicazione live

Question

Architettura per mantenere / eseguire più versioni della stessa strategia / funzionalità nell'applicazione live

#1 da (1 voti)

4

Quindi sto lavorando con un cliente che ha una vecchia applicazione che ha alcune stranezze interessanti. Tra le altre cose, ha un proprio sistema di versioni di codice per le funzioni aziendali, memorizzando l'intera versione dell'algoritmo in un database. I dati vengono quindi recuperati e compilati su richiesta (questa è un'applicazione web, e sì, compila un sacco di codice ogni volta che provi ad acquistare qualcosa).

Per ovvi motivi, questo non è esattamente veloce. Sto cercando di migrare il codice in normali progetti di codice, ma come potete immaginare, questo crea una sfida interessante per quanto riguarda le versioni degli algoritmi.

È un requisito aziendale che le citazioni / offerte precedenti in revisione debbano utilizzare lo stesso algoritmo utilizzato al momento della creazione. Detto preventivo dovrebbe quindi essere in grado di ricalcolare, con input modificati, ecc (quindi non possiamo semplicemente archiviare i risultati).

Come affronteresti questo problema? Stanno avendo enormi problemi nella produzione ora che ho semplicemente deciso che creeremo un hot-fix spostando tutto il codice su librerie e funzioni di chiamata reali con il controllo delle versioni dei nomi (alcuniAlgortihm6Jun2014 o qualsiasi altra cosa) che risolveranno il problema dell'immenso uso della banda e tempo di compilazione sprecato, ma è tutt'altro che elegante.

Mentre cercherò di implementare cambiamenti architettonici molto più grandi in futuro, per ora sto semplicemente cercando un buon modo per mantenere più versioni dello stesso algoritmo nel codice statico, senza ricorrere a questa convenzione di denominazione. Pensieri?

versioning architecture .net

posta Marius Brendmoe 24.06.2014 - 13:39

fonte

1 risposta

Leggi altre domande sui tag versioning architecture .net

Perché la complessità temporale di k-way merge sort O (nk ^ 2)? Che cosa esattamente io / la mia azienda devo fare "rendere disponibili / pubblicare" le modifiche al codice sorgente e soddisfare GPL / LGPL

score 1 · Accepted Answer

Per quanto ho capito, non c'è alcuna manutenzione per quelle versioni precedenti - solo per la versione più recente (la modifica della versione precedente è vietata , giusto?). Ciò significa che, anche se i nomi delle funzioni diventano molto tecnici dopo versioning, questo non dovrebbe essere un problema, dal momento che non dovrai mai più toccare quel codice.

Devi archiviare le funzioni in forma compilata dal database, quindi il posto più ovvio è in un assembly della tua applicazione. Inserisci le versioni precedenti di tali funzioni in un assembly separato, come parte del processo di controllo delle versioni, in modo da metterle fuori strada quando apporti modifiche alla versione più recente.

Utilizza uno schema di denominazione rigoroso per le tue funzioni in base ai tuoi requisiti aziendali (deve esserci anche un modo per i tuoi utenti di distinguere tra le funzioni più vecchie e quelle nuove - perché non nominare semplicemente le tue funzioni con un tipo di prefisso in base al tuo schema di utenti di "fare cose")? Se il criterio è una data, allora è la data che ottiene parte del nome della tua funzione - se è usata nel processo di produzione, sarà la migliore che riuscirai a trovare. E invece di una grande pila di if / else / switch / case, usa un tabella di invio .

Se ciascuna delle tue "funzioni" non è in realtà solo una funzione, ma un sacco di funzioni e dati, puoi anche considerare di incapsularli in oggetti di comando o di strategia (come alcuni commentatori hanno suggerito). Ciò sposta il problema di versioning e naming dal livello di funzione al livello di classe. L'idea generale è la stessa.

Potrebbe anche essere interessante sapere come e quanto spesso vengono create nuove versioni delle tue funzioni. È fatto solo manualmente da uno sviluppatore? Quindi il versioning di una funzione può anche essere fatto manualmente (forse supportato da alcuni strumenti self-made, rinominando la funzione in palio, spostando il codice sorgente nel "progetto delle versioni versioned" ed estendendo la tabella di invio).

C'è un'altra opzione, ovviamente: mantieni tutto nel database dove è ora, ma memorizza in cache l'output compilato localmente. Quindi, prima di ottenere il codice sorgente e di compilare di nuovo la stessa funzione, controllare se è già disponibile un pendente memorizzato nella cache locale, e in tal caso, utilizzare la copia dalla cache (si dovrebbe fare un test del checksum per assicurarsi che la copia compilata locale sia correlata a il codice sorgente nel tuo db). Ciò non impedirà la compilazione e l'accesso al database completamente, ma potrebbe probabilmente essere la soluzione che stai cercando. E ha il vantaggio di poter distribuire facilmente nuove funzioni o versioni di funzioni in produzione senza distribuire l'intera applicazione.