Zero-day delivery changes the way you perceive the first steps of a new idea, or a new feature, or a change in your software.

The cool thing about software is how quickly you can make ideas a reality if you set things up right. Ideas are what give businesses the oxygen they need to stay ahead.

And the feeling of getting a good idea is hard to beat, but for many businesses what comes next is the hard part. What would it feel like to see the realization of your idea the same day you came up with it?

This is in my opinion the next frontier of DevOps, and it’s called zero-day delivery.

Zero-day delivery borders with continuous delivery

Continuous delivery produces software in short cycles, increasing speed and frequency and reducing error. Continuous delivery means you have the capability of deploying your code and make it available for use, but the last stage of customers actually experiencing changes to your product is a manual process. The practice of even this last phase being automated is called continuous deployment.

Continuous delivery is an important move away from traditional methods that rely on organizational siloes. However, most of the leading adopters of continuous delivery are not taking its potential far enough. They’re still practicing traditional methods when moving from the business idea to design, from design to development, or from the finished feature to a released product.

When an organization gets in its own way

The waterfall model of developing software

Continuous delivery requires a certain kind of organizational culture and certain practices to be in place to deliver continuously. Still, organizational siloes can mean that the delivery can’t start right away, it has to wait for a number of steps first.

Companies well into their DevOps journey (journeys which often involve organizational change) have the capacity to accelerate the entire process, all the way from the idea to releasing your update.

However, instead of using this potential, many are getting off to a walking start by only using continuous delivery halfway through their journey from idea to product: either during the development, or in the production environment, but not all the way through.

Continuous delivery needs to be set free to live up to its full potential. This potential is something I call zero-day delivery.

Zero-day delivery is powered by big picture DevOps

Imagine this. When you start a software project, or even better when you decide to start a software project or are considering a software project, it could be running in the production environment that same day.

Unlike the idea you had, this isn’t an act of the imagination. It’s a continuous delivery (but why not deployment too?) pipeline of tools and project templates including, for example:

  • connections to requirements management and version control
  • a design system and its UI components
  • automated test templates, infrastructures
  • release automation.

image-43-2You can throw your idea down the pipeline and software comes out the other side. Only 10-20% of the code is the product itself and everything else is shared components, templates and practices supporting DevOps at its best.

The project templates are the starting point of a new idea. They're connected to the toolchain, so that even when you clone that first part of the code, and even if it was only 10-20% of the original template, you already have a key to the production environment waiting in that template.

The benefits of zero-day delivery are immense

zero day delivery- continuous delivery
  1. Zero-day delivery gives you immediate feedback for your idea, which is priceless. You no longer have to wait weeks to know how your new feature behaves or if it is liked by your users. No more demos: you’re looking at your idea directly in the production environment.
  2. Zero-day delivery changes the way you perceive the first steps of a new idea, or a new feature, or a change in your software. You don’t start by waiting, you start by delivering. And from the team point of view, it’s pretty easy. You’ve already established the pipeline and that work has been done in a scalable way. You can pass it on within the organization to other teams as well.
  3. Zero-day delivery takes weeks out of your time to market. When you get the information that something is wrong or something is happening is not what counts. What counts is when your business reacts to it.
  4. Zero-day delivery also encourages failing fast. You can immediately expose bad ideas for what they are (which you might not see when you’re concepting).

Don’t deliver what’s ready, deliver what’s working

Zero-day delivery is the shift from delivering what’s ready to delivering what’s working.

This commits to the smallest possible deliveries which in practice means you’re making smaller mistakes. Also, it enables canary testing: releasing new features for only selected customers and using that information to finish or develop the feature further.

And delivery is not the same as release

Just because you place something into production or a production-like environment, doesn’t mean you have to publish it to your customers that same day. The end user does not need to see it until you flip the switch and turn it on.

The important paradigm shift is that zero-day delivery does not mean releasing only finished features, but instead releasing working software. This removes many integration and test automation problems compared to merging and releasing only ‘ready’ features. Additionally, you can try out a new feature with pilot customers in production before publishing it to everyone.

Zero-day delivery is not a leap of faith. It’s DevOps

The fact that delivery is not the same as release should take a lot of the fear away. But the point I’d like to emphasise is that businesses have nothing to lose. The technology is there to make zero-day delivery a reality and we have seen it in practice.

We are already in a world where delivery cycles are so fast they happen on the day an idea is conceived. It’s not about the competitive edge you create by following these practices, but the opportunity cost if you don’t.

You’re no longer building a watch for a year. You’re building constant, mounting value for your customers, reacting to a complex environment by creating a situation in your business where new ideas happen fast.

Discover the next step of your DevOps transformation   With our most popular DevOps services

Published: Aug 26, 2019

Updated: Apr 30, 2021

DevOpsCI/CD