Yesterday we deployed 19 times to our test environment (about once for every 4 commits). We were busy making some final refinements to a new feature that we launched last night. We had most of the team working on this feature (Single Feature Release) and the rapid feedback of the regular deploys helped ensure that everything was coming together for the release.
There is no way that we could have maintained this pace if we were taking down the test system for 10 minutes with each deploy. We needed to be able to continuously test the system throughout. This to me is one of the unsung values of zero-downtime deployment. Everyone normally focuses on the benefit of your users not seeing a fail whale page if they hit your site during a deploy. But let’s face it: unless you’re practicing continuous deployment, you’re deploying to test much more often than you are deploying to production. And the frequency with which we can cycle through and get feedback on changes in the test environment is one of the primary limiting factors determining how frequently we can release the software.
While many people that I’ve talked with like the idea of zero-downtime deployment, they have little access, control or influence over the production environment. So my advice is to start with the environments that you own, like test. Get it set up and running solidly there first. This greatly lowers the barrier to then rolling it out to production. And, as I describe above, the benefits of having zero-downtime in test are substantial.
In my next post, I’ll try to provide some more technical details about our zero-downtime set up.
80% technical, 20% social change. This blog is dedicated to finding ways to sustainably release software more frequently.