Gestione delle stringhe di connessione nell'applicazione controllata da origine che viene continuamente distribuita nei siti Web di Azure

Question

Ecco lo scenario: ho più sviluppatori su un progetto asp.net mvc 4. Ogni sviluppatore ha un database locale. Il sistema di controllo del codice sorgente è TFS a http://tfs.visualstudio.com. Utilizziamo siti Web di Azure per ospitare il sito. Abbiamo anche configurato siti Web di Azure per la distribuzione continua.

Il sistema di controllo del codice sorgente potrebbe essere git, mercuriale, TFS, ecc. Onestamente, non credo che importi.

La mia domanda è come realizzare queste tre cose:

1. Ogni sviluppatore ha la propria stringa di/connessione (s) a livello locale (senza essere in controllo del codice sorgente)
2. Azure ha la propria stringa di connessione (s) (senza essere nel controllo del codice sorgente)
3. Source Control non mostra alcuna informazione di connessione
4. La capacità per ogni sviluppatore di F5 ed eseguire/debug/testare l'app localmente.

Abbiamo raggiunto il n. 1 aggiungendo le nostre singole stringhe di connessione al nostro machine.config in modo che non ci siano conflitti tra le impostazioni della workstation dello sviluppatore.

Inizialmente ho rimosso la sezione connectionstrings da web.config. Nel sito Web di Azure (utilizzando il portale di gestione, in Configure), ho configurato le stringhe di connessione e dopo aver visto un video di Scott Hanselman avevo l'impressione che queste sarebbero state unite dinamicamente nel mio web.config dopo l'implementazione, ma ciò non sembra accadere. Ogni volta che vado a qualsiasi pagina che colpisce il db, ricevo un errore che dice che non riesco a trovare la stringa di connessione (o qualche altro errore db relativo alla connessione)

Se inserisco la stringa di connessione di Azure direttamente in web.config Le cose funzionano su Azure, ma i dettagli della connessione sono visibili nel controllo del codice sorgente a tutti.

Dopo aver letto altri post di Scott e David Ebbo, sembra che potrei inserire una stringa di connessione vuota in web.config (con il nome corretto) e quindi Azure sovrascriverà correttamente i valori. Dovrei quindi avere gli sviluppatori che mettono le loro stringhe di connessione nel loro web.debug.config e quindi installano il plugin Slow Cheetah in modo che possano F5 e testare localmente. Dovrebbero anche non controllare il web.debug.config nel controllo del codice sorgente. (Non così facile con TFS) Questo sembra un kludge pesantemente oneroso, che è destinato a fallire da qualche parte lungo la linea.

Devo credere che questo non sia un problema raro. Come fanno gli altri team a raggiungere questo obiettivo?

Answer 1

Dopo essersi guardato attorno, sembra che ciò che stavo chiedendo non sia effettivamente supportato senza una serie di hack da riga di comando per il processo di pre/post build. Ciò che abbiamo finito è costringere gli sviluppatori a creare tutti i loro database locali, utilizzare l'autenticazione sicura e stabilire un alias SQL che è stato utilizzato da tutti gli sviluppatori nel web.config. In questo modo, funziona localmente per tutti, non espone alcun nome utente/password nel controllo del codice sorgente e Azure può comunque sovrascriverlo quando viene estratto automaticamente dal controllo del codice sorgente.

Answer 2

Cheetah lento è in realtà una soluzione piacevole. È un'estensione a web.config transformations. Quelle trasformazioni ti consentono di conservare un file web.config e quindi per ogni scenario di distribuzione devi specificare quali modifiche desideri. Ad esempio, la configurazione di Release probabilmente rimuoverà l'attributo debug.

Questo può essere utilizzato anche per modificare le stringhe di connessione. Le trasformazioni vengono applicate durante la distribuzione del progetto in Azure.

Quello che ho fatto in passato per farlo funzionare anche con macchine di sviluppo locali è utilizzare un web.config con un externalized connections.config file. Ogni sviluppatore ha creato un file connection.machinename.config che è stato copiato in connection.config su build nel passaggio post-build. Questi file non devono essere archiviati e non possono mai causare conflitti perché ciascun nome di computer è univoco.

Le configurazioni release/staging/.. hanno utilizzato una trasformazione web.config per sostituire l'elemento stringa di connessione con una stringa di connessione specifica per tale distribuzione (eliminando in tal modo la dipendenza dal file di configurazione esterno).

Slow Cheetah offre alcuni simpatici aiutanti per verificare il risultato di queste trasformazioni in fase di progettazione.