Continuous Deployment in Practice
Even MVP Is Too Big to Be Released at Once
In my work as an engineering leader, I spend quite a lot of time reading various reports—about technology, the IT market, trends, research papers, and more. Among the many publications, there are two I always eagerly await and read almost immediately after their release.
One is the annual DORA State of DevOps Report, which I briefly covered a few weeks ago. The other is Thoughtworks' Technology Radar, a semi-annual overview of recommendations related to tools, techniques, platforms, languages, and frameworks.
I won’t summarize the key takeaways from the recent Radar—its breadth means everyone should explore what’s most valuable to them. However, one particular subject caught my attention and brought a lot of thought: the practice of continuous deployment.
In today’s article, I invite you to explore what the true desired state of CI/CD processes could look like and what it means not only for technology but also for product and business stakeholders.
Here, you can find a PDF cheat sheet summarizing this article.
Continuous Deployment
Here’s a quick reminder. CI/CD stands for two practices:
Continuous Integration: This usually involves triggering automated tests and builds to ensure your changes integrate without breaking the system. Integration means combining code into an existing, shared codebase.
Continuous Delivery: This goes beyond CI by ensuring the integrated codebase is always in a deployable state. It automates the entire software delivery pipeline (build, test, package, and stage), so the software can be delivered to production at any time.
However, readiness doesn’t imply that deployment happens immediately. In fact, many organizations incubate their codebases for weeks—or even months—keeping them in a (relatively) deployable state before finally pushing to production.
That’s why there is a third practice built on top of CI and CD. Continuous Deployment extends Continuous Delivery by automatically deploying every change directly to production, delivering updates to users without manual intervention.
The latest Thoughtworks Radar recommends adopting exactly this practice:
We believe organizations should adopt continuous deployment practices whenever possible. Continuous deployment is the practice of automatically deploying every change that passes automated tests to production. This practice is a key enabler of fast feedback loops and allows organizations to deliver value to customers more quickly and efficiently. (...)
Push Everything to Production, ASAP
Many companies today adopt Agile practices—working in Scrum sprints, demoing developed solutions on a weekly or biweekly cadence, and splitting work into deliverables of up to one week.
Many product organizations have also introduced the concept of MVP—a minimal viable product that addresses three critical risks:
Value Risk: Will customers buy it?
Usability Risk: Will users know how to use it?
Feasibility Risk: Can we build it with the resources we have?
(You can read more in my article: MVP, PoC, or Prototype).
But even with such agility, continuous deployment sounds unattainable, to say the least. Pushing each branch—or sometimes even a single commit—straight to production? Crazy. 🤯
Such an approach seems feasible only in two cases:
You’re bootstrapping a startup where each commit lands on
mainbecause no one is using your product yet.Your product is extremely mature and widely adopted, and you’re delivering only minor changes—like tweaking a button’s color—which could indeed be a one-commit change delivered straight to production.
Nothing else will work, right?
MVP Can Take Months to Develop
The reality is that no matter how "Agile" you are, building a product feature that is valuable, usable, and feasible can sometimes take months. It often involves multiple engineers across backend, data, frontend, infrastructure, and other domains—frequently spanning multiple teams.
Even with Continuous Integration and Continuous Delivery practices in place, the final deployment often happens in a waterfall-like, all-at-once push. And in most cases, the final product doesn’t work as expected in the first try.
As an engineering team, can you do better? Yes. This is where Continuous Deployment comes into play.
Split Your MVP Into Even Smaller Pieces
Here’s a real-life situation that was eye-opening for me.
The organization I worked for wanted to develop a card management solution enabling customers to save their credit cards in our system for recurring payments.
The work involved backend (card validation and storage), frontend (card form and management screens), and infrastructure (security-related tasks) and others. The MVP was to allow some specific users to save their cards and then select them manually for their payments.
When we approached a demo day, the product was only a few days into development. The team had just one microservice deployed to production: the card BIN validator, which wasn’t even connected to anything else. A Product Manager opened a REST client and asked, “Who will give me the first six digits of their card?”
The REST call response was:
{
"cardType": "CREDIT",
"cardBrand": "MASTERCARD",
"isoCountry": "POL",
//...
}Business stakeholders were… excited to say the least. 🤩
Suddenly, everyone took out their cards to test the endpoint. Even though we were weeks away from launching a fully functional product, that day, everyone was impressed! Progress was tangible, and everyone understood what had already been achieved.
Here's the thing. In the relationship between Engineering and Business, things are "done" only when they work. This is where most misunderstandings arise.
If you say, "The service's code is already finished, merged to main, released to the staging environment," it effectively means that the work is not done.
If you say, "Microservices are ready, web app is ready, mobile app is on the last mile—once team X finishes it, we only need to push everything to production," this work is also not done. Sometimes, it's hard to even understand if this is 50% of work or 90% of work.
But if you say: "Card validation is done, card storage is done, mobile app is in progress, but if you visit this secret link on web, you can make payment - for now only Mastercard, but it works in real life" - suddenly everyone more-or-less understands what’s the progress and how much of the work is done.
Continuous Deployment Will Simplify Things For You
Continuous Deployment is exactly about that. By pushing things to production, you de facto show the business real progress, enable early validation for the product team, and simplify the release process for the engineering.
The last one is critical for you. Even if you do Continuous Delivery (constant readiness to go live), releasing a few things at once during a single launch event is hard to coordinate. It's very likely things are coupled too much, and the only way to test them is either through manual checks or extensive end-to-end tests. And when something goes wrong, you have quite a big chunk of changes to investigate.
If you deploy continuously, you were already forced to decouple things beforehand. Most likely, you have developed different ways for pushing the backend independently from the front or even making each service independent from the others. This independence can come from among others:
Good functional testing practices,
Contracts and interfaces, contract testing,
API versioning or other routing practices,
Good telemetry and alerting,
etc.
In Continuous Delivery, we don't pay that much attention to these things. Functional testing, contracts, API versioning - these are nice to have, but if you deploy everything at once, there is this illusion that your product will test itself.
For example - why test your backend extensively when there will be a frontend app released with it, most likely with some E2E tests on top of that? In such case, it's tempting to not test your API in isolation because what for... 🤷.
How to Do Continuous Deployment?
Continuous Deployment requires a high level of organizational maturity, including:
Confidence in the test suite: tests must catch nearly all critical issues.
Low mean time to recovery (one of DORA metrics): Even with great tests, issues will slip through, so teams must respond quickly.
Cultural shifts: Not every organization is ready to deploy changes to production many times a day.
Release throttling practices: even if change is released to production, it’s invisible to customers until you decide differently
Yet, even though it's not easy to achieve, it should be the desired state for all engineering teams and their leaders.
Here are some pieces of advice and further reading materials that can help you move closer to Continuous Deployment.
Trunk-Based Development
Although Continuous Deployment is a cultural shift for the entire organization, including technology, products, and the entire business, it starts with pure technical aspects. One of them is the way we approach managing our source code.
If I have to pick single starting point for such transformation, it would be the implementation of Trunk-Based Development, which is s a foundational for Continuous Deployment. This is because:
It eliminates long-lived branches, which delay integration and complicate deployment pipelines.
It enables the frequent, small commits required for reliable automated testing and fast feedback loops.
It reduces conflicts and ensures a consistent, deployable codebase is always available.
For more, I recommend checking the official source: trunkbaseddevelopment.com.
Transforming the Way You Deliver Software
While trunk-based development can be fundamental for continuous deployment, it's just a single technical aspect. Transformation of how we deliver software is much broader and touches aspects like:
Frequent, small releases, through continuous delivery process,
Measuring how each feature of the product is being used through product analytics,
Monitoring the technical stack behind the product through observability practices (monitoring, alerting, tracing, etc.),
Controlling how changes are released to customers (feature flags, early access).
Even though these things are still very technical, they also have direct impact on how the entire product organization works.
Such approach is called Product Operating Model, and I dedicated a series of articles to this subject, which you can find here: The Role of Engineering in Product Model Transformation - Changing the Way Product Is Built.
Approach to Testing
One of the biggest changes in CI/CD processes is the shift in testing practices. While continuous integration or continuous delivery assumes that there are some test automations in the process, continuous deployment needs much more than that.
Tests must be fast to execute, owned by the team, and ideally defined before we even start the development. This approach, often called QA Shift-Left, will give you enough confidence about the quality of the software you deliver.
For more on the subject, I invite you to read "Do You Need More Testers or Better Tests?"
Slowification and Simplification
Continuous Deployment is much more than just the technical setup of your CI/CD pipelines. It's a transformational shift that can make your company successful through two processes: Slowification (making the problem-solving process easier) and Simplification (making the problems themselves easier).
Continuous deployment will force you to take a more thoughtful and measured approach to delivering your software. It will often require taking a step back to ensure that each change you implement either adds value or reduces risk. Knowing that your implementation will very soon land in production environments, you will think twice about the expected outcome of this work.
You will also do the homework to decouple your system as much as possible to guarantee that changes can be pushed in isolation and won't easily break your entire system. And if they do, the process of fixing them will be as quick as possible.
To understand these processes in detail, I invite you to read the entire series on Slowification, Simplification, and Amplification.
End Words
Continuous Deployment isn’t just a technical setup—it’s an organizational and cultural transformation.
While challenging, it enables faster delivery, better feedback loops, and greater resilience, making it a worthwhile goal for any engineering team.