In the age of DevOps, techniques to overcome challenges associated with releasing updates frequently, yet still of the highest quality, include making use of automated testing, effective management of your codebase, utilising infrastructure as code, and ensuring your environments are synchronised where it counts. This last item, however, is perhaps not given as much emphasis as it should.
What is Configuration Drift?
Configuration Drift refers to the phenomenon where environment configurations ‘drift’ toward an inconsistent state. In the DevOps world, it is vital that development, test, and production environments are as close to identical as possible. When configuration drift affects their synchronicity this often accounts for why code works in one environment, but not another.
One of the main causes of configuration drift is the time-poor circumstances that most developers work in – the balance between speed and compliance is a difficult one, and configuration drift is frequently part of the collateral damage of a high-speed DevOps working culture.
We can slow drift down by using the right tools and sound automation practices, however, it is inevitable that environments drift over time, and become increasingly different as a result of ad-hoc manual changes, updates, and other unplanned factors. These gradual changes in software configuration generally remain unobserved until they lead to application failure, at which point it can become a time-consuming, and painful task for software engineers to try and identify why code working in one environment behaves differently elsewhere.
What can we do about Configuration Drift?
One option to prevent configuration drift is to regularly destroy your environments, then rebuild them using automated tools or virtual machines. This, however, does not necessarily take into account real-world situations – for example just because a build phase is automated, it doesn’t preclude the possibility of ad-hoc changes down the line, and when it comes to rebuilding environments to keep them in sync, this isn’t always possible due to constraints such as deadlines and other priorities.
So, the question becomes how can we better manage configuration drift? Firstly, and importantly, we acknowledge that configuration drift cannot be prevented outright. Secondly, we use a tool such as LimePoint’s DriftGuard to monitor and detect configuration drift, and lastly, we notify the engineers responsible that drift has occurred, so they can proactively correct it before it actually impacts the release cycle.
A good configuration drift management tool will allow you to detect changes as they occur, compare data before and after any planned Changes are implemented, compare environments with other environments, compare environments with themselves over time, provide an audit of any changes made, and provide automatic notifications if unexpected changes are detected. And through all of this it will help to ensure that any rectification performed is in response to notification alerts – not application, or release cycle failure.
In the end, managing your configuration drift in relation to your development environments can be considered just another technique like effective testing, codebase management, and infrastructure as code, however, it really should form part of your DevOps arsenal, and become an integral layer in ensuring your release cycles are not plagued by hidden issues relating to your environment synchronicity.