Release cycle period

[Rajan Chinna]

In a typical product development environment, what is the release cycle period should be ?

From my experience it could be anywhere about 2 weeks to 2 months.
We practice the 2 week iterative cycle which I think is kind of over kill. Every 2 week we have to cut new branch and test the code and take it to a shippable state.
If there are any major bug fix in trunk code base than it has to be back ported to multiple branches where the code merge could cause lot of overheads. Like some times you fix in one branch but forgot to apply the patch on the other branch. It is like wasting developers and testers time.
I feel like 2 week cycle is too short, what would be the ideal period?

I am interested to see what best practices others are following in their product development environments.
Thanks

[David Newton]

There is no "ideal" period, only "ideal for a given environment".

If you're releasing every two weeks you shouldn't need to backport changes more than a release or two, though. Testing should be happening as development progresses--when the iteration is over it should be tested already. A handoff to QA shouldn't matter; they're still on the same cycle, just offset. Two weeks only works if there's strong agile buy-in from *all* the stakeholders, not just development.

It also depends on what kind of functionality you need to be able to roll out, how long the product needs to remain in various stages, and so on: without knowing more it's impossible to be anything but vague. At my current gig, we have around a week of design, two weeks of development, a week of dev-internal integration testing. Then it goes to QA for about a month (don't ask--I have no idea why it takes so long), then to UAT for a minimum of one week, then to production.

So right now say we've just rolled rel56 to production, rel58 is about half-way through QA/UAT, and rel60 development is beginning. At *most* we'd have to move a change into two releases, rel58/rel56, but any changes moving to production have to be severe in order to be promoted off-cycle.

Previously we worked on a two-week cycle in development, but QA was done internally, and there was no UAT. Before that, same two weeks, with about a week of QA, and a week of UAT, so we still weren't backporting more than two releases--but it was *very* rare we had to, because it had to be a deal-breaker in order to disrupt the current iteration. When you're releasing every two weeks, things don't stay broken very long.

[Rajan Chinna]

Unfortunately in our case it is not like push the bug free code into production and forget it. We have clients using the product on different releases,
means some are on Rel50, Rel51, Rel52 etc... where as our most recent release is at Rel60. Now lets say the client using Rel50 want
some enhancement or bug fix then we are suppose to port those changes up until Rel60.

As we are growing bigger by adding more clients, we end up having clients staying on different releases. Obviously some of them are hesitant to
upgrade to most latest release, they are still using Rel40. I am thinking by reducing number of releases to say 4 per year could help us some.

I understand David, each dev environment is unique, want to hear from experts as what process they are following.

[Ilja Preuss]

Rajan Chinna wrote:
As we are growing bigger by adding more clients, we end up having clients staying on different releases. Obviously some of them are hesitant to
upgrade to most latest release, they are still using Rel40. I am thinking by reducing number of releases to say 4 per year could help us some.

It's obvious that the number of releases in production is costing you. Reducing the frequency of releases would be one way to reduce the number of releases in production - with the drawback that you get worse return of investment and reduced feedback.

Another way would be to make it less painful for your customers to update to the most recent release. What would it take to do that?

[Ilja Preuss]

Oh, and another way to reduce the overhead of having to backport bugfixes to branches is to ship less bugs. Seriously.

[David Newton]

Ilja Preuss wrote:Another way would be to make it less painful for your customers to update to the most recent release. What would it take to do that?

I agree with this--it does not make sense to have a wide range of releases in production. Part of the development process should include upgrade paths.

[Rajan Chinna]

As we all know no software is bug free, we strive to keep the bugs low but as the product grows monster size it gets really challenging.
Usually we roll a stable tested release to the client but they often request for more enhancements and fixes.

Well, we do encourage clients for up-gradation, that way we get more business
The upgrade process will take minimum 6 months to 2 years depending on various factors like how back they are on the release, thorough
end-to-end testing, UAT of all the modules and other resources issues.

Our product is more flexible, we take all clients request and try to incorporate them in to the product, that way they should still see that
added feature when they migrate to a different release in the future. Here client enhancement means money, so we don't say NO
to any of the client request.

I would love to hear others experiences who are working in product development environment.

[David Newton]

Rajan Chinna wrote:Here client enhancement means money, so we don't say NO to any of the client request.

IMO that's a recipe for certain disaster: you *must* be able to say no, and your post here pretty much backs that up.

But if the release cycle is two weeks, and your span is rel50-60, that's not even a half-year. Again, I'd still suggest it would be better to transparently upgrade all of your clients. (Or not transparently, and get them actively involved in the agile process--remember when I said that agile doesn't work unless *all* stakeholders have bought in?)