homeblogcontinuous delivery integration deployment guide c suite

Continuous delivery, integration & deployment: a guide for the C-suite

How often are you exactly right? I mean, 100% perfect? It’s not often. When delivering new software and services to customers (internal or external), you’ve made a bet that what you’re providing is what the customer truly needs. The problem with traditional delivery is that you might be wrong, and by quite a bit.

What if instead of optimizing for shipping the perfect thing when it’s ready, you optimized for feedback from your customer base? The goal of shipping now becomes learning, rather than checking off boxes on a requirement sheet. This is where the change from traditional software delivery (often called Waterfall) to practices like continuous delivery and continuous deployment take hold.

You’ve probably been hearing about continuous delivery and continuous deployment for a while now. What do they have to offer you, as an IT leader? This isn’t another round of programming language debates, editor wars, or tabs versus spaces. This is embracing new processes, tools and objectives to further enable the business. As a side benefit, your IT staff will align more closely with the business, and who doesn’t want that?

Let’s dig in a little bit on continuous delivery (CD). We’ll come back to continuous deployment in a bit. Continuous delivery is about always having software in a shippable state. Since software is now how business processes are modeled and structured, it’s really about having your business in a state where it can accept modifications and improvements to its processes and operating assumptions. If you can’t make a change in software because it either takes weeks of validation, the code is too monolithic, or you have very strict change cycles, you’re going to lag behind businesses who can.

Businesses regularly struggle in the validation cycle, often referred to as integration. Changes to software — which can be anything from adding a large amount of new functionality to a bespoke application, or making a minor configuration change to some commercial off-the-shelf software (COTS) — must be validated. Validation can happen automatically by using continuous integration (CI) software. If every change is validated, we know the software is good. If we know it’s good, the decision to send that change to production, or to customers, becomes a business enablement decision rather than a technical constraint.

Some businesses choose to deploy every change, as soon as it’s made its way through the CI system. This is known as continuous deployment. As an example, companies like Amazon, GitHub, and Salesforce deploy many times per day. The changes are often small, so you may not even realize anything has changed since the last time you used their software. However, when you look at today’s experience with something like Amazon and compare it with the site from two years ago, you’ll see quite a bit has changed.

Let’s get back to learning. Feedback is the next important part of continuous delivery. When you make small changes to business processes, you want to know if the tweak you just rolled out improves the situation, or makes it worse. The same is true for software. Sometimes, you can instrument software to tell you how things are going. It’s very common for web applications to tell the authors what areas of the page are clicked on most, how much time users are spending on a page, and other traffic statistics. On a manufacturing application, you may look at idle time on the machines, or for a lower defect rate. In some business process modeling, the easiest feedback mechanism could be to simply have a discussion with the consumers of that process, and talk about what’s better or worse than how it was before.

Armed with this type of information, you can make orders of magnitude more changes, and learn from them, rather than shipping or rolling out a new process like a big bang — which is likely missing critical elements.

In summary, continuous delivery is about small changes, automated testing and quick feedback. A nice benefit to implementing CD is that any one of those things in isolation improves the value of your IT services to the customer, so incremental improvement exists on your journey toward continuous delivery. CD enables the business to make adjustments more quickly, and ultimately deliver more value to your customers.

Michael Stahnke is director of engineering at Puppet.

Learn more

Puppet sites use proprietary and third-party cookies. By using our sites, you agree to our cookie policy.