Configurazione del progetto del servizio cloud di Azure (.csdef e .cscfg) in più ambienti

Question

Attualmente abbiamo un servizio di sviluppo cloud (acme-dev-service) e un servizio cloud di produzione (acme-prod-service). La nostra configurazione attuale nella nostra soluzione prevede un progetto di servizio cloud denominato acme.application che utilizza la trasformazione dei file .cscfg e .csdef per la distribuzione del progetto nei due ambienti (produzione e sviluppo). Non mi piace il metodo di trasformazione perché mi sembra un po 'un trucco. Quindi, dopo aver fatto qualche ricerca, sembra che tu possa avere più file di configurazione che risolvono alcuni problemi, ma sto riscontrando dei problemi perché ti è consentita una sola definizione di servizio. Questo non funziona per noi perché l'ambiente di produzione richiede certificati extra e diversi binding hostHeader rispetto al nostro ambiente di sviluppo.

Quindi sembra che non possiamo davvero evitare di utilizzare le trasformazioni. Quindi penso che la mia domanda si riduce a sto guardando i file del progetto di servizio di Azure nella luce sbagliata? Dovremmo veramente mappare un progetto di Azure a un servizio cloud di Azure? Devo avere un progetto Azure per la produzione e un secondo progetto Azure per lo sviluppo? C'è un modo migliore per farlo? O una best practice per lavorare con più ambienti in Azure?

Answer 1

Il file CSDefinition è il vero kicker qui. Se hai un valore devi essere diverso tra due ambienti (dev/test/stage/produzione, ecc.) Allora hai davvero tre opzioni:

1) Modificare manualmente il valore prima di una distribuzione. Errr .... Va bene .... hai due opzioni.

1) Toccare il processo MS Build e determinare quale configurazione cloud è stata selezionata (quella utilizzata per determinare quale versione del file .cscfg verrà utilizzata) e quindi fare in modo che la build modifichi il file .csdef dopo la build e prima del confezionamento (c'è un tempo in cui il file è stato copiato in una directory diversa prima della pacchettizzazione e questo è il punto in cui si desidera apportare la modifica). Questo può essere complicato, anche se l'ho visto e l'ho fatto anche io nei primi giorni dell'SDK. Ecco un post sul blog che spiega un esempio in cui usa WebConfigTransformRunner per fare proprio questo: http://fabriccontroller.net/blog/posts/apply-xdt-transforms-to-your-servicedefinition-csdef-file/. Non penso davvero che questa sia la tua migliore opzione perché è opaca. Non è evidente cosa sta succedendo e qualcuno che viene dopo di te per mantenere il codice non conoscerà questa piccola gemma e passerà per sempre a cercare di capire perché alcuni valori che hanno inserito nel csdef da qualche parte vengono in qualche modo sovrascritti dopo la pubblicazione un ambiente diverso.

2) Utilizzare i due approcci di progetto di Azure citati. È possibile impostare le definizioni di build nello strumento di scelta di Build che determina quale dei progetti di Azure si desidera creare e pubblicare. Personalmente penso che questo sia il modo migliore per gestire diversi file .csdef. È semplice e non richiede la modifica dei file csproj. Non sono contrario al cambio di file csproj, non è troppo ovvio che sia stato fatto e, parlando come qualcuno che ha ereditato cose del genere, non è facile trovare quando le persone fanno quel genere di cose e non sono in giro per raccontare tu su di esso.