Churn and the evolution of test environments

Writing two blogs (this one and one internal work blog) and maintaining my Masters studies is a bit of a stretch currently – so apologies for any regular readers. While I finish off my current TMA and eye up my next, here is a copy of a blog I did recently for work – it describes the concept of Environments Churn and how it impacts the role of the Test Environment Manager..

What is Environments Churn

Environments Churn is a useful measure of application stability for test environments. It is also a metric that can be used to help identify the nature and focus of an Environments Manager role.

  • Low environment churn means that the Environment Manager is supporting a stable set of environments for a fairly stable product.
  • High environment churn signals a likelihood that the Environments Manager is supporting a fast changing product with high levels of uncertainty.

Low Environment Churn

Low environment churn happens in a Portfolio that is supporting applications which rely on stability  as opposed to fast paced and dynamic change.

With low churn, it is possible to plan ahead by multiple quarters or years. Budgeting for low churn environments is about attaining  repeatability, availability and high data quality.

Environments will have life-cycles of months or years, instead of days or weeks. They are however, restrictive in number and have to be strategically planned and utilized as virtually all projects will be expected to use them on their path to live.

Low environment churn is compatible with centralised ‘enterprise’ environment function as it is critical to keep track of everything and everyone using every environment or you lose baseline assurance.

What is the role of a EM in a low churn Portfolio?

EMs in this sort of environment need to be able move seamlessly between high level Portfolio planning and low-level Environment details. Having access to a good cross-section of technical and change specifications will also help the EM to keep track of the environments ‘pool.’

The primary tension with these sort of environments is creating a balance between environment stability, and ensuring ‘cohabiting’ projects do not crash into each others changes. Data pollution is a big risk with these type of environments.


High Environment Churn

High environment churn happens when you have a rapidly evolving set of deliverables and teams are working on highly dynamic technologies. These are teams that are developing and experimenting with very short term pieces of work; fail-fast, proof of concept, minimum viable product.

High churn environments may only be used for a couple of days, weeks at most.

Organisations which move towards micro-services frequently have large numbers of these short term environments that they spin up and rip down as required. In a high churn environment, test environments should be easy to create.

A high churn Portfolio will encourage more environment automation and self service management, as it is faster to put these controls directly into the hands of the developers to create when they need them.

What is the role of a EM in a high churn Portfolio?

The EM role  transitions from day-to-day implementation to week-to-week governance.

Providing unlimited access to environment creation tools can easily morph into environment pollution if its not actively managed. Environments pollution refers to environments that have become abandoned over time and not shut down, or have become unreliable as they have not been kept in line with Production. The EM role evolves from build management and scheduling, to quota and capacity.


What about the space inbetween?

High and low churn environments are polar opposites. It is in the grey area between the two where we find many of the tensions which affect Environments Management today.

As IT products and projects move towards faster delivery and agile methodologies, and systems become more complex and interconnected, teams are finding that their low-churn environments cannot keep up with demand; they take too long to build, they are too expensive, keeping track of the configuration is too difficult, there are not enough of them…

As our systems move towards micro-services and automation, these constraints will start to  decouple and transform these bottlenecks. As we evolve our environments to meet this need, so we will start to see the Environment Management role evolve alongside it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s