Ayende @ Rahien

Refunds available at head office

The RavenDB Release Process

We got several questions about this in the mailing list, so I thought that this would be a good time to discuss this in the blog.

One of the best part about RavenDB is that we are able to deliver quickly and continuously.  That means that we can deliver changes to the users very rapidly, often resulting in response times of less than an hour from “I have an issue” to “it is already fixed and you can download it”.

That is awesome on a lot of level, but it lack something very important, stability. In other words, by pushing things so rapidly, we are living on the bleeding edge. Which is great, except that you tend to bleed.

That is why we split the RavenDB release process into Unstable and Stable. Unstable builds are released on a “several times a day” basis, and only require that we will pass our internal test suite. This test suite is hefty, over 1,500 tests so far, but it is something that can be run in about 15 minutes or so on the developer machine to make sure that our changes didn’t break anything.

The release process for Stable version is much more involved. First, of course, we run the standard suite of tests. Then we have a separate set of tests, which are stress testing RavenDB by trying to see if there are any concurrency issues.

Next, we take the current bits and push them to our own internal production systems. For example, at the time of this writing, this blog (and all of our assets) are currently running on RavenDB build 726 and have been running that way for a few days. This allows us to test several things. That there are no breaking changes, that this build can survive running in production over extended period of time and that the overall performance remains excellent.

Finally, we ask users to take those builds for a spin, and they are usually far more rough on RavenDB than we are.

After all of that, we move to a set of performance tests, comparing the system behavior on a wide range of operations compared to the old version.

And then… we can do a stable release push. Phew!

Tags:

Posted By: Ayende Rahien

Published at

Originally posted at

Comments

Daan
05/23/2012 09:40 AM by
Daan

Thanks ayende for giving insight in how your relase process is. What im missing is how do you handle exceptions. For example really important bug fixes that needs to be released.

Chad
05/23/2012 09:57 AM by
Chad

Build 726? Do you mean 926?

Barry Dahlberg
05/23/2012 10:01 AM by
Barry Dahlberg

Are you able to give any more info on where RavenHQ fits in to this process?

njy
05/23/2012 11:17 AM by
njy

+1 for Barry: we would like to know which client to use and which features/bug fixes we can count on.

Ayende Rahien
05/23/2012 12:15 PM by
Ayende Rahien

Daan, Exceptions are just that, we have no set process. Usually, however, we will issue a separate unstable build with just a fix for something like that. This allows users impacted by the issue to handle it, while it also allows us the time to go through the full stable release process.

Ayende Rahien
05/23/2012 12:16 PM by
Ayende Rahien

Chad, Yes, 926 is what I meant.

Ayende Rahien
05/23/2012 12:17 PM by
Ayende Rahien

Barry, RavenHQ goes through an additional release testing on their end. This is because we usually have additional requirements from RavenHQ (custom extensions and behaviors running multiple databases on single host).

Comments have been closed on this topic.