
Everything You Wanted to Know About DevOps and Continuous Delivery but Were Afraid To Ask
We all have heard the buzzwords being thrown around.
DevOps, Continuous Integration, Continuous Delivery, whatever you want to call it.
What is it? And why does it matter?
All great software has been created in teams whether open source or in an enterprise environment. Building software at scale comes with its inherent challenges and the larger the team the bigger these challenges become.
Recently in the enterprise software development culture there has been an emphasis on DevOps but it is not always so clear what this defines.
This article aims to provide the purpose of DevOps culture and the reasons why enterprises will benefit from cultivating an environment of continuous delivery.
The Good Ol’ Days

There is a natural friction between developers and system operators.
Development teams are measured on throughput, how many new features or bug fixes can a team complete in a given amount of time.
Whereas the operations team is measured on the stability and performance of the applications and underlying systems.
It’s easy to see how the priorities of the two teams can be conflicting. Developers are working hard to quickly release new features and fix bugs to allow the business to stay competitive. Sometimes even at this cost of code quality (also known as technical debt).
Whereas, system operators must maintain speed (performance) and uptime (application stability) which at times pushes back against software changes and new feature releases.
In this hypercompetitive market all businesses require change or risk becoming obsolete.
However, it is also evident that CHANGE is the root cause of most service outages.
Most service outages are the unforeseen effect of code changes that occurred a few minutes, hours, days or weeks ago.
So, what do you do?
You are pressed to develop quickly but code changes cause instability. Your business is left with two options.
- Discourage change in the interest of stability or
- Allow change to happen as often as it needs to ensure business SUCCESS
The ONLY answer is to allow the business to change as often as required to ensure business success and a continued competitive advantage.
But how do you achieve rapid successful change without compromising performance and application stability?
Enter Continuous Delivery !!!
The ability to get code changes — features, configuration changes, bug fixes, experiments — into production or into the hands of users safely and quickly in a sustainable way.” — Jez Humble
Continuous Delivery is a set of technical practices that harmonizes the actions of both the development and operations teams to optimize development throughput while maintaining application stability and performance.
But wait, I thought this wasn’t possible?
It’s not, unless you intentionally make an effort to implement a process which enables the two teams to work together as one cohesive unit.
What does continuous delivery look like?
Imagine we start with a developer working on an existing body of software. The developer works on a new feature which must be completed and then integrated back into the existing body of software. This is then released as a newer version of software and the cycle continues (this is why we will see software versions 1.0, 1.1, 1.2 etc).
But when the developer declares “I’m done” coding this new feature release, what does “done” really mean? How confident are we with this new software feature change? How do we know that it is working as it should and has not broken another piece of the software functionality?
In some organizations once the developer has finished coding a new feature which compiles and builds on his personal computer it is declared “done”. However, many of us know that code running on your machine does not necessarily mean the code change will run in a production environment.
The principle of continuous delivery would declare this scenario as an unfinished code change.
Continuous delivery requires you to prove systemically that this software change is working effectively as it should.
How do we know the code change is working effectively as it should before releasing it to production?
We subject this software change to tests that become progressively more difficult. At first the tests are easy. Does the code compile? Does it build in a production environment?
This alone is enough to fail most new code changes. It is important to catch these early and often as this prevents the loss of time and effort in later stages of testing which may require manual human intervention.
If the code passes the initial tests, the code is subject to even more tests that become progressively harder. Moving onto lower level unit tests, then to higher level integration and functional tests, followed by performance test.
These series of test are more formally defined as a code deployment pipeline and is relative to the size of the project.
Smaller projects may only require a few tests for the team to be confident that their code change is good and green. Larger organizations with multiple microservices require more comprehensive tests to ensure nothing has broken as cause of this change and everything is functioning appropriately.
As you get through the code deployment pipeline your test should begin to mimic (or closely replicate) the production environment. Ideally your last test should be as close or identical to your production environment as possible.
These series of tests are performed until we are thoroughly confident that this change is good and we are able to deploy into production with confidence.
If developers are still finding they are nervous about deploying code changes this indicates that the test suite is not comprehensive enough and should be revisited.
Continuous Integration Vs. Continuous Delivery
The timing of when you choose to deploy your new feature or code change will ultimately have an impact on the traffic and load on your application.
Therefore, as a business, you have the option between continuous delivery and continuous deployment.
Continuous Delivery — Every change the developer makes to the production environment can be deployed but does not have to be deployed until the business is ready.
Continues Deployment — Every change the developer makes gets deployed into production.
There is a tiny distinction between the two concepts but an important one to make.
The deployment of new features should be a business decision (we can deploy when we want to) as opposed to a technical decision (we deploy when we are ready).
This provides the business unit of your organization with figurative levers to pull when they are ready to release new features into production.
Why does this all matter?
Why put in the effort to achieve continuous deployment?
Achieving continuous deployment requires a great deal of effort and time. However, the effort put forth is greatly rewarded due to the below reasons.
Are we building the right thing?
The most compelling reason for continuous deployment is the immediate user feedback.
“Far more then 50% of functionality in software is rarely or never used. These aren’t just marginally valued features, many are no-value features.” — Jim Highsmith
Way too much developer time is spent building features that users don’t care about.
However, getting appropriate user feedback is hard. Humans are irrational and surveys are tricky. Your users will never truly know what they want until you put a feature out into production and in their hands. Only then will users tell you (or their behavior will indicate) what they do not want.
Through continuous deployment new code features are released in small chunks to the user as soon as they are ready. This provides immediate feedback whether the user is interested or not.
For developers this means more time spent on innovation and features that really matter to their users.
For businesses this means less time spent writing code that adds no value to the business or its customers.
Taking advantage of this quick iterative feedback loop will allow your technical team to achieve a heightened sense of focus on the customers’ needs which in turn results in adding features that your customers’ care about.
Lowers Deployment Risk

If you have hundreds of lines of code that need to go into production (a monster merge!) the potential risks and harmful effects it can have on your code base is also large and unpredictable.
If instead you could shrink your code deployments into smaller chunks, the risk also become smaller.
Smaller code changes become much easier to reason, test and debug.
This may sound counter intuitive but you have to remember that these smaller code changes are subject to a series of tests before deployment. By the time you deploy what would be a “full feature” in smaller code commits it has been tested numerous times incrementally as opposed to being tested and merged as a large-scale code base.
This is analogous to testing every piece of a bridge, the concrete, bolts, screws along the way to ensure they are able to withstand the required stress levels as opposed to ONLY testing the bridge once it has been completed.
The idea of multiple commits to the main software trunk is definitely scary at first. The integration problems seem daunting and at the beginning it will be. But as you continue to perform this routine of deployment more frequently, your integration process is forced to become smoother and eventually you don’t even notice it.
Sense of Real Progress
Earlier in this article I alluded to the definition of “Done”. What does “Done” mean for your organization or developer?
Is it the developer saying “Hey, I am done with this. It runs on my machine”, as opposed to “Hey, its deployed live in production”.
The latter is what truly defines complete production ready code and what every software development team should strive towards.
This also provides management with an honest estimation of progress and completion timeline. If each code change is a live deployment, management can be that much more confident that you are on the right track towards meeting your deadlines.
Say no more …
The reasons outlined above justify the effort required in cultivating a DevOps culture and a development environment which prioritizes continuous delivery.
In the follow up article I will discuss the best practices to continuous delivery and provide an example of how to create such an environment.
If you found this article helpful please like and share it so others may also benefit.
I would love to hear your opinion on DevOps and continuous delivery. What were your challenges and how did you overcome them?
