Come si aggiornano i siti Web live con modifiche al codice?

So che questa è una domanda molto semplice. Se qualcuno potesse umorizzarmi e dirmi come avrebbero gestito questo, sarei grato.

Ho deciso di pubblicare questo perché sto per installare SynchToy per risolvere il problema di seguito, e mi sento un po 'poco professionale usando un "Giocattolo" ma non riesco a pensare a un modo migliore.

Molte volte trovo che quando mi trovo in questa situazione, mi manca un modo dolorosamente ovvio di fare le cose - questo deriva dall'essere l'unico sviluppatore dell'azienda.

• Applicazione web ASP.NET sviluppata sul mio computer al lavoro
• La soluzione ha 2 progetti:
  • Sito Web (file)
  • WebsiteLib (C # / dll)
• Utilizzando un repository Git
• Distribuito su un server Web GoGrid 2008R2

Distribuzione:

1. Apporta modifiche al codice.
2. Push to Git.
3. Desktop remoto su server.
4. Tirare da Git.
5. Sovrascrivi i file live trascinandoli con Windows Explorer.

Nel passaggio 5 elimino tutti i file dalla radice del sito Web .. questa non può essere una buona cosa da fare. Ecco perché sto per installare SynchToy ...

AGGIORNAMENTO: GRAZIE per tutte le risposte utili. Non riesco a scegliere quale contrassegnare la risposta - tra l'utilizzo di una distribuzione Web - sembra che io abbia diversi suggerimenti utili:

1. Progetto Web = intero sito impacchettato in una singola DLL - aspetto negativo per me non posso inviare semplici aggiornamenti - essendo uno sviluppatore solitario in una società di 50, questo a volte rimane qualcosa di più semplice.
2. Passando direttamente da SCM alla radice web del sito - inizialmente non lo facevo per paura che la mia directory nascosta SCM potesse finire per essere esposta, ma le risposte qui mi hanno aiutato a superarlo (anche se non mi piace ancora averne uno più cosa di cui preoccuparsi per dimenticare di assicurarsi che sia ancora vero nel tempo)
3. Usando una web farm e distribuendo sistematicamente ai nodi - questa è la soluzione ideale per zero tempi di inattività, che in realtà è qualcosa di cui mi preoccupo poiché il sito è essenzialmente una fonte di entrate in tempo reale per la mia azienda - potrei avere difficoltà a convincerli a il doppio del costo dei server però.

-> infine, la re-applicazione del principio base che deve essere implementata con un solo clic per il sito O ALTRO QUALCOSA DI SBAGLIATO è probabilmente la cosa più utile che ho ottenuto dalle risposte.

AGGIORNAMENTO 2: Ho pensato di tornare su questo e aggiornare con la soluzione reale che è stata messa in atto per molti mesi e funziona perfettamente (per la mia soluzione con un singolo server Web).

Il processo che utilizzo è:

1. Apporta modifiche al codice
2. Push to Git
3. Desktop remoto su server
4. Tirare da Git

5. Esegui il seguente script batch:

   cd C: \ Users \ Administrator

   % systemroot% \ system32 \ inetsrv \ appcmd.exe stop site "/site.name:Default Web Site"

   robocopy Documents \ code \ da \ 1 \ work \ Tree \ LendingTreeWebSite1 c: \ inetpub \ wwwroot / E / XF connectionsconfig Web.config

   % systemroot% \ system32 \ inetsrv \ appcmd.exe avviare il sito "/site.name: sito Web predefinito"

Come puoi vedere, questo fa cadere il sito, usa robocopy per copiare in modo intelligente i file che sono stati modificati, quindi il backup del sito. In genere funziona in meno di 2 secondi. Poiché il traffico di picco su questo sito è di circa 2 richieste al secondo, sono accettabili 4 richieste per aggiornamento del sito.

Sine, sono diventato più abile con Git, ho scoperto che anche i primi quattro passaggi precedenti sono un "processo manuale", anche se sono sicuro che potrei fare tutto in un solo clic, se lo volessi.

La documentazione per AppCmd.exe è qui . La documentazione per Robocopy è qui .

Dovresti dare un'occhiata alla distribuzione web di VS 2010. Se GoGrid lo supporta, il pacchetto di distribuzione Web è una buona soluzione.

http://weblogs.asp.net/scottgu/archive/2010/07/29/vs-2010-web-deployment.aspx

Al mio precedente datore di lavoro, per distribuire le modifiche al codice, avremmo impostato il bilanciamento del caricoper interrompere il servizio a un server web. Potrebbero essere necessari 20 minuti per la scadenza delle sessioni sul primo server Web. Aggiorneremmo il codice su quel server web decomprimendo il file zip di distribuzione, quindi controllando che le cose funzionino bene colpendo l'indirizzo IP diretto per quel primo server web. Quando siamo convinti che funzioni bene, impostiamo il bilanciamento del carico in modo da colpire il server web ora aggiornato e attendere che le sessioni scadano su un altro server e quindi aggiornarlo (e così via fino a quando non sono state aggiornate tutte). Dopo che si sono verificati bene, abbiamo impostato il bilanciamento del carico per tornare a fare il suo lavoro. Ciò si è complicato quando abbiamo avuto fino a 10 server Web collegati al bilanciamento del carico durante i carichi di picco stagionali (quindi aggiornarli uno a uno potrebbe richiedere ore perché non siamo riusciti a chiudere il sito Web live: i clienti dovevano essere in grado di ottenere al sito).

In ASP.NET, se si rilascia un file denominato App_Offline.htmnella directory principale di un sito Web, tale sito Web viene scaricato e ciò consente di aggiornare le DLL (e quant'altro). IIS pubblicherà una pagina intitolata "Applicazione offline". Quando il file viene rimosso, rinominato o eliminato, l'applicazione Web verrà riavviata e IIS fornirà pagine Web a quel sito Web. Questo è ciò che fa Visual Studio quando si pubblica un sito Web dall'interno di VS.

In genere quello che faccio è tenere tutto in un repository SVN. Quando ho finito con alcune modifiche, mi impegno sul sito di sviluppo e quindi controllo sulla produzione. Mantiene tutto sincronizzato, è facile e veloce. Se il check-out è troppo complicato, puoi configurare Apache con WebDAV e lo farà per te.

Per ciascuna delle mie app Web ho una configurazione di repository git con tre rami. Live, Beta, Funzionalità. Live è ovviamente il sito live. Beta è il sito utilizzato per correggere bug o per il test finale delle funzionalità subito prima dell'implementazione. Quindi, come hai detto, faccio una semplice git push, git pull on live per inserire le informazioni. Le funzionalità vengono utilizzate per i miglioramenti della "prossima versione".

Stai cercando di risolvere il problema della consegna continua . Inizialmente inizieresti con passaggi manuali, ma presto ti accorgerai dei problemi. Questi sono i più comuni:

1. Il codice funziona sul tuo PC, non funziona sulla produzione
2. La nuova modifica rompe il vecchio codice
3. Le modifiche incrementali renderanno sempre più difficile la distribuzione, otterrai nuove librerie da allegare, patch da applicare ecc.

Dai un'occhiata a TeamCity (o qualsiasi strumento simile).

Utilizzare uno script di compilazione e distribuzione automatizzato

Il modo migliore per farlo è utilizzare uno script di compilazione e distribuzione automatizzato come MsBuild o Nant.

• https://www.justinshield.com/2010/06/automated-deploy-to-iis7-using-nant/

Il motivo è che puoi semplicemente digitare 1 comando per distribuire un sito Web e quindi semplicemente digitare 1 comando per ripristinarlo. E se sei abbastanza approfondito, questo includerà le migrazioni dello schema del tuo database. (Migrator.Net)

Uno dei motivi principali per non utilizzare SVN o GIT per la distribuzione è che l'ambiente può cambiare tra produzione e stadiazione. Nel tuo script NANT puoi farlo costruire i tuoi file .config specificatamente per l'ambiente a cui ti rivolgi. Questo evita di dimenticare di inserire un'impostazione di configurazione in produzione.

Automatizza anche l'intero processo in modo che diventi un affare di un comando e qualsiasi numero di processi manuali diventa 1 semplice processo.

Prima di tutto, dovresti usare un progetto web. Quali sono le differenze che chiedi?

Un progetto Web combina tutti i file di classe C # (codice sottostante incluso) in una singola DLL (migliore per la sicurezza e il fatto che è un file da spostare)

In secondo luogo, è necessario pubblicare l'applicazione e quindi è ancora possibile desktop remoto, trascinare tutti i file nella cartella di pubblicazione e semplicemente impostarlo per sovrascrivere (i nuovi file sostituiranno i vecchi file).

La pubblicazione metterà tutti i file necessari per l'applicazione in una cartella.

Il mio attuale datore di lavoro distribuisce usando il burattino . (Qui ci sono più pacchetti software che affrontano lo stesso problema.)

Il mio precedente datore di lavoro utilizzava un sistema di controllo dei lavori personalizzato per gestire l'implementazione del software, il riavvio, ecc. Anche se fosse disponibile, era eccessivo per le tue esigenze.

Il datore di lavoro che avevo in precedenza aveva script personalizzati per copiare i dati dalla sovversione ai server e fare un riavvio progressivo.

Diversi posti che ho visto in precedenza avevano creato file per gestire la distribuzione. Hanno generalmente usato una strategia come tagliare metà dei server web dal bilanciamento del carico, aspettare, fermare quella metà, stendere il codice, riavviarli, quindi lanciare il bilanciamento del carico, attendere, arrestare l'altra metà, riavviarli, quindi riportare indietro il bilanciamento del carico su.

In tutti i posti in cui ho lavorato, la distribuzione del codice era un singolo comando o la mancanza di un singolo comando veniva riconosciuta come un problema da risolvere.

In genere ciò che utilizziamo per risolvere questo problema con i nostri siti Web è uno strumento incluso con Systems Internals chiamato junction.

Usando questo strumento siamo in grado di creare collegamenti da una directory all'altra. L'app root sul server contiene 3 cartelle. Rosso, blu, corrente. IIS è configurato per guardare sempre Current per i suoi file.

Puoi emettere un comando junction currentche ti dirà a quale cartella è attualmente puntato. Ad esempio, supponiamo che al momento stesse puntando su Blue. Quello che faremmo è mettere in coda i file in rosso per la nuova distribuzione e assicurarci che tutta la configurazione fosse pronta.

Una volta che siamo pronti, possiamo emettere il comando junction current redper farne riferimento.

Ci sono due cose che rendono questa soluzione così eccezionale

1) Hai tutto il tempo per mettere in coda le tue modifiche nella cartella. Nessuna fretta e l'unico tempo di inattività è quando il pool di app si avvia. (C'è un modo per pre-compilare anche questo passaggio.)

2) Se qualcosa va storto con la tua distribuzione, tutto ciò che devi fare per ripristinare è emettere un comando invece di provare a ripristinare le modifiche. Il comando nel nostro caso sarebbejunction current blue

Speriamo che il nostro modo di fare le cose possa far luce su una nuova soluzione per te.

Quello che ho fatto e non sono sicuro che tu abbia lo scopo per questo, ma qui va. Uno sviluppatore verificherebbe il codice in un ramo di controllo qualità, quindi verrà caricato in un ambiente di controllo qualità da un ingegnere di sistema, una volta superato il controllo qualità verrà promosso nel ramo di produzione. C'erano almeno 2 di ogni sito collegato a un server su un bilanciamento del carico, anche in questo caso, uno dei due server sarebbe stato offline, si sarebbe fermato il sito sarebbe stato archiviato e il nuovo sito sarebbe stato distribuito insieme a tutte le modifiche richieste sono state quindi riavviate e si passa al server successivo. Questo è stato tutto scritto usando C # nel nostro caso, ma è stato fatto in passato usando lo script vb. Spero che aiuti. Saluti