Deployable vs Releasable
Last week we explored the difference between Continuous Integration, Delivery and Deployment; now we need to state the difference between “deployable” and “releasable”.
Hello, developers! 🚀
Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!
Before starting, I quickly remind you that my brand new Test-Driven Development 101 5-day Email Course is available: it is the introduction to TDD I wish I had when I started learning it, so I think you will find it very useful!
As a subscriber to my newsletter, you can have it with a 10EUR discount! 👇
Now, let's dive into today's micro-topic!
In short
💻 Most people in the industry use deploy and release with the same meaning, but when you want to implement CI/CD you need to separate the idea of something ready for production from something ready for the user.
🚀 We can describe a deploy as the technical act of copying software to a host environment and getting it ready for use, while a release is the act that makes a new feature available to users.
🔄 Separating deployment from release supports the flexibility of Continuous Delivery, making it easier to respond quickly to user demands while keeping quality and reliability intact.
Aren’t deploy and release the same thing?
Last week we explored the difference between Continuous Integration, Delivery and Deployment: one of the key distinctions we need to state when trying to implement CI/CD is the difference between “deployable” and “releasable”.
Most people in the industry use them with the same identical meaning, but when you want to implement CI/CD you need to split the idea of a deploy/release (as most people intend them) into 2 different ideas:
the technical act of copying software to a host environment and getting it ready for use
makes a new feature available to users
When we usually think to a deploy/release, we think to both of the 2 points done together at the same time, but when doing CI/CD you want to differentiate them because you will release so often that you need to make a difference between what can go in production (which is a purely technical question) and what can be seen from users (which is also a business/marketing question).
According to minimumcd.org, we can refer to point 1 as “deployment” and to point 2 as “release”.
Deployable: Ready for Production, But Not Yet Available to Users
For every organization, there should be non-negotiables in place for delivery. These may include security, compliance, stability, responsiveness, etc. The pipeline should be the final word for this. This is what we call “definition of deployable”.
When software is deployable, it means it has met all quality, compliance, and security requirements and is technically ready to go live at any moment. A deployable version passes every stage of the pipeline—tests, security scans, and other critical checks—making it safe to move to production. Deploying simply means transferring the code to a production environment, where it’s held, prepped, and ready.
The key here is reliability. Achieving a deployable state is non-negotiable for quality teams, as it means you can deploy with confidence whenever business needs dictate. Think of deployable code as a product stocked on the shelf, ready to be sold, but not yet in the hands of customers.
Releasable: Available to End Users
Releasable software, on the other hand, is about the end user. When a feature is released, it is now accessible to users. Release controls such as feature flags allow teams to toggle features on and off, releasing only when it makes business sense, or rolling them back if needed. This approach grants greater flexibility in timing and helps deliver value safely and strategically.
In short, all releasable code is deployable, but not all deployable code is immediately releasable. This flexibility is central to Continuous Delivery, allowing teams to maintain a constant flow of work and respond to user needs without compromising reliability.
Deployable vs Releasable: an example
Let’s make an example to make sure the difference is clear: imagine we have a system where we want to add a new page with a form to submit ideas. The form will be releasable when all the expected fields are in place and the submitted data is saved correctly.
As in almost every situation when doing CI/CD, for one release we will have multiple deployments. We might even have a deploy for every single field we add to the form. Every time we commit a change to the main branch and the pipeline is green, we will have a deployment. The release, then, will just happen super easily whenever is needed from business/marketing/any other driver for the decision.
This means that, from the first deployment to the release, we need to keep the form hidden from the user: in other words, we need a way to keep the work in progress hidden. In this simple example, the page route might just be hidden and accessible only for specific users, when a specific query param is used, or when a feature flag is activated at configuration level.
There are multiple ways to hide work in progress (have a look at Martin Fowler’s suggestions, for example), and usually the complexity of the solution is inversely correlated to the safety we need: the more sure we want to be that no one ever see the work in progress, even by accident, the more complex solution we can use. Most of times, a simple one will be enough.
Until next time, happy coding! 🤓👩💻👨💻