The Why of Continuous Delivery

Introduction

The continuity of operation of any software product is one of the most critical factors of success of a digital transformation. Properly adopted, digital processes posess two profound qualities:

• the quality of software to operate continuously;
• the quality of software to adapt to shifting needs.

The first one looks simple to measure. It seems there is a binary yes-no question that can be fairly simply checked by pretty much anyone:

Is there a downtime?

For software that doesn’t change with time, that’s all you need to care about. We’ve already explored the topic of software product value and it’s failure to produce value when not operating in another article if you’d like to dig deeper.

However, if software needs to change with time (to adopt to market needs, to reflect your internal processes or because the right way is unknowable before trying it out), the problem of continuity becomes a lot more complicated.

That’s why the IT world is adopting means of preserving continuity in actively developed projects. It started over 20 years ago with Agile and eXtreme Programming. DevOps movement and Continuous Delivery are the next pieces of the bigger puzzle to be solved – how to reliably engineer software for the next decade and beyond.

Continuous Delivery is one of the things that you’d want to have if you want to both use software and improve it with time.

What is Continuous Delivery?

So what is Continuous Delivery exactly? You may look at it as a promise that the solution will always be shippable. In other words, as soon as the feature we implement is ready for production, it will be entirely up to you when the users get access to it. You may want to roll it out in the middle of the night during the weekend. You will certainly not need to wait for another release cycle to get the brand new feature on production. You can think of it this way:

The decision whether to show a particular feature to your clients and employees is separated from the development team, because we guarantee it will work whichever moment you choose to enable/disable it.

This requires strong discipline on the part of the development team, including tests, automation, monitoring and even the right mindset.

How can we achieve that when deployments are widely considered tedious and unpleasant processes? The first step to solve this matter is to separate deployments from releases. In order to understand what benefits this separation gives us, let’s discuss deployments and releases.

Of deployments and releases

The deployment is an exclusively technical process, namely the installation of a piece of software, called an artifact, in the target environment. It could, for instance, be a new version of a backend application on your server (or on servers of your cloud provider). Or updating an app on your smartphone. Or laptop. And that’s it. From the developer’s perspective, deployments (especially the manual type) are often the tedious part of work that consumes a lot of time and draws them away from other tasks.

On the other hand, the release is a business-related process, involving giving access to the new features to users of the system when you deem appropriate. In the classic approach to software development, the decision to release the new feature leads to deployment. It requires preparations, sometimes even shutting down the whole system for a while. What is more, the deployment may fail during the process, therefore time to solve such deployment issues should be taken into account and this in turn makes the releases non-instant. In short, it may make the features wait longer than expected to get into users’ hands.

Oftentimes, you’d like to release a whole package of changes to end users. Under classic approach, these changes would accumulate until all of them are ready to be released. There’s a caveat. The changes from other teams are slipping in too. The more changes you introduce at one time, the bigger is the risk that with a lot of changes failures will be introduced too.

As you can see, it would be wise to have the release without the deployment and there is actually a way to achieve that. It’s called Continuous Deployment.

It’s the way to assure that every new code lands immediately in the target environment (even if it is a production server). Our tools deploy even the smallest change within minutes after being made. However, there is a catch. To achieve this, we need to automate the deployment process. Fortunately, there is good news here: usually, the deployments consist of well-established steps that machines can easily handle. As a result, the developer does not need to execute the deployment manually and can instead concentrate on other tasks. It comes with an added benefit that we can make deployments multiple times a day.

It is a win-win situation. Less risk of errors and more velocity in the project. But there is one more challenge to be addressed before we move on.

If the new code deployments are immediate, how to prevent new features (which do not even have to be complete) from being accessed by the users? The solution is pretty simple. We make them inactive until they are ready. There are tools that allow to turn the features on and off. Consequently, while working on a new feature, it comes disabled in the production environment, but is enabled for the staging and test environments.

What is even more interesting, you can selectively turn new features on to a group of users, for instance, to internal testers, to perform acceptance tests of the new functionality in the production environment.

When the new feature fulfills your needs, its release is as simple as flicking a switch. The users get it within seconds. If there are any issues, we can disable it so that it doesn’t hurt software’s operation in any way. Then we can steadily work on the patch instead of doing some wild hotfixes in the production environment, which may cause even more harm.

For you, there is an additional benefit. When you decide to make a new feature available to your customers, you don’t need to wait for us to do our part with the deployment. It’s at your fingertips.

What about quality assurance?

So, if the production environment gets the new code immediately, how do you check for errors?, you may ask. It’s a pretty reasonable question, as it might look like there is no time to do proper quality assurance on the delivered product. However, it’s quite the opposite. We perform lots of tests, both automated and manual.

Automation is key here. We design our systems so that they are testable (especially the core pieces, which contain the business logic). Then we can create a suite of automatic test runs whenever any of our developers introduces even the slightest change in the code. The process of ensuring that the new changes integrate well and don’t break other parts of the system is called Continuous Integration. That being the case, the tests check all system components several times a day to ensure that everything is running smoothly.

Of course, when the test suite for a change fails, this change’s deployment is canceled. You may think about it as a club bouncer who will do his best not to allow any undesirable guests into the club. That will prevent most of the bugs going into production.

Nevertheless, sometimes bugs will happen (even in the production environment). But the Continuous Delivery approach also deals with it quite well. Continuous Deployment requires us to monitor the systems we develop. As a result, we have real-time insights into how the system is performing. We can quickly identify that something is happening without anyone even noticing that the quirky behavior they encountered is, indeed, a bug.

Please bear in mind that there is no such thing as a “flawless system”: every computer software (as a matter of fact, not only software) contains bugs, some are still hiding from our sight and will emerge in the future. It’s not a matter of “if” the bug will appear, but a matter of how fast we can respond. Since we are continuously deploying, we can apply a patch to the production immediately without waiting for the deployment window.

Continuous deployments reduce the size of the changes we introduce to the production environment: we deploy more often but in smaller chunks. Therefore, when a bug appears, we have much less code to analyze in order to resolve the issue. What is more, as monitoring is in place, the bugs are usually found in the recently deployed code pieces. It’s a great advantage since the developer responsible for the given change usually still has a mental map of the solution in their mind. Subsequently, they don’t need to remind themselves what was going on, thus reducing the time to resolve it.

One more thing to remember: not all bugs are equal. Some will only deny the user from doing something. From your perspective, they are an inconvenience rather than a severe threat to your business, not to mention the fact that they are usually easily spotted by the monitoring solutions and easily fixable. However, there are other kinds of errors: when the system allows the user to do something they shouldn’t be able to do. Sometimes, especially in the core parts of the system, it may even cause financial damage. Our job is to identify such places in the developed system, design them thoroughly and automatically test them before getting the code to production. Nonetheless, we are not able to accomplish this task without you. You know the way your business operates. And we need this knowledge. Thus, we have to cooperate: solving your problems side by side with you and developing a system that will fulfill your needs.

What are the benefits of Continuous Delivery?

The most crucial gain of using the Continuous Delivery approach is the agility, especially when the system goes live and starts earning real money for you. It allows the project team to react more flexibly to the business environment’s changes. If new circumstances or regulations that affect your operations arise, we may much faster identify the required changes in the system. Then, with confidence, step by step, we can adapt it to the new environment without any interruption. Do you remember the COVID-19 outbreak in early 2020? It forced many companies to adjust and start providing their services remotely in order to survive or quickly change the way they operate. Those who needed to wait for release cycles in their systems were probably in real trouble, seeing their customers move to their competitors who had adopted faster.

Moreover, the feature management tools have a “side effect”, which allows for enabling new features to the specific group of users. We can utilize this to perform so-called A/B tests. For instance, we can introduce a new, redesigned checkout process for a particular group of customers and then compare if we get better sales results than when using the old one. If it is not satisfactory — we can easily disable the new flow entirely and go back to the good old one.

Since we have monitoring in place and deploy new code to production quickly, we can react to undesirable behaviors. We can do it even if they are not yet affecting the system’s visible side. We can spot problems and eradicate them before they impact your business and make you file an issue report. As a result, you might be sure that the system is not left alone since we’re keeping an eye on it and taking care of any issues that arise. Remember, any interruption in the system is at least an inconvenience. In the worst case, it can turn into a loss of money for your business. And we will do our best to prevent it from happening or to make it as short as possible.

What are the costs of Continuous Delivery?

Unfortunately, not all systems are capable of embracing this development model. Old, legacy, probably monolithic systems need to be adjusted to reap the benefits out of the Continuous Delivery approach. It requires own investments. Thus, if your system is running well and you do not plan to develop it further in the foreseeable future it might not be feasible. Also, if the environment of your business is pretty stable — better stay with the classic model. There’s nothing wrong with it. Enjoy your working system and do what you are supposed to do — earn money.

Furthermore, all the automation and monitoring require additional infrastructure, which converts to other costs. Nowadays, it is becoming more and more popular to rent computing power from the cloud, where customers are billed by what they use. It is, in most cases, cheaper than setting up the required infrastructure on premises. However, this is an additional cost that needs to be included in the budget. The decision is up to you whether the value of implementing the Continuous Delivery model is worth the extra cost, compared to supporting your existing system as-is.

Summary

In this article, we’ve described what Continuous Delivery is. As you can see, it may bring some great benefits for the business – flexibility and continuous operation. However, they are not achievable without some extra cost. Furthermore, not all systems are well-suited to Continuous Delivery out of the box. It is entirely up to you whether you want to benefit from it in your business. We are right here if the answer is “yes”. We are waiting to deliver value to you. Continuously.