Benefits of Continuous Deployment
In Software Development Agility is Key to Success
Software-as-a-service (SaaS) providers have a delicate balancing act to follow. For subscription based services, clients expect not only value to be delivered in the here-and-now, but also expect increased value in the future. Market conditions can evolve rapidly, meaning the functionality delivered by an SaaS application today could soon look obsolete as competitors do their best to keep an edge.
To meet these challenges, SaaS providers have to continuously improve their products, releasing early and often. Most startups embrace some form of agile software development, where release-to-market cycles are on the order of weeks, rather than months. By focusing on small chunks of deliverable functionality, development teams can devote their scarce resources to meeting the highest priority goals of the business, adapting readily to shifts as they happen.
Here at Compendium, the Engineering team has long followed some form of agile development. We've used SCRUM to manage our planning and release, complete with a product owner, product backlog, planning meetings, sprints, and daily stand-up meetings. Our first sprints were planned in the summer of 2008, and stand-ups have been held continuously since then.
Why Continuous Delivery Became a Necessity for Us
Over time, it became increasingly evident that the weekly release cycle was reaching its useful limit. A typical schedule had the team committing to the week's deliverables on a Wednesday, with development taking place up through the end of Monday. Tuesdays were reserved for release candidate cuts, peer code reviews, and functional testing. Sometimes that testing lasted well in to the wee hours of early Wednesday morning. With a release process that required a push to production starting on Wednesdays at 7:30 am Eastern time, there were some pretty tired team members showing up to the office.
Earlier this year, we set aside a few weeks to retool our testing and release process. Using the book Continuous Delivery by Humble and Farley, we put into place a more reliable system for automating tests and creating deployable packages from sources that passed the tests. 
We migrated our source code repository from Subversion to Git so that each developer could make changes in a more isolated way. Finally, we put into place a means of automating the deployment of code to the test and production environments so that pushes could happen with a click of a mouse.
The end result was a much cleaner process that was repeatable and reversible. The ceremony of setting up tests and deploying code to production manually was eliminated. Work that might get holed up waiting for the following week's release could now be deployed once it had passed acceptance testing. Instead of one big release per week, we might instead have four or more smaller releases during the week.
Our team has embraced the change because it allows us to work on new items at the cadence of when things get done, rather than when the next fixed code deploy time will take place. The improved testing and deployment automation has made releases a much less stressful process. We now get a good night's sleep on Tuesdays, too.
