Does continous delivery reduce the need to make settings configurable?

Question

I mainly work on custom web applications that have just one production deployment.

While we are moving to continuous delivery, I was wondering if that approach reduces the need to make settings configurable.

For example, I was writing code that sends confirmation e-mails from a web server through Exchange.

Quite some configuration needs to be done:

1. Version of Exchange
2. An account to login to Exchange
3. A sender e-mail address
4. The URL of an Outlook web access service

The version of Exchange will probably change only once in a couple of years. The account to login and the sender email address will possibly never change during the live time of the product. The URL may change at some point due to whatever external reason.

Traditionally, I would make all of these configurable through a setting file, like web.config. The consideration would be that if changing any of these would unexpectedly be required, this could be done without a release of the product, which may not be feasible at the time it is required or introduce risks.

However, if your continuous delivery pipeline works as it should, couldn't you rely on the possibility to release whenever such a change is required?

What are your opinions? Have you observed a trend in this?

Answer 1

You have several assumptions about the production environment that may be true today, but may not be tomorrow. Anything specific to that environment - even if you only expect a single installation - should be in a configuration file. Then changes, when needed, can be made immediately without having to wait for a build to be made.

While you may not expect any of those settings to be changed frequently, if anything goes wrong anywhere being able to make quick changes to these can make a difference in how quickly you can recover from the fault.

Using a configuration file will make it easier to scale your environment by adding additional mail or web servers.

By using a config file for these settings, you can keep information like usernames and passwords out of your code base.

Answer 2

One significant benefit in having a CI/CD pipeline is the ease at which it's possible to deploy into multiple different environments, where each environment has its own configuration. For example, it's frequently desirable to have a staging environment in which some users or stakeholders can review changes before anything is pushed into production.

To ensure that other environments are completely isolated and don't interfere with production, external dependencies would also typically be deployed into that environment too - in which case, in the given example in the OP using MS exchange, that would mean the 4 configuration parameters mentioned for an Exchange server are all likely to vary between environments.

Answer 3

For the core of your question: CI/CD and config files are orthogonal concepts.

Having configuration settings is a good practice, as 1201ProgramAlarm says in their answer. You never know when those settings can change. I am going to add that you shouldn't change those settings directly into a production machine, but only as part of your deployment (exceptions do exist)

Having a CI/CD pipeline only modifies that your deployment is automated. How you use your configuration settings doesn't change.

One exception, though, you can avoid having transformations on your settings for each environment and depend on environment variables setup on your CI/CD pipeline. That moves the setup from your source code to the pipeline. Of course, there is a drawback to this, as you lose the historical data when you change the values on your configuration settings, which maybe important for you.