Mantenere aggiornate le versioni DLL

Question

Mantenere aggiornate le versioni DLL

#1 da (0 voti)

-1

Ho un'applicazione c # multilivello abbastanza semplice, con diversi livelli di presentazione in ASP.net MVC (2 siti Web diversi e un'API separata) e un'applicazione desktop. L'applicazione desktop è installata su 20 computer dell'utente finale.

I dati (EF), entità e livelli di servizio sono condivisi da tutti i livelli di presentazione in quanto vi è una grande quantità di crossover e nella maggior parte dei casi è solo la vista o la logica di autenticazione che cambia. La mia domanda riguarda gli approcci di best practice per mantenere sincronizzate queste DLL. Quando si aggiorna il codice per un mchange a una delle UI, deve attivare una distribuzione di tutte le interfacce per garantire la coerenza? In tal caso, quali strumenti di automazione sono disponibili (principalmente pensando ai siti Web ospitati su Azure, l'app desktop viene sempre distribuita manualmente)

c# deployment

posta Macros 10.05.2017 - 14:18

fonte

1 risposta

Leggi altre domande sui tag c# deployment

Come implementare uno scalabile esiste nella query set di grandi dimensioni Come si chiama questo comando?

score 0 · Answer 1

Il mio primo riflesso qui sarebbe di trattare ogni applicazione come entità atomica. Se le parti condivise sono molto grandi (il che sembra essere il caso), coordinerei l'implementazione tra tutti e aggiornarle tutte insieme. Questo approccio funziona bene con ClickOnce per esempio.

Potresti anche seguire il percorso di aggiornamento continuo, ma tende a essere meno stabile in quanto distribuirai componenti meno testati. Se scegli l'implementazione continua avrai bisogno di schemi e convenzioni solidi per il controllo delle versioni e dovranno essere seguiti con ferocia. Ci saranno dei momenti in cui i cambiamenti nella DLL indurranno cambiamenti di rottura in altri componenti presenti, quindi ancora una volta il coordinamento e le versioni di packaging consentiranno di inserire test aggiuntivi prima di rilasciarli. La parte più importante di uno schema di implementazione continua è di gran lunga la possibilità di eseguire rapidamente il rollback di una versione nel caso in cui venga eseguito il sud in modo da garantire il coordinamento del rollback su tutti i livelli contemporaneamente o garantire un'architettura sufficientemente solida per consentire i livelli condivisi (Server ) per servire clienti di varie versioni.

Quindi, in breve, l'opzione più semplice è quella di raggruppare un gruppo di modifiche insieme e impacchettare ciascuna applicazione in modo da rilasciarle simultaneamente. Il vantaggio aggiunto è che il controllo delle versioni può essere unificato se questo è qualcosa che il tuo team ritiene importante.

Qualsiasi altra cosa vedo come fondamentalmente un'ottimizzazione di questa situazione di base.