Developers always want to use the newest, coolest tools. Admins want everything to be 100% reliable and stable. RavenDB was not just a new tool, it was an entirely new kind of tool for us. Successfully introducing it to our environment required our Ops folks to be comfortable with monitoring and maintaining it.
After our initial testing in various environments, we talked about it with Ops and deployed RavenDB to production — without anything actually talking to it. That was step 1 — get it deployed. It was on its own servers and nothing depended on it, but it was out there. RavenDB was now part of our build and deployment process, so we could update it whenever we needed to.
Step 2 was to deploy some fairly trivial code, accessible only to internal users, that used RavenDB. So far so good.
Step 3 was to turn on replication across the multiple instances of RavenDB. Here we did find some issues: a few in our own code as we learned about RavenDB; one in RavenDB itself — a bug involving the combination of replication and DTC-managed transactions. After a few emails with Oren and Hibernating Rhinos support, a build with a fix was available for download within a couple of days. We also asked for a new feature — the ability to disable transitive replication. That was available in another build within a week.
Step 4 was to start using RavenDB behind a real feature. We chose a non-mission-critical feature of our editorial system — something that, if broken, would only affect our editors, not the public. We shipped that and learned a bit more. Bryan posted about his experience creating that feature.
Step 5 was to ship a feature used by the public. We did an A/B test of a new user experience for some of our content in late 2011. That ran on RavenDB. More recently, in Feb 2012, we fully released that feature: we transitioned some of our blogs to a new look and feel, from our new RavenDB-backed CMS. You can see those blogs at: