It's all about the answers!

Ask a question

Create a new change-set from another


Rafael Hernandez (3222030) | asked Apr 08 '13, 2:39 p.m.
Good day everyone,

Im starting using flow targets to send change-sets to 2 different streams, but i want to do this:

-I want to send a change-set to a integration Stream OK
-Next the users that have a integration Stream Workspace recibe that change-set OK
-This last user create a new change set from the accepted files and deliver it to a Production Stream

I have the problem in the last step, when i change the flow target from my integration stream to a Production Stream it load the changes, but loads with a change set, not like a unresolved changes.

I hope anyone can help me.

Thanks in advance.

Comments
Geoffrey Clemm commented Apr 08 '13, 2:46 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Can you elaborate on "create a new change set from the accepted files"?   Is the last user making some additional changes based on the changes in the original change set?   If not, and they are just creating a "copy" of the original change set, then you can do that with the "patch" operation, but why are you creating a copy of the original change set?


Rafael Hernandez commented Apr 08 '13, 3:06 p.m.

Thx for your answer Geoffrey,

I'll tell you the process i want to implement:

i have 3 different streams:

DEVELOPMENT STREAM  ||  INTEGRATION STREAM  ||  PRODUCTION STREAM

- The developers creates a modification of any project to solve a request, they compile the project and send the results to integration stream (JAR,WAR, AAR, etc).

- The QA users accept the changeset on the integration stream and make tests

- If its ok, they create a new change set with the files and send it to deployers on Production Stream

- If it is not ok, they create a Defect and return it to the developers

The problem is, i want the QA users create only 1 new change set to send to Deployers, instead of send a multiple changes  from the developer

i hope you can help me

thx a lot

One answer



permanent link
Geoffrey Clemm (29.6k23035) | answered Apr 08 '13, 7:13 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
It looks like what you are looking for is the enhancement: Allow a change-set to have child change-sets (change sets it semantically depends on) (71191) .   Until then, probably the best workaround is to associate all the change sets that you want them to accept to a work item, and then have the developers accept all the change sets associated with that work item (select the links tab of the work item, multi-select the change sets there, and select the "Accept" operation).

Comments
Rafael Hernandez commented Apr 08 '13, 7:21 p.m. | edited Apr 08 '13, 7:43 p.m.

Thx for your answer Geoffrey,

I think the child change-sets its the answer, but now the only thing i want to do is to "copy" the components of the change set to another workspace, and then generate a new unresolved change.

example,

QA takes the components of the Integration Streams and test it,

Then, QA copy that components and paste it in a the production workspace, then generates a new change-set with the legend Deploy in production and deliver the new change set.

Deployers only the components contained on the "Deploy on production" change-set and deploy it on the server.

Thank you very much for your help



Geoffrey Clemm commented Apr 08 '13, 8:21 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

In general, it is a bad idea to "copy" things, because you lose traceability.  Suppose an error is discovered in the original change-set.  You can ask RTC "what streams contain that change-set", and then deliver your change-set fix to those streams.   If you make a "copy" of the change-set, you break the connection between the original change set and the copy.   But let's investigate a bit more if that copy is really needed.  For example, suppose there was a "ready-to-deploy" stream, and QA just delivered all successfully tested change sets to the ready-to-deploy stream.   The deployers can then just look at the components with incoming changes from the ready-to-deply stream, deploy those components, and then accept all changes from the ready-to-deploy stream into the "deployed" stream, so that RTC tracks for them which components have been deployed.

Your answer


Register or to post your answer.