10,000 Foot Developer

The other day I got to meet up with a UI developer who works on the sphere of HTML, Javascript, and CSS.  I am working on a back end that I inherited from another consulting company; its a Java stack and requires a deployment for changes.   The UI guy looked at me and asked about the large process we use to do a release, and he asked me a compelling question: “And you are OK with that?”  He is used to deploying UI changes at will from a CMS system.  It fits in the realm of “continuous deployment” which is the automated version of deploying-at-will.

Continuous Deployment (CD) is deploying new software changes as soon as they are ready to be deployed instead of waiting for a release date.

It’s a good question; and it also shows why doing software isn’t necessarily common sense because you have to dig to get the answer for this question.  I did a little reading and dug into my experience to think about scenarios as to why an organization could or even should (or not) do Continuous Deployment.  A lot of my development experience over the last 10 years is in health care, and this impacts my view on this subject quite a bit.  So here are my list of questions and why’s:

Definitions:

Critical systems: involve people’s actual lives, like health care notifications of conflicting pharmaceuticals, or power grid monitoring etc.

Non-critical systems: people are not as dependent and changes are not life threatening, i.e. a retail system.

1. Is the system a critical system? If it is, continuous deployment is probably not for you because the chance of deploying an error and rolling back (if you can catch it after 4 deployments) increases with the deployments.
2. Do you have time/resources to build and maintain the CD infrastructure? If not, doing continuous will be very time consuming.  You will want a repository, a CI build like Hudson up minimally to do this AND there are other methods like pre-check in code holder scripts etc.  This takes time and commitment and possibly another person to maintain it.  You might even need a cluster of machine instances virtual or otherwise) for the next consideration:
3. Do you have a bank of automated QA tests? If not, if NOT, then you will probably generate and propagate a ton of bugs.  You need to test test test.  It is a requirement to do CD, not an option.
4. What technology or separation of concerns do you want to/can continuously deploy? If its the base underlying framework, you might be in dangerous territory because one small change will cascade up to remote areas of the application — for instance another piece of the UI you did NOT work on could break.  Again, test.  Isolated UI pieces or isolated systems might be an easier place to do CD. — and that might be all the business needs for CD.  Another consideration is if you have a system with lots of dependents; i.e. if you are a rest services piece with 5 applications dependent on your service.  All these apps have to coordinate with your changes and that is absolutely not an easy thing to manage.
5. Do you have a database/content object version system? You need to be able to roll domain changes back quickly, synced up with your code versions.
6. Will training be required for the new versions? If so, then C.D. would be a bad route to go.  Imagine, having to learn a new piece of a system constantly as a nurse, or even as a book keeper at a retail store.  A system I recently worked on would deploy to many clinics and was used in exam rooms — tons of doctors and nurses.  CD was far too risky for this situation.
7. Does you have a good  feature review process? If you don’t, its possible that business “prototype” code will get deployed and damage the real mission of the application.  You still need human eyes on the requirements and the ability to review the effects of change before deployment.
8. Deployment dependencies large? If you have slow-pinging servers, or WAR deployments (vs. PHP changes which can be fast), tons of data services; well then your down time might be too big to start or you have to drop in a load balanced system to accomodate the time it takes to deploy and automate that.
9. Can you even automate the process? If you do not have even a good way to drop CI in, maybe its time anyway to evaluate your system for new techniques.

The idea of CD is compelling. And I hope these questions shed some light on the larger implications and considerations of trying to achieve this kind of level of deployment.  But, especially die to the training/critical issue, CD is not for everything.