Gestione della distribuzione in più ambienti

Normalmente maggiore è il processo di distribuzione automatizzato, minore sarà il rischio. Per ottenere una migliore automazione, penso che le procedure da riga di comando (con diverse modalità, ad esempio la modalità interattiva v.s. quiet) potrebbero essere una buona opzione:

1. Credo che non ci siano molti ambienti (DEV / QA / UAT / PROD / etc.) e sono già stati risolti. Quindi una trasformazione xslt fissa potrebbe essere definita e inclusa nel progetto, ad esempio chiamarla web.config.xslt, in cui è possibile definire un elenco di sezioni di configurazione per ambiente (o una configurazione condizionale con switch case)

2. usa MSBuild per costruire la soluzione e metti i file costruiti in una nuova posizione (preferibilmente accessibile a tutti gli sviluppatori) e alla fine trasforma web.config basato su web.config.xslt e genera una coppia dei file di configurazione: web.Dev.config, web.QA.config, web.UAT.config e web.Prod.config

3. dare un'opzione alla riga di comando, dire quale ambiente l'utente vuole distribuire, quindi copiare in batch tutti i file sul server desiderato (ovviamente, devi consentire a queste cartelle di essere condivise e accessibili al deployer) e alla fine copia il web corrispondente. [ENV] .config file come web.config nella cartella di destinazione

4. altri bit e pezzi (come il controllo delle versioni, la firma della DLL e così via) potrebbero anche essere inclusi e automatizzati attraverso il processo MSBuild.

tutti questi passaggi possono essere archiviati in un file a livello di soluzione predefinito, diciamolo mySolution.BuildRelease.proj (tutto a te) e impostare MSbuild (o il tuo bat file auto-definito, che chiama MSBuild e l'app della tua console ) come app predefinita per aprirlo.

naturalmente, se alcuni dei processi non possono essere eseguiti usando la linea di comando, potresti provare a scrivere un'applicazione di console e chiamarla durante MSBuild.

se ti piacciono gli approcci interattivi, puoi anche definire un'app html (hta) per concludere il processo

In una vita passata ho gestito un gruppo di fronte a questo problema.

Abbiamo scelto di impostare manualmente i file di configurazione in base alle esigenze (ad esempio, una promozione del codice dal test alla produzione esplicita escludi il file web.config). Come te, era un gruppo diverso che promuoveva.

Uno dei principali vantaggi che abbiamo visto è che "quello che hai visto su Test era quello che avresti ottenuto su Prod". Se il tuo codice contiene ANY codice dipendente dall'ambiente, sei nei guai perché stai mettendo in produzione un codice non testato.

L'abbiamo imparato nel modo più duro quando uno sviluppatore ha inserito if (servername != "prodServer") nel codice. Tutto andava bene fino a quando il gruppo di server non ha rinominato prodServer in prodServer2 e tutte le nostre stringhe di connessione, ecc. Tornavano alle impostazioni dell'ambiente di sviluppo. È stata una giornata difficile, difficile da spiegare al business perché il loro sistema di produzione si è schiantato così a fondo.

tl; dr

• Il tuo codice non dovrebbe mai sapere in quale ambiente (dev / test / produzione) si trova.
• I file di configurazione non sono codice e non dovrebbero mai essere promossi.
• Mantieni il processo di promozione del codice il più semplice possibile. Penso che abbiamo usato Robocopy . Impostarlo per copiare tutto eccetto web.config da dirA a dirB è abbastanza infallibile.

So che è uno dei tuoi limiti, ma onestamente spingo più che puoi per ottenere un build server. davvero .

Ora ce l'ho fuori dal mio petto, se uno non è disponibile nel termine breve , potenzialmente ogni ambiente potrebbe avere il proprio repository delle impostazioni che cerca i nomi dei server, stringhe di connessione ecc., in modo che la configurazione di una configurazione o di una macchina non richieda la modifica dei file fisici, ma lo staff dell'amministratore (o chi ne ha mai la responsabilità) può modificare le impostazioni in un'unica posizione. Ovviamente ogni app contatta il repository tramite web services / wcf o qualsiasi altra cosa vogliate ottenere le impostazioni. L'app deve quindi solo conoscere la posizione del repository e tutto il resto è controllato dagli amministratori.

In definitiva, il modo per sbarazzarsi degli errori manuali è quello di automatizzarli, come hai detto tu.