DELIVERY APPROACH
We think of delivery in terms of Value Chains. This is because ‘Value’ is created for an organisation by software only when that software is delivered into production and is made available to users. There are many ways of defining a value chain; we define it as the generalised set of activities that, when linked together, progress a product from a local development environment to a production environment. These activities include quality gates (e.g. QA acceptance tests, performance tests, system integration tests and even automated security tests), automated propagation from one environment to the next and green/blue deployments into a live environment.
Our view of the value chain centres around environments as each has a discrete set of activities must take place in order for progression to take place.
The objective of the Boost delivery model is to ensure that moving through the value chain is as efficient as possible by:
Identifying and removing friction from the delivery processes.
Ensuring that stories committed to by the team during Sprint planning have passed QA and are ready to be (or have been) deployed into the SIT environment by the end of the Sprint.
Ensuring that all quality control processes are automatically adhered to and are an integral part of the propagation of software through the value chain.
This is achieved by:
Ensuring that an immutable image created during the build stage is promoted through the value chain unchanged, reducing the risk of configuration drift.
Ensuring that environmental bottlenecks are removed by allowing testers and developers to recreate end-to-end environments using versioned automated processes in minutes (either locally or in the cloud).
Ensuring that containers are propagated between environments only after passing extensive quality gates that are 100% automated.
Removing tightly coupled dependencies during continuous integration by isolating dependencies between containers so that developers need only focus on writing code for specific microservices services.
Incorporating monitoring and tracing tools into the delivery process to provide feedback on any delivery issues.
Continuously monitoring infrastructure and microservice instrumentation so that alerts can be created for production issues.
Reducing rework due to defects caused by environmental and configuration drift by versioning the entire value chain source (including all automation) each time the product progresses from one environment to the next within the chain.
Detecting and addressing issues as soon as they occur and remedying them as quickly as possible.
Having a cross-functional team with shared goals for each Sprint.
Implementing behaviour-driven development, where tests are reviewed by all team members and customer stakeholders early in a Sprint.
Shared development of test automation across the team.