At VoxGen we have been using some form of Continuous Integration (CI) for a long time. CI, at its minimum, is the process whereby every time a developer commits a code change to the source code repository then that code is merged with the rest of the project and the project is built and tested to see if anything breaks. This aims to prevent integration problems later on in the project by integrating early and often. By adding Unit Tests we can also ensure that new code is doing what we expect it to do and that existing functionality has not been changed. All of this occurs on a central server guaranteeing that a common and repeatable build process is developed and removes the old problem of "it works on my machine". The build process can be grown to check for code quality, style, test coverage, complexity and even common mistakes and vulnerabilities. And all of this happens every time that a developer checks something in. If everything works as expected then life continues as normal. If, however, something breaks then everyone in the project immediately gets alerted to the fact and can work together to fix it.
Continuous Delivery (CD) builds on the idea of CI, adding a deployment pipeline process that can, in theory, take each and every code change through to deployment to end users. The pipeline can have many steps (the first of which is CI) through which the software must pass, being validated as it does so. Typical steps include load testing, performance testing, automated acceptance testing, quality assurance, user acceptance testing and deployment. Not all of the steps have to be automatic, for example the quality assurance step may involve a whole raft of manual testing by the QA team, but the pipeline still exists and the software cannot progress until the QA is passed.
So, here at VoxGen HQ we have been encouraging the implementation of CD, and the teams have been successfully using Jenkins to deploy systems to our development and testing environments. The plan is to keep on adding automation steps to the pipeline and eventually reach the point where we would be happy to use it for deployment to Live. On February 6th, several members of the development and operations teams attended a one-day event on Jenkins to hear about the latest improvements to the product and listen to some real life stories of Jenkins in action. Interestingly, one of our customers' lead architects was speaking on his experiences of using Jenkins to build and deploy a variety of legacy and new applications supporting their CRM and billing systems. The same CRM and billing systems that the VoxGen IVRs and multichannel applications integrate to. It's a small world.
Buoyed up with the latest knowledge and best practices I expect to see increased use of build, test and deployment automation across all our projects over the coming months. I am not sure that we will reach the point where every code change is automatically released to Live in the near future, but I believe that we can achieve greater efficiency in our deployments, giving ourselves and our customers the confidence to continue to innovate.