Recently we have been taking much more interest in Continuous Delivery. Working on early stage start up projects continuous delivery is pretty much assumed. You put code up the server all the time and don’t really think about it. Getting new features and early SEO traffic is more important than stability.If you don’t have a lot of traffic you can live with the downtime for a release and even be prepared to release a bug you didn’t find in testing. In these environments I often find releasing code up to live can happen at least once a day.

Not having much traffic at the start makes this risk pretty low. However you can’t really carry on like this forever. As soon as you have even a steady stream of traffic to your site you will want to have much higher up time and lower risk of releasing bugs. This is when Continuous Delivery becomes more of a challenge. I have recently read “Continuous Delivery” by David Farley and Jez Humble (http://amzn.to/qSrrgo).
This is a detailed book with many different topics but the key ones I think are most pertinent for small businesses are automated testing and continuous integration. Most projects now use Source Control but Continuous Integration is still not adopted widely enough.

Automated testing is, on the face of it, expensive for a business owner to sign off. But they really do stop the releasing of bugs being so easy and mean that you can  more confidently put code up to live faster. As we mainly work on web projects, acceptance tests for us are all about automating the browser. We can get our main features properly tested and then run automatic scripts against them. This allows our developers to run these when they make changes to certain areas of the site and for our them to be run all the time against our code base. As soon as one fails, all the developers must stop to find out what has gone wrong.

Automated testing is hard to do right but once you have the right techniques and infrastructure in place it does get a lot easier. I have also found it is making me design pages in a cleaner way, if a page is becoming hard to test then it is probably doing too much.

Continuous Integration is more the software development manager’s dream. I can get our developers all working together and then be instantly aware when one of them has made a breaking change. I get an email and my dashboard goes red. Again sponsors of projects don’t get all that excited about this sort of thing and it can be a hard sell but any informed project sponsor should insist on this being in place. If code that wont build is committed then I know, if a unit test fails (suggesting something is coded wrongly) then I know, if automation tests are failing (suggesting the site functionality is broken or changed) I know. I can also add other checks in such as code cleanliness and so forth. It means I don’t have to micro manage my developers and also they know they need to work in such a way to get work to live.

There are many other areas of continuous delivery of interest but I am not going to cover them all now. I can only leave you with a recommendation to read the book!