Default Config Options

Once your project becomes a bit bigger than ‘Hello, World’, you need to add an ability to configure it. It could be config in the code like in Django or Flask, pass environment variables, CLI arguments or a special config file located somewhere in the filesystem.

At this point, everyone should ask themselves this question: What should I consider as a default option? Should it be production-like or developers friendly options?

The first rule is: you should be able to run your application with default config. You can use SQLite as a database, maybe some features should not work properly but the application must be able to start.

What does it mean? E.g.: if an application requires RabbitMQ for RPC, it should startup but raise an exception with a proper message like ‘Can not connect to the RabbitMQ host: localhost, port: 5672’ so you’ll be able to understand what is going and how to fix it. Another option is to raise an exception like ‘RabbitMQ connection is not configured. Please specify “rabbitmq_host” config option’. Sometimes you even can start an application without some third party requirements like a database, message broker or something like it. But any such issues should be logged. Errors like “Can’t startup with invalid config” are not useful at all.

Another important thing is to decide what is defaults: development or the production-like environment. As a software engineer, I prefer to have development-friendly defaults. But if you don’t have good configuration management, it’s harder to have production config tested.

I think, on CI you should have production-like configurations in your configs. It helps you to prevent many issues in the future.

If you can have a production-like config for your development needs, it’s awesome. It leads to some more testing even during development. Also, if you keep your development environment closer to a production one, you’ll have fewer errors in the future.

It’s a hard choice. I don’t have a strong opinion on it. I just try to keep my configs as close to production as possible and do not make development as a nightmare.


.net .net-framework .net-framework-3.5 agile ajax ajax-control-toolkit ampq ansible apache automation axum babel bash benchmark blog blog-engine bootstrap buildout c# cache centos chrome ci cinder ckan cli cloud code-review codeplex community config debugger deface dependencies development-environment devices devstack devtime disks django dlr dns docker dockerimage dos easy_install elmah encoding environment-variables error event events everything-as-a-code exception exceptions fabrik firefox flask foreach forms fstab gae gcc gerrit git github go google google-app-engine grep hack hacked hardware headless horizon hound html hugo iaas ienumerable iis internet iptables iron-python ironic iscsi java-script javascript jenkins jquery js jsx kharkivpy kiss kombu kvm kyiv lettuce libvirt linux lio loci logging loopback losetup lvm mac-os macos mercurial microsoft microsoft-sync-framework mobile mono ms-office msbuild networking news nginx npm npx offtopic oop open-source open-xml opensource openstack openvswitch os packages paraller-development patterns-practices performance php pika pip plugins pnp podcast popup postgresql profiler project protocols proxy pycamp pycharm pycon pykyiv pylint pypi python python-3 qcow quantum qumy rabbitmq rar react reactjs refactoring rfc rhel search-engine security selenium server shell silverlight socket software-engineering source-control sourcegear-vault sources sql sql-server sql-server-express sqlalchemy ssh static-site sublimetext svg tests tgt tipfy tornado typescript uapycon ui uneta unit-tests upgrades usability vim virtualenv visual-studio vitrage vm vue.js vuejs web-development web-server web-service web_root webpack webroot windows windows-live word-press x32 x64 xcode xml xss xvfb интернет-магазин книги


2019 (73)
2018 (2)
2017 (3)
2016 (2)
2015 (3)
2014 (5)
2013 (17)
2012 (22)
2011 (35)
2010 (25)
2009 (35)
2008 (32)
2007 (2)