idea on best practices for deliverying bug fixes
Hello all,
We are coming up with an initial document for our RTC role out. One of the items we are trying to nail down is how projects will resolve/deliver bug fixes. Here is the scenario we have: A project is working on an production stream, and at some point is ready to release <project>_R1.0. After the build a release tag is associated with the build. A defect is found, which needs to be resolved and released before R2.0. From what I know the developer would create a workspace from the R1.0 build. After fixing the bug the developer will have to deliver the changes to a bugfix stream. How do those changes get into the production stream? I initially thought the developer would change the flow target of their workspace to deliver the changes to the integration stream. I think this will work fine as long as developer treat the bugfix workspace as a one and done. The reason I think the bugfix workspace should be one and done is because when you change your flow target from the bugfix stream to the production stream you will have to accept changes made to files associated with the bugfix before they deliver their changes. Therefore, you can not change the flow target back to the bug fix stream because new features may get into the bugfix release. The other option is to change the flow target of the bugfix workspace to a production workspace. This would allow you to maintain two workspaces ongoing, but my question is there another processes that people have thought of for this situation? Any and all input is greatly appreciated. |
4 answers
Assuming the developer has delivered her changes to the bugfix stream before she delivered to the production stream, she can replace the components in her workspace with the latest from the bugfix stream to get rid of any changes she picked up from the production stream.
Martha Jazz Team Build Component |
I initially thought the developer would change the flow target of their workspace to deliver the changes to the integration stream. I think this will work fine as long as developer treat the bugfix workspace as a one and done. I'm not sure what "one and done" means. You have a few possibilities: 1. If your bugfix stream will contain a subset of your production stream, encourage your developers to use a single remote workspace. They should flow everything into production, but be more selective about flowing into the bugfix stream. 2. If you think the two streams will quickly accumulate incompatible changes, you could encourage developers to maintain two remote workspaces. When they switch from task to task, they can load the appropriate one. When Jazz loads a remote workspace, it only downloads the files that have changed, so it should be relatively fast. 3. If the two streams will accumulate incompatible changes <i>and</i> they have too much stuff to reload every time, developers could maintain two remote workspaces, loaded into different local workspaces. That way they can either run two Team Concert instances simultaneously (one for each stream), or switch loaded workspace when they switch tasks. 4. If you're feeling brave, you could have all changes delivered to the production stream, and have a releng developer that unentangles bug fixes and backports them to the bugfix stream. Depending where your new changes are added, this could be an exercise in pain. I mention this because it may work if your new features are mostly touching files/folders that aren't in the bugfix stream. There are probably other possibilities as well. Creating new streams and remote workspaces is trivial with Jazz, so you may want to experiment with different configurations. If something doesn't work, reconfigure your stream layout and allow the appropriate solution to evolve out of it. e |
|
Thank you for the responses.
What I meant by "one and done" is that a developer would create a workspace from a release build (R1.0), resolve a specific bug, deliver the bug fix to the bug fix stream and production stream. After that the workspace would be deleted. If another bug is found the developer would create a new workspace from the initial R1.0 build. I don't think option one will work because your bug fix should be based on the source used in the production build (R1.0), which may very well be different then the current version in the production stream. Therefore, the developer would resolve the bug first, deliver to bug fix, and the production. Once the flow target is changed from bugfix stream to production the developer will have to accept any incoming changes if the same file is changed in both streams. That means the workspace can not longer be used to for bug fixes. Option two is the method I have been contemplating implementing so far. Option three is another good idea, and I am not brave enough to try option four. thanks again for everyone's input. |
Geoffrey Clemm (30.1k●3●30●35)
| answered Jun 04 '08, 7:38 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
On a minor terminological note, by "remote workspace", Evan is referring
to a repository workspace, and by "local workspace", Evan is referring to the files loaded by Jazz SCM into your local file system (e.g, into your Eclipse workspace). Cheers, Geoff echughes wrote: danielrmartinwrote: |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.