Insider's view: how we managed months of content changes for our public beta release!

Written by Rudy Rigot in Writing Room on May 07,2014

The past few months have been very exciting for us, as we were secretely preparing our recent public beta release with a lot of changes and enhancements like the brand new redesign of the Writing Room, the new pricing, and all the cool new features.

However, we wanted to make sure that our users were starting off on the right foot, so we really wanted our documentation, our blog posts, our feature tours, etc. to be introducing screenshots for the new design, and all the details of the new features right off the hook.

To master the release of all of this new content, we really needed a powerful, flexible way to plan our content... good thing our website's content lives in a repository! This was the biggest content release we had had on this repository, and the biggest I had worked on personally, as it impacted over 50 documents at once!

A release in is a place to which you can push changes that you want to publish together. You can have as many releases as you want, and it is recommended to group content changes into different coherent releases.

First step a few months ago: we had created a content release that we had named "Public beta release", and for months, we simply could push all the content changes we wanted to include in it. Of course, all without disturbing the publishing of changes unrelated to the public release (blog posts, fixes, ..).

When we'd push a version of a document onto the content release, it would look like this (here, the document we're pushing is the blog post announcing the release):

But when viewing the content release itself, we could find out much more about what was upcoming.

Clearly, it included a lot of screenshot replacements...

... it also introduced the documentation of brand new features, such as Group fragments...

... or the "Billing and Payment" section in the administration, now that you can purchase a plan...

... or even a completely new manual in the documentation, now that the users can also be "publishers".

We worked on making this great for months, literally. A few days before we released, I spent some time previewing the "Public beta release" content release on our website (I was authenticated of course, so you guys couldn't see those contents yet!), and looked at what everything would look like after we pressed the "Publish" button.

Everything was looking good, I knew we could proceed safely whenever the timing would be right, and that switching that release to production was technically a very simple procedure, so taking absolutely no risks when pushing the publish button... Here, a few seconds before, only one thing was left to be done:

And in a split second, our brand new content was out there, and our public beta release that we had spent months on was revealed to the world! All in all, this was a really painless process, and I was just glad we got to do it with our own beloved; I sometimes wonder what all of this would have felt like if we had used another way!

Rudy Rigot

Rudy is developer evangelist, and promote to our developer community.