We like to think about application delivery as if it is a pipeline from development to production. Each step in the pipe is usually a separate environment – e.g. a different topology, different configuration and a process for promotion from environment to environment. Just as many process failures are a result of failed hand-offs; many, many delivery problems are the result of promotion process mis-configurations.
Deployment topology is the mapping of components to systems and the dependencies between them. Deployment topology and configuration are the basis for how we measure difference between environments (with topology being much more important than configuration). Difference is influenced much more by the linkages of different element types, less by repetition of equivalent elements, e.g. the relationship between application server, db server and their deployment topology is much more important than the number of nodes in a application cluster.
Applying the principles of six sigma calls for minimizing the variance between environments along the pipeline in order to minimize problems. So in a perfect world it would make sense for all environments to be identical to production – i.e. shift left. In most cases that just isn’t possible, so the trick is to make them as similar as possible – but in all cases the application topology must be identical.
Because the environments are different we can’t be certain of the integrity of the promotion – that is where assurance comes in – by providing the capability of ensuring the promotion process “did the right thing”. Assurance uses topological equivalence and configuration analysis to verify deployment topology across two consecutive environments.