concept of cherry picking ?
Hi,
assuming the following scenario:
in the project area we have a stream for the continuous development called "development stream" and a stream to support my product in the field called "release 1 support stream".
We have three developers doing product maintenance in the "release 1 support stream" and a QA guy who needs 1 week to verify each fix before it gets shipped to the field.
Developer 1 and 2 have delivered minor fixes (fix 1 and fix 2) to the "release 1 support stream", fix 1 is build and QA has started the verification process. Now we found a major bug in our application. The fix 3 is simple and is delivered to the "release 1 support stream" after a day. Since fix 3 is much more important than fix 2 we won't loose a week for fix 2 verification. The library must be able to build fix 3 before fix 2. and send it for verification to QA. Is there a concept in RTC which supports such a scenario?
Thanx, Steffen
assuming the following scenario:
in the project area we have a stream for the continuous development called "development stream" and a stream to support my product in the field called "release 1 support stream".
We have three developers doing product maintenance in the "release 1 support stream" and a QA guy who needs 1 week to verify each fix before it gets shipped to the field.
Developer 1 and 2 have delivered minor fixes (fix 1 and fix 2) to the "release 1 support stream", fix 1 is build and QA has started the verification process. Now we found a major bug in our application. The fix 3 is simple and is delivered to the "release 1 support stream" after a day. Since fix 3 is much more important than fix 2 we won't loose a week for fix 2 verification. The library must be able to build fix 3 before fix 2. and send it for verification to QA. Is there a concept in RTC which supports such a scenario?
Thanx, Steffen
2 answers
I am not sure I fully understand the question. My best attempt:
In RTC, provided you have the change sets for fix 3 available either in the developers environment or tracked by a work item (typical) you can deliver/accept the fix to/in the integration/release stream. This only works if there is no dependency on a prior change to a file that has not been delivered/accepted yet. If there is an overlap between Fix2 and Fix3 you will notice that.
In RTC, provided you have the change sets for fix 3 available either in the developers environment or tracked by a work item (typical) you can deliver/accept the fix to/in the integration/release stream. This only works if there is no dependency on a prior change to a file that has not been delivered/accepted yet. If there is an overlap between Fix2 and Fix3 you will notice that.
Hi Steffen,
It sounds like you're looking for a way to back out some set of updates so that you can push through another update that takes precedence to the other ones.
One way to do this is to make use of additional streams which are used to deliver work into and which needs to have additional testing done on it before it should be delivered to the "product release" stream. Then, if there are errors/problems, the code will not have been delivered to the product release stream, allowing the higher priority work to be delivered ahead of the other work.
Tim Hahn
It sounds like you're looking for a way to back out some set of updates so that you can push through another update that takes precedence to the other ones.
One way to do this is to make use of additional streams which are used to deliver work into and which needs to have additional testing done on it before it should be delivered to the "product release" stream. Then, if there are errors/problems, the code will not have been delivered to the product release stream, allowing the higher priority work to be delivered ahead of the other work.
Tim Hahn
Hi,
assuming the following scenario:
in the project area we have a stream for the continuous development called "development stream" and a stream to support my product in the field called "release 1 support stream".
We have three developers doing product maintenance in the "release 1 support stream" and a QA guy who needs 1 week to verify each fix before it gets shipped to the field.
Developer 1 and 2 have delivered minor fixes (fix 1 and fix 2) to the "release 1 support stream", fix 1 is build and QA has started the verification process. Now we found a major bug in our application. The fix 3 is simple and is delivered to the "release 1 support stream" after a day. Since fix 3 is much more important than fix 2 we won't loose a week for fix 2 verification. The library must be able to build fix 3 before fix 2. and send it for verification to QA. Is there a concept in RTC which supports such a scenario?
Thanx, Steffen