Testing production applications against new builds
Tropo maintains two clusters for your applications to run on. Our free developer applications run on one cluster of servers and paid production applications run on a separate cluster. This affects you and your applications in a few ways, and opens up some possibilities for development and testing.
I’m going to spend a few blog posts talking about how to use our development and production servers effectively. First up, I’ll talk about you can use the two types of servers to ensure bug-free upgrades.
Every few weeks we complete a development cycle and determine if the work completed is ready to be published into our network. We take into account our testing and QA, what sort of issues are found in the existing builds on the network, and the number and significance of any bug fixes in this build.
When we determine that we have a build we’d like to put on the network, we first push this to the servers that run free developer applications. We do this for a few reasons. First, it means that the build is exercised to find any bugs missed during QA and that these bugs are found before they can impact production applications.
Second, it allows you as a developer to test your production code against new Tropo software before your production apps start running on the new software. Tropo software builds are pushed to production after they’ve run for at least a week on our developer clusters. For some builds, for instance, those with significant changes like an upgrade of Ruby or PHP, we’ll wait even longer to move them to production. This week, we’re planning on promoting a production build that has been running our developer clusters since April 18th. It was a big change, and we wanted to make sure we had it right.
You can find out about new developer builds by subscribing to the Tropo changelog at http://changes.tropo.com/ or following @TropoChanges on twitter.
To test your production application against the latest developer build, simply create a second application and leave it in development mode. Put a copy of your code in this second application and run your tests. This second application will be running against the latest Tropo build, allowing you to validate your code against it.
While we take great care to ensure that our upgrades do not break customer applications, this extra validation step can help make sure that if a bug does slip through, we can catch it before it affects your application’s users.
In future posts, I’ll talk about A/B testing, automated deployment, and how we route calls and messages within our network.
©2011 The Tropo Blog. All Rights Reserved.
.Related posts:
Originally from All Voxeo Blogs Feed
Leave a Reply