La nuova documentazione di ASP.NET sotto Nozioni di base / Lavorare con Ambienti multipli ha una descrizione dettagliata di come gestire più ambienti (sorpresa a sorpresa) nel codice.
Mi chiedevo se questa è la "best practice" quando si ha a che fare con ambienti multipli o dovrebbe essere gestita da qualcosa di diverso dal codice come lo strumento che sta facendo la distribuzione, per esempio?
Sul mio posto di lavoro abbiamo molti ambienti di test da gestire e generalmente eseguiamo uno stack .NET per i siti web. Al momento utilizziamo Octopus Deploy che, per ciascun ambiente, configurerà le applicazioni in fase di distribuzione. Le nostre app sono costruite e impacchettate con variabili sostituibili che Octopus riempie di distribuzione.
Anche se non si utilizza uno strumento del genere, raccomanderei la configurazione al momento dell'implementazione. La tua applicazione che impacchetta (nel tuo strumento CI preferito) per la distribuzione dovrebbe essere lo stesso pacchetto ripetibile che va in dev, test e prod. Utilizziamo Team City che crea i nostri pacchetti di distribuzione e un altro strumento che è un repository di pacchetti per memorizzare tutti gli artefatti di build.
Avere percorsi di codice che sono speciali per un ambiente potenzialmente rende i test più difficili dal momento che l'applicazione si comporta in modo diverso.
Integrazione continua che compila tutto il codice mentre esegue il check in ed esegue test unitari.
Come nel punto 1 più varianti o build parametrizzate. Costruisci per Windows Server. Costruisci per il server linux. Ecc.
Per i componenti interni o gli assembly condivisi potrebbero essere desiderati uno o più feed privati di nuget.
Una cultura di devops può essere utile.
Una strategia per l'implementazione continua di sistemi composti da sottocomponenti spesso etichettati come microservizi può essere utile per i servizi web.net asp.net.
La distribuzione blu / verde può essere utile. Vedi link
Leggi altre domande sui tag .net configuration environment