The Road to Continuous Delivery–Part 1

June 6, 2014 by Rene van Osnabrugge Comments Off on The Road to Continuous Delivery–Part 1

Introduction

Continuous Delivery. You hear and read a lot about it lately and it seems to be or become a trend. What I see in the field is that companies think about Continuous Delivery but are not completely sure what it actually means. Let alone that they can oversee the impact of a Continuous Delivery implementation.

Last April I presented a session on the Dutch TechDays about Continuous Delivery (you can find the session on Channel 9(in Dutch) and on SlideShare). There I spoke about Continuous Delivery as a concept and about the feature set of Team Foundation Server with this concept in mind. Because with the introduction of Visual Studio Release Management Microsoft broadened the toolset of Team Foundation Server even more. This makes Team Foundation Server a very rich toolset which is fully capable of supporting Continuous Delivery within your organization.

But beware, Continuous Delivery is more than Release Management only. It is a sophisticated process that goes further than implementing a tool alone. Think about agile processes, automated builds, Continuous Integration, Code quality and test automation.

In this blog post I will talk about Continuous Delivery as a concept and what Team Foundation Server can do for you.

Backgrounds

Before I start explaining what Continuous Delivery is, I want you to give a little background information to understand why we want something like this. There are many reasons that I can think of, but all leads back to one common denominator. Eliminate Work Disturbance.

Let me explain this by some simple examples.

Customer Demand

Customer demand is a good thing. It means you have the right product and customers cannot wait to use it. But customer demand can be very disturbing as well. Especially if the customers wants your product or feature really badly. They start to call you, report bugs that are actually features or in the worst case leave you for your competitor. And when you think of it, can you blame them? They lose money. A feature loses its value over time (Agile Software Requirements [Dean Leffingwell]) and nobody like to wait. When you order a new television, you do not want to wait 4 months before you can watch TV.

“The Release”

In most companies where I have been, the release is dark cloud hanging above the IT-department. Many things go wrong. Most of the times it is manual labor and many people are involved. Traditionally Development and IT-Operations are the ones involved with a release and traditionally they do not communicate very well. Handovers, installation guides, step-by-step configuration manuals and people who do not read this.

The result is usually a faulty release and to do it better next time even more documents are required. The release becomes harder and harder and causes a lot of disturbance.

The “Business”

I often call them the monster of Loch Ness, because everybody talks about them but nobody actually knows them. The business is often used as an excuse for things going wrong or things being late. “The business wanted this”, “The business asked for this”, “The business changed its mind again”.

But why does “The Business“ causes these disturbances. Why do they keep adding new features and why do they keep pushing the developers. Especially in large organisations, where the business side is often separated from the developer side we see these things happen. And the underlying reason is simple.

Continuous Delivery to the rescue

The reason for many disturbances can be related to what I call “Waiting Time”. Time that people usually do not want. Customers do not want to wait for a feature because it costs them money. So they start complaining. The release becomes harder and harder as it becomes larger. The longer you wait with a release, the harder it gets. And the business does not WANT to disturb, they just do not want to wait. The market changes and the longer they have to wait for a feature the bigger the change is they want another feature instead.

So, what can we do to reduce waiting time. What if we could deliver our software with a single button push? Would all problems vanish? No, but many things would be a lot easier. And this is what Continuous Delivery is all about.

Deliver fast enough so that a customer does not have time to change his mind.

To be a little more specific we can look at some definitions of Continuous Delivery. Techopedia describes Continuous Delivery as follows.

And Martin Fowler sums this up as:

Your software is deployable throughout its lifecycle
Your team prioritizes keeping the software deployable over working on new features
Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them
You can perform push-button deployments of any version of the software to any environment on demand

As you can see Continuous Delivery is a whole set of processes, tools and techniques that impacts many parts of your organization. To be deployable throughout the lifecycle, software needs to be architected this way. Installations need to be scripted. Environments need to be created automatically. Feedback mechanisms must be in place. Rollback scenarios must be created and scripted. A whole lot of work as you can imagine.

In the next part I will dive into the Deployment Pipeline and Various stages and I will talk about what role Team Foundation Server can play in this context.