What’s Continuous Deployment?

Thousands of years ago, back before people lived in houses and when dinosaurs still ruled the earth, software development took a long time. First, you did the design (figuring out what you want to do and how you’re going to do it). Then you wrote the code. Then you did testing (the stage of the project where people pretend to look over what you created but really don’t pay attention). This lead to changes, sometimes drastic changes, in what you did. Finally, you moved everything to production and went live (also known as final testing because now people are forced to pay attention).

Then Agile came along. And Scrum. And Lean. And the idea that maybe it would be better if the whole cycle (design, coding, and testing) was compressed so that, rather than taking months to get something into the users’ hands, it would take maybe just weeks.

The final move in that direction (so far) was broadly labeled Extreme Programming, where all coding had to either be done at high altitudes or else on a skate board. As part of that, we added the deployment phase to the quick turn around cycle. And this is where Continuous Deployment fits in. Essentially the idea behind Continuous Deployment is that functionality is moved to production as soon as it’s coded and tested so it can be used (that is, really tested).

The Various Continuous Options

If you think your life is complex enough, then you might want to pretend that this particular section doesn’t exist. There are a number of similar and yet different terms (especially if you talk to the experts) that describe all of this. Break out the Dramamine and hang on.

If you Google “Continuous Deployment” you will see many references to Continuous Integration and Continuous Delivery. They sound the same but, if you listen to the experts, they’re really very different (which means that they’re really pretty much the same).

Continuous Integration really refers to the front-end of the process; the building, integrating, and testing of code within a development environment.

Continuous Deployment is described as something where every change that goes through the deployment pipeline is automatically loaded into production.

Continuous Delivery, on the other hand, is where everything goes through the pipeline but you choose when that happens, rather than all the time as with Continuous Deployment.

Advantages of Continuous Deployment

The first advantage of Continuous Deployment is that its continuation of Agile’s focus on small scale tasks as a unit helps to reduce the complexity of the deployment effort. That is, it’s easier to move one module and two files than 50 modules and 100 files, and that hopefully leads to fewer deployment mishaps.

The second advantage is that it makes it less likely that you and someone else on your team will get your tasks tangled up. This is particularly true if you are in a large organization with many developers but you are not in a situation where a given developer has complete and sole control of a given application. The shorter the time that a module is checked out and is worked on before it’s pushed out to production, the less likely that two developers will check out and separately update the same module.

Disadvantages of Continuous Deployment?

As we well know, every rose has it’s thorns, right? So there must be some disadvantages to Continuous deployment as well.

To the uninitiated (this includes every manager I have ever worked for), Continuous Deployment is code for “poor quality code thrown out there to let the user swim for his life”. But the truth is, Continuous Deployment means just the opposite. The basic assumption is that the code that you do deploy quickly will be clean. To do that, a focused and disciplined approach is required. Continuous Deployment is not for hackers or the insincere.

Another thing that some people say is that while it might be a nice thought, Continuous Deployment is just too complex to do. And there is some truth to that; there has to be some complexity involved if you’re moving new code to production multiple times per day automatically and without mishap. But I don’t see anybody complaining about the complexity of the new BMW when the engine cuts out when it’s stopped at a red-light and then comes back on again automatically, so we should all be able to agree that complexity is okay as long as it works and leads to a good outcome.

Getting Started with Continuous Deployment

So what do you need to do Continuous Deployment? Other than the simple faith of a child, that is. Unfortunately, Continuous Deployment is not just an idea that you can casually implement. You need some solid procedures and software behind it.

First, you need an integration environment. This is a server that replicates the production environment, giving you something that you can test in and with.

Second, you need a full set of test scripts (this is the sticking point with many people). We code up a new script, run them through a couple of obvious things, and then we’re ready to go. Who keeps track of tests? But that’s too dangerous when talking about Continuous Deployment. You need to have a complete set of test scripts designed to find any and all errors. If you don’t have this, don’t even bother.

Third, you need a piece of software generally referred to as “build software” that automates the process of putting the new code in with the existing code, running through the test scripts, notifying you of any problems, and then, if all goes well, pushing the new code into your production and test environments. Examples of this include Cruise Control, Jenkins, BuildBot, Bamboo, etc.

Conclusion

I don’t want anyone to be fooled. Continuous anything is not simple to implement. It requires a real commitment. It requires exhaustive test scripts. It requires sophisticated software to make it automatic (and thus practical). But for people in a multi-developer environment, one where responsiveness to user demands is important, where speed and reliability of changes is important – Continuous Deployment just might become your new best friend.

Image via Fotolia

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://www.sylvainlevesque.com Sylvain Lévesque

    Thanks Mr. Shirey for this great and well written article. It gives me a push in the back to try someting like “Continous Deployment” this automn. Thanks !

    • Dave Shirey

      Thanks for the kind words about my article. Having so inspired you I am now ever glad I write about CD rather than excessive drinking or getting into using recreational drugs. Good luck.

  • Vincent Michel

    Thank you for this article !
    As a major disavantage, you would add: it raises project maintenance costs as deployment phase is repeated more often. Costs for dev team (packaging and support), integration and exploitation team who have to execute the deployment procedure several time. This may not be a big deal for simple wordpress blogs, but when it deals with big internal business application involving night deployment, data indexing, and so, it is.

    Hoping to bring a another view about this :-)

    • Dave Shirey

      Excellent point and one that I wish I had included. Nothing is every just positive, everything has at least one negative to it and you need to be sure that the benefits of faster deployment of new functions and a reduced chance of different developers getting tangled up with each other offsets the added cost.

  • http://www.solanolabs.com Leo Cheng

    Hi Dave,
    Great write-up on continuous deployment and the difference between continuous integration/delivery/deployment. At Solano Labs, we also see the lack of test scripts being one of the main hurdles in getting to continuous deployment. Some devs still don’t believe in writing tests, but that kind of thinking seems to be phasing out quickly (or at least jobs for those people are). Will definitely pass this post around!

    Cheers,
    Leo

    • David Shirey

      Absolutely! Getting good test scripts is the toughest part of any good design and the one that is most often neglected. I think we sometimes convince ourselves that testing is a user function and we expect our users to give us any test script parameters. But it is definitely something that is the responsibility of the designer.

  • Ramesh Baral

    Thanks a lot Mr David Shirey for the interesting and well organized article on Continuous Deployment.
    We expect more details on this from you soon.
    Thanks.

    • David Shirey

      Glad you enjoyed the article.