Goods require shipping. Software should not. Despite the IT industry successful move to detach the release management and need to physically transport the product, the ‘shipping’ is still creeping into the software development nowadays. Well, it’s even worse - it got embedded into our thinking. We don’t release, we ship. Those two became synonyms. What’s wrong with that, you ask?

Shipment of the product by itself doesn’t add any value to the customer and represents direct cost for the software vendor. We can call it waste. As we are taught the best thing we can do to eliminate waste is to try to reduce the activities where such a waste is produced. So, let’s not ship everything. Yes, the obvious and safe bet is to bundle as many features as possible to a single release. Iteration cycle time is getting longer and therefore expensive. If you want to bet the company’s well-being on a single (even though repetitive) milestone, you better invest some serious effort to make it worth while. That means testing. The safety net of testing of software is focused on improving testing coverage. Unfortunately as your product grows, QA has to do exactly the same. Overhead is increasing. Just when we assume we have reduced one type of waste we actually introduced the new one - waiting. Now we got two types of waste. Waiting and shipping.

Wait a second! Didn’t we just reduce the impact of the latter? Yes, but only at the end of the release cycle. In the process described above you still have to ship the product, and every time you do so waiting pops in. Waiting before the development team reach the agreed milestone, waiting to test the features, waiting to deploy the product, waiting to educate the user.

If you feel the pain of the process we’ve just described you’re on a good way to start fixing it. Luckily for us there’s already a way out of this mess. Internet not just significantly reduced the shipment cost incurred by a software vendor, it transformed the industry altogether. New vendors became service providers. Subtle change you might say, but it comes with a great simplification. Where software house ships the product to a thousands (or millions) of customers, service provider does it only to one - its internal operations team. No more hard to predict environments, no more unnecessary delays incurred. The pain has moved to a new level, from internal users to external ones.

Close proximity to the customer has already been accepted as one of the main advantages behind Agile movement. Shorter iteration cycles enabled faster feedback, automated testing reduced waiting time between development and testing. Product creation phase started to move faster. Stories got shorter, iterations more aggressive. In such an environment you have to pull down any obstacles to make the flow as continuous as possible in order to eliminate waste.

Traditional paradigms of the software development are now holding one last wall to conquer - deployment itself. In a situation where you have only one customer (you) there’s no more space for a separation of concerns. If there’s no cost behind operations talking to development do you really need to keep them apart? Most likely not. If you already automated most of your product life-cycle, don’t you want to conquer the last mile and automate the deployment as well? Yes! Move from continuous integration to continuous deployment.

I accept it might sound scary at first, because you we are effectively going to remove the last safety net, but you are also going to remove the separation between ‘us and them’. Developers will need to start thinking about every single line of the code in the context of deployment, start thinking as Operations team. And not to stop there Operations will need to start to behave like developers. Both sides have a unique processes and experiences learned over the time that can help the other camp.

And no, you can’t just wake up one morning and switch to continuous deployment. You have to work towards it, reduce waste over time. The implementation of smooth product flow will naturally exposes bottlenecks, expose the quality problems and therefore naturally leads to a reduction of the waste.

Let’s create software, not a new ways how to ship it somewhere.

For non-believers and pessimist the concept of continuous deployment isn’t really something new and coming out of a blue. It’s just a naturally extension of something called continuous flow applied in manufacturing and if you are interested you can read more about it online - Lean manufacturing.