Continuous Delivery Office Hours Ep.9: The compliance ratchet
/
RSS Feed
Share
Link
Embed
In this episode of Continuous Delivery Office Hours, Steve Fenton is joined by Octopus Deploy founder Paul Stovell to explore the hidden bottleneck in the AI productivity conversation that nobody is talking about: compliance and risk tolerance.
Everyone wants code written faster, so they are turning to AI to make it happen. But the constraint is never coding speed, it’s the organization’s appetite for change… and that means things are about to get more painful.
The physics of organizations means faster change generation will create an equal and opposite reaction in risk-averse environments that introduces irreversible road blocks.
Listen to find out more about:
Why developer velocity was never the real bottleneck in regulated organizations
The compliance ratchet: why risk requirements only ever go up, never down
How AI could be applied to risk assessment rather than just code generation
Why fragmented on-machine AI agents are creating a UX coherence crisis
The product velocity bullseye and why direction matters as much as speed How to avoid inviting regulation by rolling out AI responsibly
CD Office Hours Ep.8: AI efficiency and effectiveness
/
RSS Feed
Share
Link
Embed
In this episode of Continuous Delivery Office Hours, Tony Kelly, Bob Walker, and Steve Fenton discuss some of the tangled pathways around AI, the search for efficiency and productivity, and the need to re-focus on effectiveness and outcomes.
You’ll find out about the beneficiary user versus end user divergence and where asymmetry can cause bad outcomes for end users and, ultimately, organizational goals. This leads to why the organizations succeeding with AI had the right foundations in place before their AI adoption.
In this episode of Continuous Delivery Office Hours, Tony Kelly, Bob Walker, and Steve Fenton discuss modern multi-tenancy and how different it is today than during the SaaS revolution.
Multi-tenancy has a single purpose; sharing resources between users to get higher utilization from physical infrastructure by sharing it. Originally that meant time sharing on a single computer when it was too expensive to put one on every desk (and in every pocket). When SaaS gained traction, it often meant designing a single application to handle the workloads and data for many tenants, which might be entirely different companies.
Modern multi-tenancy leans into the lightweight containerization options available today, where the sharing can be handled at the infrastructure level and applications no longer need complex architectures to manage multiple tenants. This reduces the amount of compromise surfacing through the application’s design and eliminates many of the scaling challenges.
Listen to find out more about:
Different application architectures for multi-tenancy
The goals and own-goals caused by multi-tenanted architecture
Real-world stories of multi-tenancy for large-scale applications
In this episode of Continuous Delivery Office Hours, Tony Kelly, Bob Walker, and Steve Fenton discuss the purpose and common pitfalls of software change approvals. They argue that strict, manual change approval processes are often just a reflex to past organizational trauma and an attempt to have “humans on the hook” to blame, rather than a valuable safety measure.
Relying on excessive bureaucracy, like formal monthly review boards or demanding multiple manual sign-offs, significantly reduces deployment throughput and, according to DORA research, actually makes systems less stable. Instead, the experts advocate automating the vast majority of checks, like tests, linting, and scanning for dangerous database commands, so that human reviewers step in only to evaluate a filtered subset of complex or high-risk changes.
Effective change management requires small review requests and daily co-ordination rather than formal change approvals.
Listen to find out more about:
Change approval processes are often based on past organizational trauma
Most checks should be automated
Excessive manual approvals wreck throughput and reduce stability
While application code deployments have become highly automated and disciplined, database changes often remain manual, “folksy,” and prone to causing messy environment drift. Find out why databases require a uniquely cautious approach due to the severe risks of data loss and the impossibility of simple rollbacks, emphasizing the need to treat database deployments with the same rigor as application code.
Your system’s architecture can support team autonomy, independent deployability, and independent evolution of components, or it can be a sticky mess. This episode looks at whether choosing a monolith or microservices fundamentally changes the crucial properties of your architecture.
Your branching strategy can support Continuous Delivery, or make it an impossible goal. Teams should assess the impact of how they branch on their ability to deliver software at all times, and that means there are some branching techniques that make software delivery more like walking in the dark through a field of rakes.
To ensure software is deployable, teams must shift from manual testing to automated pipelines. Automation provides immediate feedback, captures institutional knowledge, and reduces long-term costs. Strategies like the Strangler Pattern help modernize legacy code for greater reliability.
Listen to find out more about:
How deployability depends on continuous automated verification
How automation is a long-term crucial investment
Strategies for modernizing legacy code
How automated tests are a form of living documentation
Why leadership buy-in and cultural alignment is a necessary pre-condition
CD Office Hours Ep.1: Prioritizing Continuous Delivery
/
RSS Feed
Share
Link
Embed
Tony Kelly hosts our first episode of Continuous Delivery Office Hours, with Bob Walker and Steve Fenton.
In this episode of Continuous Delivery Office Hours, we ponder why prioritizing Continuous Delivery (CD) is essential for managing risk. We challenge the common instinct to reduce deployment frequency after failures, using a dentist analogy to explain how delaying deployments increases pain and risk by allowing unchecked changes to accumulate.
We advocate decoupling “deployments” (moving code) from “releases” (exposing features) using trunk-based development and feature toggles, which lets you test safely in production and avoid the deadlocks of complex dependency management.
