One of the most important principles of an agile software development team is the ability to quickly modify an application to deliver business value.

Often that change is a simple setting in the configuration file, so it doesn’t make sense to redeploy the whole service including large binary packages that can be slow. In order to combat this, we have started to implement config-only deployments.

Leave code behind to deploy config in rapid time

Why so slow?

Traditionally, the code and config in our applications are tightly bound and released as a single package. This makes deployments slow as all of the code plus config must be compiled, packaged and copied to its destination. When the application is large and includes multiple binaries it takes even longer, which results in longer down times.

This problem is further compounded by the fact that the app must progress through the build pipeline across multiple testing and integration environments before finally getting into production. Sometimes the full deployment process can sometimes take hours alone.

On top of this, it means that we are slower to deliver business value and slower to react to incidents. The latter of which can force us to make manual modifications to production that are not documented in source control and is very bad practice.

Boost your deployment times

The solution was to create separate config-only deployment pipelines, which dramatically improved release times by up to 75% for some services.

Splitting the config away from the code enables our applications to be more flexible and adaptable, as it is quicker for us to deliver business value and react to incidents. We can also confidently and quickly make changes to production environments without manually logging onto servers.

How did we do it?

To ensure a consistent development experience, both the code and config remain in the same solution and source control repository so users can make modifications, run tests and commit as usual.

The main change to enable the config to be released separately was the introduction of a new deployment pipeline. This uses some simple Powershell and Git commands to compare commits and detect which files have been modified.

If only config files have been modified in a commit then just the config is released. But, if the code or config plus code are modified, then the entire solution is released via the original deployment pipeline.

Dynamic configuration

All of this has led me to think about if config files are the best way to manage applications. An alternative approach could be to use dynamic configuration management.

Tools such as Consul, Zoo Keeper and Archaius make use of distributed key value stores that allow services to retrieve config and modify behaviour at runtime. These tools are particularly useful for feature flags, switches and A/B testing which opens up further possibilities to move our services forwards in the future.