Modo corretto di distribuire e testare le applicazioni ASP.NET con i database nel 2017

-1

Attualmente sto sviluppando un'applicazione ASP.NET abbastanza ampia che utilizza SQLExpress come database sottostante. Il progetto è attualmente in fase di strong sviluppo ed è coperto dai test delle unit test e della regressione . Subversion (SVN) viene utilizzato come sistema di controllo della versione. Questi test sono molto importanti, dobbiamo assicurarci che ogni test ritorni con successo.

Il nostro flusso di lavoro corrente ha il seguente aspetto:

  1. Qualcuno commette le modifiche al codice nel nostro repository svn
  2. I colleghi aggiorneranno il loro repository locale ed eseguiranno uno script di build che si muove costruendo alcuni progetti di Visual Studio e spostando le DLL intorno

Tieni presente che i test non devono essere attivati automaticamente!

Quindi, ecco le mie domande:

Come si usa l'integrazione continua in questa configurazione? Ho trovato Jenkins.io dopo alcune ricerche. Strumenti come TravisCI o CircleCI sembrano non funzionare con le applicazioni ASP.NET (correggimi se sbaglio). Jenkins è adatto per eseguire test asp.net su ogni commit SVN?

Sono aperto a ogni idea e suggerisco come gestire i CI / test automatici in questa situazione.

La seconda domanda riguarda l'utilizzo dell'applicazione: Come si distribuiscono le applicazioni asp.net nel 2017?

Fyi ci sono due modi per usare la nostra piattaforma / sito web:

  1. L'applicazione che include il database verrà distribuita sul server di un cliente
  2. Il cliente utilizza il nostro server in cui viene distribuita l'app e si connette a esso

La nostra attuale configurazione è basata su uno script PowerShell che crea database con tabelle e dati iniziali, distribuisce il progetto asp.net, modifica i file di configurazione e infine configura il server Web IIS.

L'installazione basata su container come Docker è la soluzione giusta? E come gestiresti il "caso di aggiornamento"? L'aggiornamento del software non è un problema sui nostri server, ma come gestiresti questo se il nostro software si trova sul server del cliente? Sono pronto per ogni idea. :)

    
posta jdstaerk 31.08.2017 - 21:50
fonte

1 risposta

1

Bene, ci sono un certo numero di opzioni ed è abbastanza dettagliato. Anche il tuo caso è forse inusuale in quanto lo si distribuisce sul server clienti oltre che sul proprio.

Se disponi di un sito Web / applicazione, le modifiche ti aggiornano continuamente. La tua piattaforma di configurazione può avere un aspetto simile a

  • Github: con gitflow branching
  • Teamcity: trigger su commit per lo sviluppo del ramo
    • build solution
    • esegui test di unità
    • pacchetto su nuget
  • Distribuzione di Octopus
    • teamcity ha attivato la distribuzione per testare il server
  • Città del team: build innescata dal successo dell'implementazione
    • esegui test dell'interfaccia utente selenio sul server di test
  • Distribuzione di Octopus
    • Distribuisci manualmente la distribuzione per vivere con i server verdi / blu quando sei soddisfatto.

Con il database potresti avere una catena simile ma con gli script di migrazione

Se il servizio è ospitato nel cloud, è possibile che vengano generate nuove istanze per ogni distribuzione anziché essere distribuite nelle stesse caselle.

Ora, se si esegue la distribuzione su un server clienti, probabilmente non è possibile che utilizzino octopus, quindi è necessario uno script di distribuzione autonomo.

Powershell è un po 'vecchio cappello in questi giorni, prova Fake lo script make basato su F # che ha plugin per configurare IIS e simili. Ma essenzialmente sta facendo la stessa cosa.

Allo stesso modo, Jenkins può eseguire lo stesso tiro di Teamcity e Subversion può sostituire Git (se insisti a usarlo)

La difficoltà principale non è nella programmazione degli script per far sì che tutto accada. È abbastanza disciplinato da correggere la catena di costruzione quando si rompe, piuttosto che eseguire un lavoro manuale o disabilitare i test.

    
risposta data 31.08.2017 - 23:49
fonte