Modo corretto per distribuire ASP.net sul server Web di produzione

5

Ecco come mi è stato detto di distribuire il mio sito Web \ programma \ applicazione ASP.net (principalmente intranet) al server Web di produzione nella mia azienda.

  1. Modificare le impostazioni necessarie in web.config per il server Web di produzione.
  2. Copia TUTTO i miei codici sorgente, quindi incolla nella cartella \ directory virtuale designata nel server web.

Per quanto ne so, dovrei essere:

  1. utilizzando Publish.. o Publish Web Site in Visual Studio per generare i codici.
  2. Copia i codici generati nella cartella \ directory virtuale designata nel server web.

Quale è un metodo di distribuzione migliore?

Quali sono i pro e amp; contro di questi due metodi di distribuzione?

C'è un modo standard (per poveri o poco costoso) per fare questo?

    
posta Pop 21.07.2016 - 06:02
fonte

1 risposta

5

Dalla mia dolorosa esperienza, più il processo di implementazione viene eseguito manualmente, maggiore è il problema in cui ti troverai. E entrambi i tuoi passaggi attuali richiedono uno sforzo manuale pesante. Ecco i miei consigli:

1. Utilizza la funzionalità VS Publish come minimo indispensabile

Il primo passo verso il processo di distribuzione automatizzata è, come saprai, utilizzando la funzionalità Pubblica in Visual Studio. Con la corretta configurazione della trasformazione XML, questa funzionalità gestirà le modifiche necessarie su web.config (e altri file di configurazione basati su XML).

Idealmente, se si ha accesso al server di produzione, è possibile scegliere come target il sito Web Pubblica sul server di produzione. Questo farà il copia / incolla per te. Altrimenti, scegli una cartella isolata nel tuo sistema (che non la scambieresti mai con la cartella del codice sorgente).

2. Impiega l'integrazione continua (CI) e la distribuzione continua (CD)

Questo potrebbe essere eccessivo per piccoli progetti che sono principalmente gestiti da un unico sviluppatore. Ma CI / CD è la strada da percorrere se il tuo progetto si evolve verso un mostro. Ecco gli indicatori per iniziare a utilizzare CI / CD:

  • Il tuo progetto e il team che lavora su di esso diventano abbastanza grandi da non poter letteralmente testare manualmente tutti gli aspetti del sito Web ogni volta che vengono introdotte nuove modifiche = > Hai bisogno di test automatici e ne hai bisogno ogni volta che qualcuno commette un cambiamento.

  • Ora disponi di più ambienti da distribuire a (dev, staging, UAT, produzione, lo chiami). Sebbene la creazione di un profilo di pubblicazione per ognuno di essi sia ancora fattibile, sapere quando è necessario distribuire in un ambiente specifico diventerà complicato (ad esempio, distribuire in produzione solo se tutti i test vengono passati in altri ambienti e il tuo capo, ovvero il tuo cliente) felice con UAT).

  • È necessaria la possibilità di ripristinare la distribuzione. Vedi quanto è bello? Il CD potrebbe letteralmente risparmiare ore quando qualcosa va a sud con la tua nuova implementazione con un solo clic del mouse.

  • Si desidera mantenere i dati sensibili di configurazione dal check-in al controllo del codice sorgente (diciamo che non si desidera esporre la stringa di connessione al proprio DB di produzione a uno sviluppatore junior appena assunto). Il flusso di lavoro con la trasformazione VS Publish + XML rende più difficile il raggiungimento di questo obiettivo.

Ci sono molti strumenti CI / CD per iniziare, alcuni di questi sono GRATUITI. Attualmente sono soddisfatto di TeamCity per CI e Octopus Deploy per CD (entrambi sono gratuiti per i team di piccole dimensioni).

    
risposta data 22.07.2016 - 04:23
fonte

Leggi altre domande sui tag