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
David ShireyDave Shirey is owner of Shirey Consulting Services which provides business and technical project management, EDI set up and support, and various technical services for the mainframe, midrange, and desktop worlds. In addition to PHP Master, he also writes frequently for MC Press and Pro Developer (formerly System iNews). In his free time, he tends to worry vaguely about the future and wonder obsessively how different his life might have been if he had just finished working on that first novel when he got out of college.
