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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.