What do you get with Print?

Instant access to your digital copy whilst your Print order is Shipped

Paperback book shipped to your preferred address

Redeem a companion digital copy on all Print orders

Access this title in our online reader with advanced features

DRM FREE - Read whenever, wherever and however you want

The Evolution of Software Delivery

As described in the preface, Continuous Delivery (CD) and DevOps are complementary ways of working. The former gives anyone who delivers customer value via software the ability to do so rapidly, consistently, and—as the name implies—continuously. The latter helps harmonize the teams that deliver and support said software. Both approaches can help you to optimize, streamline, and improve the way you work, and ultimately how you deliver value by shipping quality software.

It should be pointed out that the true meaning of these approaches have been blurred over the past decade—be that by tech press misunderstanding or recruitment businesses wanting to add 10% on salary rates, or software vendors and consultancies wanting to make their fortune by jumping on the bandwagon.

I have summarized what CD and DevOps are, but before we proceed, it may help if I highlight what they are not:

Continuous delivery and continuous deployment are not the same—the former focuses on business value and the latter is the mechanism of shipping software
A DevOps engineer is not a magical wizard. Software engineers and DevOps engineers are basically the same—the former creates text files that are used to create software assets and the latter creates text files that create environments and configuration to run said software
DevOps does not replace traditional system operations activities and approaches—it extends, complements, and enhances them
DevOps does not remove the need for ensuring your software, and the environments in which they run are highly secure—although this can ease the adoption and implementation of SecOps
CD and DevOps are not the silver bullet to remove all of your process and business issues, although they can help reduce the overall number

One thing you need to take into account is that almost all successful software businesses go through a number of phases of evolution. They normally start life as a small highly-focused team with good ideas, plenty of ambition, and some investment. As they build their market share, reach, and revenue, a period of rapid growth normally follows both in terms of workforce and spend. As the business matures and becomes established, they transition to the next phase of either continued and substantial growth to keep ahead of the competition, or make themselves a target for acquisition—this usually depends on how quickly investors want to see a return.

It's also inevitable that as a business goes through this evolution, the day-to-day business processes will become more complex, which in turn leads to complexity and pain in terms of how software is delivered.

The adoption of CD and DevOps can assist in reducing this complexity and pain; however, the effectiveness and benefits a business can reap are very much dependent on where the business sits on the evolutionary scale. If you are off the mark, then adoption can be more trouble than it is worth, and you may end up making things worse for the overall business. Not only that, but business, are strange and unique creatures—especially those whose raison d'etre is delivering software solutions—and no two are the same; therefore, the adoption needs to be uniquely tailored to fit.

The topics we will cover in this chapter are as follows:

A more detailed explanation of the various phases of the evolution of software delivery
The positives and negatives of each phase
How you can ascertain which phase you are in
The advantages—some unforeseen—that can come from a CD and DevOps way of working

To make it a little easier to understand what all of this actually means, we'll now dig a little deeper into these phases by following the evolution of a typical software-based business, called ACME systems.

ACME systems – evolution phase 1.0

ACME started out with a couple of things in common with the many thousands of small software businesses scattered around the globe: it had some good ideas and a saw gap in the market that it could exploit to make its fortune. It had a relatively small amount of cash so it needed to move fast to be able to survive and it needed to quickly entice, enlist, and retain customers at all costs. It did this by delivering what the customer wants just before the customer needs it. Deliver too soon, and it may have wasted money on building solutions that the customer decides they no longer want. Deliver too late, and someone else may well have taken the company's market share—and the revenue—away. The keyword here is deliver.

As a small start-up, in the early days, the going is slow and the work is hard: lots of R&D, frantically-built pre-sales prototypes, quick and dirty deliveries, and unrealistic deadlines. After many long days, nights, weeks, months, and weekends, things actually start to come together. The customer base starts to grow and the orders—and revenue—start rolling in. After a while, the number of employees are in double figures and the founders have become directors.

So, what has this got to do with CD or DevOps? Well, everything really. The culture, default behaviors, and engineering practices of a small software house are what would be classed as pretty good in terms of CD and DevOps. For example:

There are next to no barriers between developers and the operations teams—in fact, they are generally one and the same
Developers have full access to the production environment and can closely monitor their software
All areas of the business are focused on the same thing, that being to get software into the production environment a quickly as possible, thus delighting customers
Speed of delivery is crucial
If things break, everyone swarms around to help fix the problem—even out of hours
The software evolves quickly and features are added in incremental chunks
The ways of working are normally very agile
Communication and collaboration across the business is efficient and, for the most part, effective

There is a reason for stating that the culture, default behaviors, and engineering practices of a small software house would be classed as pretty good rather than ideal. This is because there are many flaws in the way a small software business typically has to operate to stay alive:

Corners will be cut to hit deadlines, which compromises software design, quality, and elegance
Application security best practices are given short shrift or even ignored
Engineering best practices are compromised to hit deadlines
The concept of technical debt is pretty much ignored
Testing won't be in the forefront of the developer's mind (even if it were, there may not be enough time to work in a test-first way)
Source-and version-control systems are not used religiously
With unrestricted access to the production environment, ad hoc and uncontrolled tweaks and changes can be made to the infrastructure and environmental setup
Software releasing will be mainly manual and most of the time an afterthought of the overall system design
At times, a rough and ready prototype may become production code without the opportunity for refactoring
Documentation is scant or non-existent—any that does exist is probably out of date
The work-life balance for an engineer working within a small software house is not sustainable and burn out does happen

Let's have a look at the software-delivery process for ACME systems Version 1.0, which, to be honest, shouldn't take too long.

Software-delivery process flow Version 1.0

The following diagram gives an overview of the simple process used by ACME systems to deliver software. It's simple, elegant (in a rough-and-ready kind of way), and easy to communicate and understand:

Overview of ACME Version 1.0 software-delivery process

This very simple process is something that many small software businesses and start-ups will recognize. From a CD and DevOps perspective, there are next to no barriers between those building and delivering the software and those supporting it (we'll cover this later in this chapter).

Let's move forward a few years and see how ACME systems is doing, and gain some insight into the benefits and pitfalls of being the leader of the field.

Key benefits

Identify and overcome the issues that stifle the delivery of quality software

Learn how Continuous Delivery and DevOps work together with other agile tools

Real-world examples, tricks and tips that will help the successful adoption of CD & DevOps

Description

Over the past few years, Continuous Delivery (CD) and DevOps have been in the spotlight in tech media, at conferences, and in boardrooms alike. Many articles and books have been written covering the technical aspects of CD and DevOps, yet the vast majority of the industry doesn’t fully understand what they actually are and how, if adopted correctly they can help organizations drastically change the way they deliver value. This book will help you figure out how CD and DevOps can help you to optimize, streamline, and improve the way you work to consistently deliver quality software. In this edition, you’ll be introduced to modern tools, techniques, and examples to help you understand what the adoption of CD and DevOps entails. It provides clear and concise insights in to what CD and DevOps are all about, how to go about both preparing for and adopting them, and what quantifiable value they bring. You will be guided through the various stages of adoption, the impact they will have on your business and those working within it, how to overcome common problems, and what to do once CD and DevOps have become truly embedded. Included within this book are some real-world examples, tricks, and tips that will help ease the adoption process and allow you to fully utilize the power of CD and DevOps

Who is this book for?

Whether you are a software developer, a system administrator, an agile coach, a product manager, a project manager, a CTO, a VP, a CEO or anyone else involved in software delivery, you will have a common problem which is delivering quality software. This book has been written for anyone and everyone who wants to understand how to regularly deliver quality software to their customers without said pain.

What you will learn

Explore Continuous Delivery and DevOps in depth

Discover how CD and DevOps fits in with recent trends such as DataOps, SecOps, pipelines and CI

Understand the root causes of the pain points within your existing product delivery process

Understand the human elements of CD and DevOps and how intrinsic they are to your success

Avoid common traps, pitfalls and hurdles as you implement CD and DevOps

Monitor and communicate the relative success of DevOps and CD adoption

Extend and reuse CD and DevOps approaches

What do you get with Print?