DEV Community

Craig Nicol (he/him)
Craig Nicol (he/him)

Posted on • Originally published at craignicol.wordpress.com on

Self-testing configuration – the example.config story

Some halloween cakes reflected in a mirror

Mirror image

We’re all good developers and never store production secrets in our source code. We have to keep them somewhere though.

If you’re an ASP.Net developer and you store your secrets in a separate file, how do you check them on release?

In a previous job, we were building an application in AWS EC2, which meant we couldn’t sit on top of the lovely Azure Key Vault/secrets.json workflow, and instead used a secure file drop as part of the deployment. We had a couple of releases that failed because secrets that were available locally weren’t included in the release package, causing the website to fail to start. We didn’t have the nice logging provided by the .Net core configuration objects, so what we did was create configuration documentation in the form on an example.config file that contained all the keys we expected, and populated dummy values. On startup, we’d compare the list of keys in the example.config which did not contain any secrets, with the actual config, and fail the startup with a report of which keys were different so we had a very quick way of checking the config was in sync with expectations.

Top comments (0)