1

Consider the following CI procedure is in place:

  • Builds are only deployed (semi-)automatically.
  • All changes are version-controlled.
  • Configuration is fixed per environment.

Why use data files (*.config in .NET) versus code for configuration?

Yes, it would technically be "hard-coded" although still centralized rather than being scattered (normal best practices still apply). The benefit is that you would get more of compile-time verification. Maybe some unit tests as well.

Possible reasons against:

  • (Advanced) users may be allowed to change some configuration manually (e.g. detailed graphics settings in x86 games).

  • It might be useful to see what is the configuration without going to source repository when the application is crashing on start?

  • Is there a difference between 'connection string' type of settings vs 'inversion of control container config' type of settings?

3

I have currently my config files in the build process, however whenever i will have the opportunity i will externalize them.

Here is a general answer :

Because the client may need to change some parameters without having a new delivery.

Let's say we use a database, and for a specific reason, the client wants to change the database to point to a new database. This considering that he has a team handling the production environment and we're not allowed to touch it directly, this is quite common. Then you need to have externalized files.

Moreover, depending where you work you may not be allowed to know the production configuration logins and passwords. So it's a matter of security too.

In your case,

If you're really sure you have your hands in the environment and no one else is allowed to touch it without your consent. You can keep them, but you will need a new version of your product every time some configuration changes for one envinronment.

  • 1
    As a result to general answer, which is correct, you can also proceed to not have externalised config if you provide a service for the client to modify it. In a sense, a config file is nothing more than a raw, unfriendly, unsecure way to expose a CRUD api to change your app behaviour. If you have time for a built-in way, there will be benefits. – Arthur Havlicek Jun 10 '16 at 9:09
  • "...you will need a new version of your product every time some configuration changes for one environment" - this is exactly what Continuous Delivery is trying to address. If building and deploying is a big deal, then there is a more serious problem to address before worrying about config. – Den Jun 10 '16 at 9:12
  • @ArthurHavlicek This is true, however there is often some system properties or some that require a restart. If it's a desktop application it's fine. If it's something like a web application, sysadmins don't really like to go from application to application to setup them. They go for config files + batch/bash scripts. Of course you can split your configurations between some high level configurable using interfaces, and low-level only accessible from file disk. – Walfrat Jun 10 '16 at 9:12
  • @Den : though i understand what you said (the words) i don't really get your point (the words as a whole, i'm not native speaker). Do you mean that CI address this problem as a new version should be generated if you change it or the opposite ? My original point was something like "the product management may not be allow you to address a new version for a config change" – Walfrat Jun 10 '16 at 9:18
  • @Walfrat I basically meant first 4 sentences here: en.wikipedia.org/wiki/Continuous_delivery . I think that situation you are describing is quite specific (release approval etc.) – Den Jun 10 '16 at 9:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.