Earlier this year, I wrote about a new approach my team is pursuing to inform our Container Adoption Program using software delivery metrics to keep organizations aligned and focused, even when those organizations are engaging in multiple workstreams spanning infrastructure, release management, and application onboarding. I talked about starting with a core four set of metrics identified in Accelerate (Forsgren, Humble, and Kim) that act as drivers of both organizational and noncommercial performance.
Let’s start to highlight how those metrics can inform an adoption program at the implementation team level. The four metrics are: Lead Time for Change, Deployment Frequency, Mean Time to Recovery, and Change Failure Rate. Starting with Lead Time and Deployment Frequency, here are some suggestions for activities that each metric can guide in initiatives to adopt containers, with special thanks to Eric Sauer, Prakriti Verma, Simon Bailleux, and the rest of the Metrics Driven Transformation working group at Red Hat. .
Lead Time for Change
Providing automated, immutable infrastructure to development teams. Use OCI container images to define a baseline set of development environments to developer teams and allow self-service provisioning for new projects.
Building automated deployment pipelines. Create deployment pipelines using build servers, source code management, image registries, and Kubernetes to automate previously manual deployment and promotion processes.
Building unit tests. Unit tests are often talked about but still too often left out of development activities, and they are as relevant and important in cloud or Kubernetes environments as they are in traditional deployments. Every piece of code with faulty logic sent back for rework by a manual test team represents unnecessary delays in a deployment pipeline. Building unit tests into an automated build process keeps those errors close to their developer source, where they are quickly fixable.
Automating and streamlining functional testing. Just as unit tests avoid time-consuming manual testing, so does the automation of functional acceptance tests. These tests evaluate correctness against business use cases and are more complex than code-level unit tests. That makes them all the more important to automate in order to drive down deployment lead times. The contribution of Kubernetes here is ability to easily spin up and destroy sophisticated container-based test architectures to improve overall throughput.
Container native application architectures. As the size and number of dependencies in an application deployment increases, the chances of deployment delays due to errors or other issues in the readiness of those dependencies likewise increases. Decomposing monoliths into smaller containerized, API-centric microservices can speed deployment time by decoupling the service from the deployment lifecycle of the rest of the application.
Deployment Frequency
For implementation teams, deployment frequency is as much about development processes as it is about technical architecture.
Iterative planning. Deployment frequency is in part a function of the way project management approaches the planning process. Each release represents an aggregation of functionality that is considered significant or meaningful to some stakeholder. Rethinking the concept of a release at an organizational level can help improve deployment frequency. As project managers (and stakeholders) start to reimagine delivery as an ongoing stream of functionality rather than the culmination of extended planning process, iterative planning takes hold. Teams plan enough to get to the next sprint demo and use the learning from that sprint is input for the next increment.
User story mapping. User story mapping is a release planning pattern identified by Jeff Patton to get around the shortcomings of the traditional Agile backlog. If Agile sprint planning and backlog grooming is causing teams to deliberately throttle back on the number of software releases, it may be time to revisit the Agile development process itself, replacing by-the-book techniques with other approaches that may feel more natural to the team.
Container native microservices architecture. Larger and more complex deployments are hard to deploy cleanly. It is difficult to automate the configuration of deployments with a large number of library and infrastructure dependencies, and without that automation, manual configuration mistakes are bound to happen. Knowing those deployments are painful and error-prone, teams inevitably commit to fewer, less frequent deployments to reduce the number of outages and late night phone calls. Breaking a large monolithic deployment into smaller, simpler, more independent processes and artifacts makes deployments potentially less painful, which should give teams the assurance to increase deployment frequency to keep pace with customer demands.
These are just a few team-level techniques organizations can pursue to improve Lead Time for Change and Deployment Frequency, the software delivery metrics associated with market agility. In the next posts, I’ll outline some techniques teams can pursue to improve upon the measures of reliability: Mean Time to Recovery and Change Failure Rate.
