Deployment is a neglected topic. It sits on the project diagram as the line that separates development work from support work. It is rarely given any time in development and even less for the testing. Just as Continuous Integration stresses that if you can’t build your project, then you don’t have a project; if you can’t deploy your project then you don’t have anything.
This will be a set of articles discussing the topic of enterprise deployment; not the kind of thing that you do on your own website where you JustCopyTheBinaries. That might work for the first version where you don’t have any users but it won’t be any good when you have a mesh of consuming systems and users in 4 times zones. It just isn’t good enough to tell people who have systems that have just stopped working on quarter-end that “Oh yes, that was a breaking change”.
Often, in the enterprise, you don’t even get the luxury of a trivial v1.0 deployment. More often than not, you have to replace an existing system; but support its bugs for a while even though your new system is event-based and the old system runs as an overnight batch. You just have to make it work, real people doing real work are depending on these systems to actually make the money that pays for your servers. Shocking, I know.
And deployment is something that never stops. You can’t “finish” the project with a deployment. In the enterprise world there are always new features and new servers in new offices that need a deployment; if you don’t have the deployment under control then you will be wasting your time and your customer’s time; with downtime and debugging.
Maybe, downtime isn’t the problem for you; maybe you don’t have a lot of timezones so you have all night, every night to do what you want; but you do have a set of users who want new features every month. Maybe you work on a non-critical application like a social web site; you are on 24×7 but you can tolerate downtime but the website can’t be off for more than 10 minutes; you have to ship new features every day and you have a development team who demand that the new work goes live from source control to the production system. If you have to do that, you have to not only have a system that allows you to DeployFromSourceControl but you need an AutomatedDeployment.
So, this set of articles will deal with a vague set of problems from the actual “go live” moment to how to architect your applications so that they can smoothly take over from a predecessor system. The systems under consideration will range from databases to web services to client applets.
This set of articles was inspired by the Martin Fowler article on a type of deployment that he called the StranglerApplication. It seemed to me that there were many such good tricks that could do with codifying.
No More Hacks 