Why Configuration Matters
When first-time programmers write their first programs they tend to hard-code settings in to what they write.
This is fine for smaller programs, but as the programs grow it becomes harder and harder to maintain. Quite often the same settings are sprinkled through various files, and any change to one of these settings will require lots of little changes to many files. The extra complication with this approach is that you need to make sure you make the same changes to all the files.
Hard coded settings can be fine for smaller programs, but they become harder to maintain
There is a better way! The idea is to have all your settings in one central place, and then you can refer to them in your program where you need to use them. In the example above you would have only had to change your setting in one place instead of in a whole bunch of files. This is the core concept of ‘configuration’.
Our team use configuration in all of our projects. Even the really small ones. We generally have configuration items for the host names of the services, database connection settings, and log file locations to name a few. Each project has some additional settings depending on what other services they need to use that we also store in our configuration. Generally speaking you would have one configuration for your project.
The configuration system that our team uses also has another layer of complexity — that being environment. Environment is another way of saying location where the project is running. We have a production environment (this is the one you, as an end-user see or use), a dev environment (where we try new things out), a test environment (which our automated testing uses), and a local environment (where we run our projects on our local computers). We have more environments than this, but you get the idea. This means that we have a configuration for each environment in our central configuration place.
When a new developer starts with us, one of their first tasks is to get our projects running on their new computers. This breaks down to two tasks; cloning the repository to their local machine, and then configuring the project to run on their machine. If we had hard-coded our settings then it would take the poor developer weeks to get the project running on their local machine.
All of our team’s projects are deployed via an automated process. One of the steps of the deployment process is to configure the project for the machine it is running on. The configuration process uses the environment and mixes this with some settings that only our servers know about. This ensures that we do not store passwords in our configuration files, and it also means that our developers cannot log on to production databases.
Configuration is awesome when it works, but it can be really bad when it goes wrong. If you get your configuration wrong then your project will not work (or it might work, but not as you would expect).
An example - If you get the address of your database server wrong, then your project will no longer be able to talk to to the database and it will not be able to look up any information. It’s really important that you get configuration correct. As they say, “with great power comes great responsibility”.
It’s really important that you get configuration correct.
The projects our team work on are either Node.js, Java or PHP. Each programming stack has one configuration method. By this I mean that all Node.js projects are configured using a single configuration method, all Java projects are configured using a single configuration method, and all PHP projects are configured using a single configuration method.
This means that the programmer only needs to learn one way of configuring a stack and all other projects using the same stack will be configured in the same way. The benefits of this is that developers can get up and running faster, and all the projects work in the same way.
This post is part one in a four-part series. The next post in this series will dive into more details about how our Node.js configuration module works and how we use it.
In the meantime, feel free to drop any questions or feedback into the comments section below!
