Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Version/release maintainance

 
kundan varma
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
Can somebody tell me what to do in scenariao given below.
Scenario - There are 40 functionality in release 1 of a module. This module goes to QA team and they found major bugs. By this time developers are working on functionality 41,42...so on. Now how to maintain version here??
If i fix QA bugs in 1st release then how to incorporate it in second release i.e having functionlity 41,42... . I am confused how to maintain code here. Can some body give some input???
Thanks,
kundan
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My team has had QA at the end of the cycle, right before release, for a decade or so. I've never gotten an answer that I like regarding what the purpose is. The schedule shows no more iterations for fixing anything so I figure that all QA can do is stop a release. In fact they find bugs and we rush around with ad-hoc patches outside the official "process." Yuck. My conclusion is that QA at the end of the development cycle is doomed to create the kind of chaos you are worried about.

The agile methods all run user acceptance tests as they go as the measure of when a story is "done". If the tests find a defect you're not done yet and you fix things up before going on to the next story. If your stories are small enough the fixes are usually very small, too.

If your tests are automated you can rerun them often to make sure a new story didn't break an older one. The "QA at the end of the cycle" just goes away. Whew.

Is that useful? Try to build in continuous testing and make the "QA cycle" disappear. Our QA team is not going away, so I think the goal should be to make them redundant ... pass all the tests before code gets to them so they can't fail in QA.
 
Balazs Borbely
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can tag the version which is released to QA. If the QA founds bugs,
any time you can make a branch from that tag and fix it, and give it back to QA for retesting.

BUT those fixes should be added to the HEAD version as well.
 
kundan varma
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Balazs Borbely ,
Can you explain more.What is head version. If i create a branch then how to maintain new functionality and bugs on previous functionality. I have to work twice to merge files or what??
Thanks,
kundan
 
Kishore Dandu
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please look into aspects called branches, labels.

Merging twice, thrice etc is part and parcel of day to day complex development efforts.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kishore Dandu:
Merging twice, thrice etc is part and parcel of day to day complex development efforts.


Unfortunately, yes. Maintaining branches really is painful.

Much more effective is it to have QA not find bugs, because there aren't any. http://www.xprogramming.com/xpmag/jatQAonTeam.htm
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Was that really just put up today? Cool.

Branching almost always looks like this:


Branches are a pain. We now use a version control tool that requires us to label some version of each file for each release number. We're working on two releases at once so sometimes you check in a file and label it for N, sometimes N+1 and sometimes both. If N and N+1 are not identical and you want to make a change for both releases you have to check out each one, change it and check it back in with the right label. The build tool checks out by label so to build for N it gets all the N files and only the N files. Many opportunities for error.
 
kundan varma
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Stan, You are really good in explaining anything.
Thanks,
kundan
 
kundan varma
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Stan,
What is the exact difference between branching and labeling. When to use branch and when to use label.
Thanks,
kundan
 
kundan varma
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I use PVCS
 
Kishore Dandu
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:


Unfortunately, yes. Maintaining branches really is painful.

Much more effective is it to have QA not find bugs, because there aren't any. http://www.xprogramming.com/xpmag/jatQAonTeam.htm


THis is never possible. Even with XP. Bugs are going to arise some time or other after going to production(unless you are developing simple stuff)
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kishore Dandu:

THis is never possible. Even with XP. Bugs are going to arise some time or other after going to production(unless you are developing simple stuff)


Yes, there are going to be bugs. But there don't have to be more than a handful a year, as experience of some teams out there show.

And the bugs don't just arise after some time, simply because we are working on non-simple stuff. They are found in production because we didn't write the right tests during development.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And bugs don't have to result in branches and patches. If you (can) release frequently any bug can just go into the next release.

Labeling is just a technique for keeping track of branches. It's an optional feature in Borland's StarTeam. I'm not fond of the way it does labeling; it's very easy to check in changes and forget to update the label so the next build doesn't pick it up. And I haven't figured out how to check things in while in a particular label view. But it's far better than holding patch versions of code private, e-mailing them to the build crew, etc.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
If you (can) release frequently any bug can just go into the next release.


And the fix for the bug into the release after that...

But this actually is a good point - the reason for branching isn't that we need to fix bugs, but that our customers fear that together with the fix they will also get new bugs.

Producing high quality code with which that doesn't typically happen really is the superior strategy.
[ February 25, 2006: Message edited by: Ilja Preuss ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic