You are currently browsing the tag archive for the ‘Continuous Deployment’ tag.
Ash Maurya posted a very in-depth case study over at Eric Ries’ blog a few days ago, and I highly recommend reading it. Interestingly, this case study is from a company that has existed for seven years (not a startup) so the lessons here apply to a broader audience.
Continuous Deployment is Continuous Flow applied to software. The goal of both is to eliminate waste. The biggest waste in manufacturing is created from having to transport products from one place to another. The biggest waste in software is created from waiting for software as it moves from one state to another: Waiting to code, waiting to test, waiting to deploy. Reducing or eliminating these waits leads to faster iterations which is the key to success.
You can find more case studies at the Lean Startup Wiki over at http://leanstartup.pbworks.com/Case-Studies.
If you haven’t seen it yet, Timothy Fritz’s post “Doing the impossible fifty times a day” on exactly how they are doing continuous deployment at IMVU is very fascinating.
“Our tests suite takes nine minutes to run (distributed across 30-40 machines). Our code pushes take another six minutes. Since these two steps are pipelined that means at peak we’re pushing a new revision of the code to the website every nine minutes. That’s 6 deploys an hour. Even at that pace we’re often batching multiple commits into a single test/push cycle. On average we deploy new code fifty times a day.
So what magic happens in our test suite that allows us to skip having a manual Quality Assurance step in our deploy process? The magic is in the scope, scale and thoroughness. It’s a thousand test files and counting. 4.4 machine hours of automated tests to be exact. Over an hour of these tests are instances of Internet Explorer automatically clicking through use cases and asserting on behaviour, thanks to Selenium. The rest of the time is spent running unit tests that poke at classes and functions and running functional tests that make web requests and assert on results.”
Be sure to check out the actual article for even more great detail, particularly around how they actually do their deployments once their automated test suite has assured a high level of quality.
In Eric Ries’ latest post over at Startup Lessons Learned, he addresses many of the most common objections he’s heard regarding continuous deployment. According to Eric, most of the objections boil down to the following two points:
1. That mission critical customers won’t accept new releases on a continuous basis.
2. That continuous deployment leads to lower quality software than software built in large batches.
I think he addresses both of these points extremely well and goes further in illustrating the improvements that continuous deployment brings to an organization:
- Faster (and better) feedback.
- More automation.
- Monitoring of real-world metrics.
- Better handling of intermittent bugs.
- Smaller batches
Be sure not to miss out on the great discussions in the comments thread as well. One comment Eric made that really stood out to me was his mention that the dichotomy between “fewer, more stable releases” and “faster, less stable releases” is a false one and that what continuous deployment truly brings to an organization is faster and more stable releases.
This reminded me of a lot of objections I’ve heard regarding Lean in that doing the right thing up front (building infrastructure, identifying and planning around your constraints, etc.) will give you better quality but slower development; in fact the truth (as borne out both in manufacturing and software development) that doing the right thing up front may cost more initially but you’ll end up letting people work faster while also increasing quality and customer value over the life of the project.
One of the constraints that makes moving towards continuous deployment difficult for some teams is the downtime required with web app deployments. Managed Chaos just posted an article on how to update web applications without destroying in-progress user sessions. In this specific example he illustrates how to do this using a Tomcat cluster, but the fundamental principles apply to any tiered web application architecture.
Databases are, of course, a bit trickier since you’ve potentially got lots of dependency problems; luckily, the Exortech blog recently addressed this issue as well.
The more I’ve been thinking about continuous deployment the more I feel like it’s really going to be a game changer for companies that adopt it. The barrier for entry is relatively low (and can be well understood before embarking on a project to adopt the process) and the reward of being able to reduce batch sizes on merges and (more importantly) give your product owners the ability to quickly get features in front of customers is key for any business.
Eric Ries has posted another fascinating article on continuous deployment, which is one of his more controversial (and brilliant, in my opinion) proposals.
To me, continuous deployment seems like a great idea for any start-up or environment where the value of fast iteration is more important than absolute stability (although stability is quite creatively addressed via the use of split testing in the production environment.)
Check out the article on why CD is worth using at http://startuplessonslearned.blogspot.com/2009/06/why-continuous-deployment.html and decide for yourself; unfortunately I’m not in a place right now where I can put this into practice, but as soon as I get back to a start-up or an immature product I’ll definitely be lobbying hard to put continuous deployment in place. If any readers get a chance to put it into practice I’d love to hear your stories.
Lean Builds 