Continuous Delivery Tools & Models Aren't Magical

The history of software development is full of excellent ideas that have turned into meaningless slogans and rituals to some. The problem isn't that the ideas are flawed, but that people try to treat them as magic formulas. "If we just use this methodology," they think, "it will get rid of all our problems."

Continuous delivery, continuous delivery tools (and methods), collectively are just the newest bright idea to receive this treatment. When developers or agencies offer continuous delivery tools or models as a magic bullets, clients still see problems. Clients aren't impressed.

We can't treat methodologies as dogma.

The cycle of methodologies and skepticism may have begun in the seventies, with "structured programming." Its ideas are mostly elementary common sense today: Organize code in blocks, get rid of the GO TO, avoid side effects, break code up into function calls. Some purists of structured programming, though, insisted code must never have side effects. This made some things very awkward to do. Some people concluded from this that structured programming was a bad idea. Today, we simply do structured programming, sensibly understood, and can hardly imagine coding a different way.

We've seen the same with "extreme programming," "pair programming," "agile development," and other ideas. When the idea becomes a dogma, it starts to get in the way of the benefits which it claims to promote. People start using it because they're supposed to, without understanding how to get positive results out of it.

Kief Morris makes some excellent points about how people misunderstand continuous delivery. This is his key point:

"A common misunderstanding is that Continuous Delivery means releasing into production very frequently. This confusion is made worse by the use of organizations that release software multiple times every day as poster children for CD. Continuous Delivery doesn’t require frequent releases, it only requires ensuring software could be released with very little effort at any point during development."

What is Continuous Delivery, really?

CD is an outgrowth of test-driven development. It rests on a simple but revolutionary idea: Code should always work. Bugs should get caught and fixed immediately. Test-driven development applies this idea at the unit level. Continuous delivery expands it to the entire product. The code should always build into a working product.

We have to pay close attention to the differences among three related concepts:

Continuous integration is the verification of every change as it's committed to the code repository. A developer can commit code only if it passes all tests. Continuous integration is opposed to using branches save local, ephemeral ones.

Continuous delivery is the use of continuous integration to have a build at all times that incorporates the latest code changes. The developers can send it at any time to a production environment. They deploy the build somewhere, but not necessarily to a production environment. Usually, it will be a test or QA system until a release is appropriate.

Continuous deployment extends continuous delivery to production servers. The deployment process is fully automated. As soon as a build passes all tests, it goes to the production environment.

Those are the usual meanings of the terms. You'll often find them stretched or interchanged for the sake of using buzzwords. Actually, none of them are "continuous" in the strict sense. It takes some time to write even the simplest piece of code. The terms, unfortunately, suggest that shortening that time is always good.

Doing Continous Delivery right—and wrong.

The more complex a product is, the more difficult it is to apply continuous delivery. If teams in different locations are working on the same product, always trying to shorten delivery cycles can lead to chaos. Continuous delivery works best with products that are small and simple, and the best way to make it work with a complex product is to break it down into independent components that can be separately deployed without breaking one another.

Promoting decomposition into separate components such as microservices can be a benefit of the continuous delivery approach. If management just insists on continuous delivery as an end in itself, though, it not only loses a chance to benefit but imposes a methodology in a situation where its chances are poor.

What to avoid:

This doesn't mean that every cycle should yield a product that's ready for the client, though. Continuous delivery says that the latest changes should always work, not that they can or should always be polished. Frequent changes that offer little benefit will only confuse the client.

Continuous Delivery tools aren't a means or an end.

In some places, continuous delivery tools is all there is. This misses the point. CD is an organizational process, not just a set of development tools. If a team is poorly coordinated, it can have the latest and best tools and still fail at software management. A successful CD project requires organizing it so that the process will work, and encouraging developers to develop the necessary rhythm of coding, testing, and updating.

Continuous delivery tools are helpful and recent developments have made these increasingly powerful. Developers everywhere rely on these to help them review code, automate deployment, manage projects, test, etc. And although continuous delivery and DevOps are two different concepts, there are similarities in their meanings and both are often related and interrelated. The rise of DevOps has accelerated the creation of advanced tools which in turn aid developers in their execution of continuous delivery.

There are plenty of continuous delivery tools lists; some tools lists for DevOps and others are tools compared. But tools aren't means; these facilitate and connect. Experienced continuous delivery talent is the means. And without this, and without the right approach, CD will be done wrong and expensively.

Done badly, continuous delivery results in unstable products. Developers have to rush changes through and make them available before they're ready. Customers get half-finished or buggy software. Changes show up without explanation.

What to embrace:

Done well, continuous delivery avoids the serious disruptions that can result from massive changes. Used well, continuous delivery tools and methods will change the industry. Developers will waste less and less work in dead-end efforts. They don't often find themselves colliding with incompatible changes by other developers.

The benefits show up when developers understand the purpose of continuous delivery. CD fails when it becomes just a way to push code out the door.

Do Continous Delivery differently. Don't be dogmatic.

Any methodology should be a means, not a goal. The goal is delivering reliable software that meets the client's expectations, on schedule. Treating continuous delivery as its own reason for existing is the biggest reason for failures using it.