Return to Jive Software

Currently Being Moderated
12

The Release Train

Posted by Matt Tucker on Aug 1, 2007 2:18:48 PM

Back in April, I blogged about how we were adopting a release train model for our Open Source projects. Since then, we've rolled out the same process to our commercial products Clearspace and Jive Forums. The release train is a fairly fundamental departure from how we've done releases in the past, so we wanted to provide more details about exactly how it works.

 

Why did we make a switch in how we build our software? There were many motivating factors, but the general theme is "move as fast as possible with high quality". For end users of our products, the key thing to know is that there will be a new release every three weeks. Each version contains bug fixes and new features and we're committed to maintaining high quality for every release (no more rushed bug fixes a week after a release). The graphic below illustrates how this process works:

 

 

Each release (from top to bottom of the graphic) takes a total of nine weeks: three weeks of planning, three weeks of development, and three weeks of QA. All three processes run in parallel, which leads to the three week release cycle.

 

Answers to common questions:

 

Q: Do we expect customers to upgrade every three weeks?

A: No, that's unreasonable in most environments. We've made it as easy to do upgrades as possible, and we hope you'll upgrade at least once per quarter to take advantage of all the great changes. When you do upgrade, the release train process will help ensure you're on high quality code.

 

Q: How will version numbers work?

A: Each release will get a minor version number: 1.5, 1.6., 1.7, etc. Major version numbers will change approximately once per year.

 

Q: How will you develop major new features that take more than three weeks?

A: Good question. No model is perfect and we're already working on new features that will take more than one train cycle to fully finish. In those cases, we're breaking the projects into milestones and using code branches as necessary.

 

Other Release Train Fun

 

The release  train has had a deeper cultural impact than just being a way that we engineer our software. The marketing team now times a lot of their work on the train, and even our major happy hours are now on the three week cycle. Late afternoon of every third Friday, we gather the company for a demo of the new features and then adjourn for partying.

 

Time will tell how well this new process works, but we're excited about it and the results so far are promising.

 

4,958 Views Tags: clearspace, planet-jabber, developers


Add a comment Leave a comment on this blog post.
Aug 14, 2007 5:53 PM Guest Mike Herrick  says:

http://www.accurev.com/product/docs/SCMBranchingModels1.pdf

 

What kind of branching model do you use? Branch by purpose or something else?

 

What SCM do you use if you don't mind saying?

 

How is it going in that dpt.?

 

Sounds like a good model to me.

 

Very Lean: http://www.poppendieck.com/

 

Aug 14, 2007 5:53 PM Guest ryan  says:

errr... Maybe I'm missing something, but isn't the 3.3.2 release of openfire close to 6 weeks old?

 

Aug 14, 2007 5:53 PM Guest matt  says:

Mike -- we use SVN and branch at the end of every three weeks. We then do QA on the branch and release out of the branch while trunk continually moves forward. The great thing is that trunk never needs to be locked down -- it's always a safe place to check in new work.

 

Ryan -- yep, you're correct. Openfire is not actually on the train yet. That's the case because so much work has been going into clustering. That will change in the near future.

 

Aug 14, 2007 5:53 PM Guest gsmd  says:

You guys really should think of a way to automatically upgrade your software w/o reinstalling it.

 

Aug 14, 2007 5:53 PM Guest Ben Davis  says:

So far I'm not liking the Train so much. How about spending more time on

regression testing at the "QA station"?

 

Aug 14, 2007 5:53 PM Guest matt  says:

gsmd -- we'd love to implement that in the future. I think it would make upgrades much easier.

 

ben -- sorry to hear that. Are there some particular issues you've run into? We focused on quality a lot in Clearspace 1.4, so I'd be curious to get your feedback on that release.

 

Aug 14, 2007 5:53 PM Guest Ben Davis  says:

Here a couple that I know of off the top of my head:

 

XMPP Presence stopped working when I upgraded from 1.2 to 1.3.

 

LDAP authentication broke when I upgraded from 1.3 to 1.4. Can't log in. A new install of 1.4 works but the upgrade is a problem. Presence still not working.

 

What worries me the most right now is migrating data from Knowledge Base. The all-or-nothing import tool you now have may work well for Jive Software but our users here cannot handle such abrupt change gracefully. It didn't work well for me when I tried it with 1.4 anyway.

 

I imagine that new customers are most important right now but please don't forget about us KB customers. Thanks.

 

Aug 14, 2007 5:53 PM Guest matt  says:

Ben -- from your description of the presence and LDAP issues, I'm not sure if we're aware of them. We did create a new AuthProvider structure that possibly could have impacted the upgrade process. Did you post any details about this issue in the support forums? If yes, please paste in any links and we'll be sure to check them out.

 

We'd also be interested in hearing more about your migration needs in the support forums. There are several improvements that we already have planned for the feature, but the more feedback we get on it, the better.

 

Thanks,

Matt

 

Aug 14, 2007 5:53 PM Guest Ben Davis  says:

Matt,

Yes, both issues are being addressed by support. I will also post more details about migration issues. Thank you.

 

Jan 25, 2008 11:03 AM Guest lou  says:

Matt,

what do you think of implementing release train model for a new hardware porting existing software from a different hardware architecture?

will the train model actually work?

thanks.

Jan 25, 2008 11:40 AM Matt Tucker Matt Tucker    says in response to lou:

lou -- I've never done hardware development before so I'm not sure how well a release train applies. At the very least I'd imagine that you'd need slightly longer iterations?

Feb 11, 2008 7:11 AM Guest WR  says in response to Matt Tucker:

I'd recommend to separate the porting layer from the apps layer. Your porting vendors drive your releases under the apps layer.

I’ve implemented the release train myself, including the name! It worked only if you have a seamless migration and customers are TRUSTING your software. When you get more down the line the release gap between your current release and the environments in the field will become bigger. People will not migrate if they do not trust your software. Instead of migrating they will demand fixes in the release they have. In such a case you will have a deadlock. Mind you, this software is rapidly replacing the MS Office paradigm and only one glitch in a seamless migration will stall the IT depts. into further migrations.

We finally gave 2 flavours:

Get Fix Packs on a major release (including porting fixes)

Get a Release Train (a functionality migration!) from one to the next major release.

If I’m gonna buy your software I’d like to see those options.