OUR THOUGHTSTechnology
Pathway to production
Posted by Gareth Evans . Aug 01.24
What is a ‘pathway to production’? A pathway to production is the end-to-end process and infrastructure through which code changes flow from development to release in production to customers.
The pathway encompasses all stages of the software delivery lifecycle including development, testing, integration and deployment. It’s characterised by high levels of automation, continuous integration and delivery (CI/CD) practices and a focus on removing bottlenecks and reducing manual interventions.
An effective pathway to production is designed to be repeatable, reliable and effective, enabling teams to deploy changes quickly and safely. It includes automated testing, security checks and compliance validations at various stages, ensuring that only high-quality, vetted code reaches production. This approach aligns with key DevOps principles of collaboration, automation and continuous improvement, ultimately supporting the goals of improving the flow of work through the system from concept to cash.
A pathway to production typically includes the ability to switch features on in production, decoupling deployment from release. It may even enable the release of features to groups, regions or other demographics to assess fitness for purpose, usage, etc.
The pathway to production determines the smallest unit of work a team can continuously learn from. It starts when a product development team changes a line of code or configuration through all the steps required to get that change into production where customers can use it. It includes all automated checks, layered tests, infrastructure provisioning, schema changes, regulatory gates, observability configuration and manual approvals that every committed change passes through until it appears as a feature in your customer's hands.
The goal of the pathway to production
The goal of the pathway to production is to fully automate flow. This includes automating infrastructure deployment, testing, compliance, security and operations. A fast, smooth path to production should be consistent and repeatable and require few manual actions.
An effective pathway to production allows teams to test value hypotheses in production with customers. The aim is to add early and frequent value delivery into production, with the ability to validate hypotheses with customers. It lowers the cost of each learning cycle with customers.
A pathway to production must consider end-to-end flow across all technology layers and cannot be designed without high levels of collaboration between teams involved in changing various technology layers that interact with each other.
Technology-accelerated pathways
Modern technology can significantly improve the average time it takes to traverse the pathway to production. Modern quality practices reduce problems and rework, allowing you to deliver more features in a given time period. The pathway to production is your primary mechanism for creating flow in a new delivery ecosystem.
Modern technology applied to your pathway to production will significantly improve the average time it takes to get each unit of work into customers’ hands. It will also improve quality by reducing inconsistency and manual effort. While investment is required to establish an effective pathway to production, once established, it reduces the transport cost for all future features, allowing you to deliver smaller batches of work more frequently.
Policy shifts to optimise pathways
Existing organisational policies may constrain the frequency of change. For example, policies might mandate manual regression testing due to a lack of automated tests, slowing down the release process. Policy edges that may impact a pathway to production typically arise in areas such as security, compliance, governance or operations. These may include obtaining permission to adopt new tools, conducting regulatory compliance checks or configuring centralised operational observability tools. These policy requirements can range from one-time approvals to pre-release checks, adding additional steps and potential delays to the release process.
The 2022 State of DevOps Report underscores the lack of maturity in deploying and releasing features through a pathway to production for most organisations. The report groups respondents by their maturity level, with the highest-performing cluster labelled as the ‘flowing cluster’. This cluster excels across all characteristics, including higher reliability, stability and throughput. However, only 17% of respondents operate in this optimal state, indicating significant room for improvement across the industry.
Organisations operating at high maturity levels also tend to have loosely coupled architectures, allowing them to deploy small parts of the architecture independently. Modern architecture is designed to enable flow through the deployment of smaller, independent components. However, optimising the flow of value was not a primary architectural consideration for older systems, resulting in few legacy systems designed with this principle in mind. The age and scale of legacy systems are likely to have a significant impact on the maturity of your organisation’s current pathways to production. Even your highest-performing teams may be constrained in their ability to deliver small units of work to customers safely, quickly and frequently. Understanding your organisation’s maturity in this area is crucial for anticipating the changes required to support the new product initiative.
Where to start? Developer experience!
Left-shifting quality is a critical concept in modern product development and is manifested in the pathway to production. This approach emphasises integrating quality practices earlier in the development lifecycle rather than treating it as a later step. By catching and addressing issues earlier, teams can reduce the cost and time associated with fixing bugs later in the process. A proactive stance on quality creates shared responsibility for software excellence across development and operations teams, aligning with DevOps principles. Left-shifting quality enables organisations to deliver more reliable, secure and high-performing software at a faster pace.
Containerised workflows – speeding up inner loop feedback
A container is a lightweight, standalone and executable package that encapsulates an application along with all its dependencies, libraries and configuration files. It provides a consistent and isolated local environment for running software across different computing platforms. Containers are awesome because they are self-contained, isolated, independent and portable. They include everything an application needs to run locally.
Containers can be composed together, enabling developers to create an optimal local development workflow. Imagine being able to run a single command to spin up a local environment that includes the service the developer is working on and all its direct dependencies, such as a database, file systems or other services. The workflow may also emulate the cloud infrastructure locally and include other dependencies, such as authorisation and authentication or mocked third-party services.
A containerised development workflow improves developer experience by speeding up onboarding and learning, providing a consistent environment for developers to get started and safely experiment. The containerised environment allows developers to try new technologies and learn faster through safe experimentation with fast feedback. It also enables the composition of specific versions of services from different technology layers without having to deploy to an AWS environment.
Containerised workflows allow teams to make progress even when other dependencies are not yet available. For example, a team may work with mocks of third-party systems until they become available.
Containerised workflows allow teams to run infrastructure as code locally for all developers without relying on cloud environments. Emulated cloud infrastructure in containers helps test cloud modules before deployment, speeding up integration by finding problems early before they are even deployed to the first AWS environment. Automated build pipelines can be container-based, providing faster feedback on issues. This creates more autonomy for teams and reduces the dependency on centralised teams, helping products make progress faster from the start, reducing delays and improving predictability.
When combined with improved quality practices, teams typically operate with less than 5% defect rates. When teams adopt layered test automation with good coverage and quality of tests, we often observe over one million unit and integration test executions in a six-month period. That is a whole lot of checking for every single change, the value of which increases as the system grows.
When we help organisations adopt containerised workflows, we typically see 10 times faster feedback cycles for developers. This accelerates learning by providing feedback on changes without having to deploy to cloud environments. Containerised development workflows allow teams to upskill quickly with fast feedback. Teams are able to safely experiment with new technology to accelerate learning. Developers can learn new languages and architectural and technical patterns within a few months; they can pick up new patterns quickly and maintained quality as they do so.
Are you ready to transform your software delivery process and accelerate flow? Our expert services are designed to guide you through every step of this critical journey. With a deep understanding of CI/CD practices, automation and DevOps principles, we specialise in creating secure, reliable and repeatable pathways that enable your teams to adapt to your customers needs faster.
Say [email protected] to optimise your pathway to production and deliver value to your customers, earlier and more often.
More Ideas
our thoughts
How to build an AI code copilot that responds with your own code
Posted by Tony Luisi . Dec 16.24
AI coding assistants and copilots continue to evolve and become more useful, reshaping the industry and changing the skills developers need to be productive. While these tools can be helpful, they also currently come with a significant drawback – they’re trained on a vast number of repositories of average code. The code they suggest reflects the quality of all the code they’ve been trained on, including excellent and problematic patterns.
> Readour thoughts
CEOs, software funding and budget mechanisms could damage your investments
Posted by Daniel Walters . Dec 12.24
I’ve worked with many executives who have great intentions and aspirations for their companies. They’re frustrated that their energy and investment in software development are not meeting those aspirations. Some find a path to success, but many fail to produce software that meets the expectations to compete.
> Readour thoughts
Seven tips to improve flow – inspired by your holiday travels
Posted by Steven Gibson . Nov 26.24
As summer approaches, it’s time to switch off laptops, pack bags and head to your favourite beach or holiday spot. Whether you’re off to the Coromandel, Bay of Islands, the Gold Coast or beyond, the journey itself offers some valuable parallels to how work flows through your organisation.
> Readour thoughts
Improving security with flow engineering
Posted by Gareth Evans . Nov 25.24
How do you improve security while delivering valuable software at speed? Traditionally, security and speed have been viewed as opposing forces, creating a false dichotomy that has hindered both objectives. However, balancing defence and response can enhance security. With the right engineering practices in place, accelerating the flow of value improves security rather than compromising it.
> Readour thoughts
CEOs, is your culture sabotaging software quality?
Posted by Daniel Walters . Nov 07.24
When I speak with CEOs, they often feel frustrated by their teams’ perceived lack of pace and urgency. They hear their customers’ expectations, their sales teams’ calls for new things to talk about and their competitors breathing down their necks. From their perspective, the product development teams are falling short of expectations.
> Read