So I've been following many different idea/strategies through many blogs/SO posts but I haven't been able to find my idea solution.
The goal is to use the Azure DevOps tools to commit my project changes, push (via Git) the changes to Azure DevOps repo, have the CI/CD build the projected follow the pipeline rules to deploying to dev/production/etc. All this while, keep connection strings out of source control.
Currently, I got a website (legacy Web Application) that has local connection string definitions on an external connection string file (based on this article Connection Strings and Configuration Files). It's hosted as an App Service on Azure. Within my .gitignore
file I made Git ignore the specific connection strings file so that it's not in source control. Using Azure's deployment from GitHub feature, the site gets updated with the source in GitHub. However, I had to manually upload the connection string file with false/bad data. I use Azure's application settings to define the connection strings themselves. This process works perfectly fine.
I have a new .Net Web API project started at .Net Framework 4.7.2. I also followed the article to separate the connection strings into a separate files so that I can also ignore the file in source control. When the Azure DevOps builds the project it fails saying:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\Web\Microsoft.Web.Publishing.targets(2603,5): Error : Copying file ConnectionStrings.config to obj\Release\Package\PackageTmp\ConnectionStrings.config failed. Could not find file 'ConnectionStrings.config'.
Obviously, because I'm not adding this file to source control. Mainly because even during development I need to put actual connection string usernames/password.
What other solutions/features exist that can help accomplish this scenario?
Short answer: Don't put secrets in configuration files.
If all your resources reside in Azure, use Managed Service Identities so that you don't need to bother with connection strings.
If not, use ARM templates and key vault-linked parameters to manage your Azure infrastructure. Azure Web Apps allow you to override configuration files with app settings/connection strings within the web app. So simply use key vault to manage that stuff, and tell the web app to pull the values from key vault.
VSRM task to publish Web Apps supports overriding values in Web.config. You can keep your secrets in VSRM and replace them in the deployment time. See File transforms and variable substitution reference # XML variable substitution
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With