The Difference Between Continuous Integration, Deployment and Delivery

Do you remember in high school it seemed like all the cool kids seemed to be speaking in their own code? Well, it’s a bit like that in DevOps circles today.

Everybody’s talking about Continuous Integration (CI) this, Continuous Deployment (CD) that. And who knows, you might even hear some people mentioning Continous Delivery (CDel).

However, how do you know they’re ‘walking the walk’, when it comes to doing DevOps, and not just ‘talking the talk’?

No Continuous Integration, No Deal

I was once at a Dev Ops summit, and I remember hearing a conversation between two engineers. One of them was boasting that due to CI being hooked into his organization’s software development system, his engineering team was able to detect, locate and fix software and security bugs every time they merged code into their master branch.

The other looked amazed. He commented that it took his team ages to find and fix issues, as his engineering team only ran builds and tests at the end of each development phase. And then he asked, “So, how often are you merging to the master branch then?”, to which the other guy replied “It depends. Seeing as we trigger builds and tests manually, sometimes we merge more often than others.” This is a prime example of someone talking the talk.

It’s true CI is all about frequently merging code into the master branch, but without automating builds and tests, it’s simply not possible to find and fix issues at the rate needed to claim you’re doing CI.

If you have CI successfully implemented, your engineering team will be able to merge code to the master branch up to a few times a day. Furthermore, due to the automated processes in place, you can rest assured that you’re left with a dependable codebase which is ready to progress through the SDLC. Subsequently, without doing CI properly, it’s impossible to do be doing DevOps.

Continuous Deployment. It’s the Talk of the Town

You’re at a dinner party, and talk turns to agile software development, as it naturally does. If someone asks you “As part of CD, do you batch large amounts of code into Staging before deployment?” Beware! It’s a trap.

CD is all about automatically deploying code into production, after it passes the automated build and tests you have plugged in as part of CI. This means no large-scale batching in Staging.

Additionally, to successfully release code, it must not only be dependable, but have all its configurations locked and loaded, so it’s ready for the end user. Therefore, if you’re doing CD properly, there’s a very good chance you’re on your way to DevOps success.

However, with all this talk of ‘continuous’ this and ‘automated’ that, what is the actual difference between CI and CD?

What’s the Difference between Continuous Integration and Continuous Deployment Anyways?

You probably won’t be surprised that the two are closely linked, however there is a difference between CI and CD. And the difference lies in the detail.

Think of CI and CD in terms of a car assembly line. CI is concerned with checking to see if all the car’s parts are of high quality, if they’re installed correctly, if they function effectively etc. Once all the tests have been made, it’s time to see if the machine as a whole is ready to be passed to the consumer. This is the role of CD.

If you’ve got CI and CD successfully implemented, the transition between the two should be seamless. In fact, it should be so simple that anybody can trigger the process at the push of a button.

Now we’ve got the understanding of CI and CD under our belts, let’s talk about Continuous Delivery (CDel).

Wait a Sec. Aren’t Continuous Delivery and Deployment the Same Thing?

From conversations I’ve had with many engineers across many verticals who like to flaunt their DevOps, many think that CD and CDel mean the same thing. Well, you might be interested to learn they don’t. And the difference between CD and CDel lies in choice.

With CD, code is automatically deployed after each successful master branch merge, while with CDel your organization can choose whether it’s released to the customer.

Teams usually choose to stick with CDel, and not progress to CD, for business reasons. For example, teams may not want to release a feature into production after every successful merge because, to put it simply, it’s still in development, and so only half-baked.

Put it this way. You’re building a cellphone. The reception’s great. The audio’s perfect. Yet the camera, although functioning, is slightly below optimal res. Do you think it’s ready for the consumer?

So, now we get on to the big question. Why should you care about adopting CI, CD and CDel anyways?

If You’re Not Hooking Continuous Integration, Delivery/Deployment Into Your SDLC, Maybe You Should….

As code is tested and deployed continuously, you can detect software and security bugs earlier in the software development process. Therefore, by shifting left testing to the earliest stages of your SDLC, issues are easier and cheaper to find and fix, as you don’t have to dig through mountains of code to do so.

Furthermore, software development is not just about developers. For example, security has an essential role to play as well. Therefore, by adopting the agile software practices we have already mentioned, you can increase code visibility not only within engineering, but also between other departments as well. Security can see the results of the automated tests, and feedback to engineering if there any security issues to be tackled or coding practices to be improved.

Finally, hooking CI and CDel/CD into your SDLC not only benefits communication between your engineers and other departments, but managers as well. As code is released more frequently, management has a greater volume of code to analyze, so they can see if product development is on the right track.

Want to Do DevOps?

Now the ins-and-outs of CI, CD and CDel have been laid out for all to see. Next time you hear someone talking about ‘doing DevOps’, you’ll be able to sniff out an imposter a mile off.

And who knows. If you haven’t already integrated some of the agile practices discussed above into your SDLC, maybe you just might think about giving some a try.