• 50
• mainwindow
• qtdev
• qtdn
• release
• release day
• qt devnet
• qt 5

Log in

Happy Release Day!

06
Jun

by Alexandra in Qt DevNet News (33617 views)

Over here we have a great tradition to celebrate the little things that make us proud. Today’s reason to celebrate is not exactly a little one but it’s one that stays behind the scenes, mostly invisible to you.

This week, we have pushed our 50th release since launching the Qt Developer Network in May 2011. Repeat after me: fif-ti-eth!

If you’re into math you’ll quickly figure out that overall we have managed to roll out a release every second week*. Some were relatively small bug fix releases, others brought bigger improvements, design changes, or major features — like the integration of the Qt documentation, or the coming Q&A forums. Main driving force behind this rigorous schedule is our release manager Gurudutt. Applause!

So, how do we do it?

Everything that catches our attention, or that you report at bugtracker.qt-project.org, and any idea that crosses our minds, is captured as issues in our Redmine instance. Gurudutt sorts everything into release buckets, while Marius keeps an eye on the backlog/wishlist bucket. Every week we hold a status meeting with the fine folks at Trollweb in Stavanger, and discuss, prioritise and (re-)assign issues, close them, and sometimes bump them to the following release. No black magic involved, it’s all pretty standard procedure.

New development is first happening on our development server. After a first round of testing, Gurudutt releases the changes to the stage server. There the code matures, and we make sure we don’t break things. Gurudutt wipes the installation on this server from time to time to keep it in sync with our production server. Every time we make sure to delete all private user data, so you don’t receive funny emails from us.

When it’s time to release, Gurudutt goes through the issue list again, bumps stuff that didn’t make it to the following one — provided it’s not a critical fix that is missing — and then puts up the red release banner.

After an appropriate warning time has passed, he sets the site to read only — caching for the win! — and rolls out the new codebase. That takes him something like 3 minutes by now. Pretty impressive, huh? He sets the system back to accepting input, the banner goes away, and we’re done.

The beauty of web development

Obviously, we don’t have to bother with packaging and shipping updates to a bazillion of computers running our software. By sticking to a 2 weeks release cycle, we can roll-out fixes quickly so you don’t have to wait forever to get this annoying CSS bug fixed, or your miscalculated number of points straightened out. And of course, if we break stuff it’s much quicker to either roll back or to get a fix out the next day. Chances are you won’t even notice.

How do you or your organization handle releases? Are you working on packaged software that is updated once a year and has an endless QA cycle? Do you have special channel to push small updates to your users? Do you rely on a slow app store process? Tell us in the comments!

*) Given our ridiculously high bus-factor, we skipped some weeks in between there. One of us is sick – no release this time.

Commenting has been disabled for this entry.