It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,882
×12,008
×1,201
×889
×562
×73
×26

question asked: Dec 03 '13, 8:53 p.m.
question was seen: 7,574 times
last updated: Dec 06 '13, 9:16 a.m.

Related questions

What is the best way to baseline and build selective changesets?

0
Andy Jewell (242●3●63●74) | asked Dec 03 '13, 8:53 p.m.
retagged Dec 06 '13, 9:16 a.m. by David Lafreniere (4.8k●7)
Sorry for the long post!  Here is the executive summary for my most pressing issue(from problem #2, below):

What's the best way to build a selected set of changesets in a build workspace?  The build workspace is on the target stream.



Our business users are addicted to cherry picking fixes from UAT and it seems that this will not be changing, though it has shown itself to be a risky and troublesome practice on many occasions.  We also have concurrent releases which are integrated in the UAT stream and tested concurrently in the UAT environment.  So it looks like this:

                                     PROD
                                         ^
                                         |    
                                         |   
                                      UAT
                                      ^    ^
                                     /       \       
                                    /         \
                               rel1        rel2

This gives me two challenges: 

1) To handle selective builds, we deliver the changesets we want deployed to PROD and the build process will then compare the build workspace to the PROD stream to determine what is being deployed.  If everything goes perfectly, this works.  If there's a hiccup and the build breaks, then the workspace henceforth matches the PROD stream so there is no longer any deviations between the build workspace and the PROD stream.

I don't like the fact that the build process is dependent on the state of the workspace.  I think I'm missing a key paradigm, like possibly creating a baseline of the incoming changesets or alternatively, creating before and after snapshots and then using snapshot comparisons.  I also considered creating baselines in the source streams and changing the workspace stream configuration on the fly (rather than using accept at all).

2) The second challenge is inter-related with #1 in the sense that when the build breaks, I'm left with an extremely difficult manual manipulation task.  For example, for the PROD deployment, I need to be able to generate a report of all the code being delivered, yet, neither Changeset Explorer nor Changeset Summary seem to give the needed functionality.  As far as I can tell, Changeset Explorer just shows you the files in the changeset.  CS Summary at least provides a way to load the file but it will not load the entire path nor can you load multiple changesets at once.  Locate changeset seemed promising since the changeset results appear in under a stream name that suggests you could load the changeset results into their own workspace, but actually, selecting that option just takes you to the normal repository workspace creation wizard.  Is there someway to do something with a set of changesets?  For example:

a.  Create a workspace on a stream loaded only with selected changesets
b.  Generate a report of selected changesets
c.  Export selected changesets either to file (load) or as a report
d.  Baseline or snapshot the changesets

I'm looking for some way to capture the essential "oneness" of a group of changesets.


Thanks for any suggestions!


- Andy


3 answers

Most liked answers ↑|Newest answers|Oldest answers

1
permanent link
Scott Cowan (966●3●10) | answered Dec 04 '13, 10:32 a.m.
JAZZ DEVELOPER
Hi Andy,

What do the lines connecting your streams represent in your diagram?  If they represent which way your change sets flow, then they should be directed.  Your questions seem to indicate you deploy from your PROD stream, but then I'm confused why both rel1 and rel2 streams would flow into one PROD stream from which you'd deploy.

But in general, the stream you release/deploy from *is* the cherry picked set of change sets.  If a build fails on a build workspace flowing to that stream, then open the failing build result.  It will have a "Show changes" link in the Contribution Summary section on the Overview tab.  Clicking that link will list the new change sets per component that have been accepted into the build workspace from PROD.

Now you need to flow a fix into that stream.  In self-hosting we do this from a repository workspace (that may flow change sets through another stream).  Your fix could be to deliver new change set(s), or it could be that you want to discard change set(s).  This is where you're cherry picking.  Discarding a change set is a bit trickier.  You first need accept all incoming changes into your repository workspace (so you're in sync), discard the one(s) that you want, but instead of delivering a discarded change set, you actually replace the component in the stream with the one in your repository workspace.  You can do this with the "Replace in <flow target>" action in the context menu of the Pending Changes view.

Once the new change set(s) or the component replace flows to your PROD stream, you can request a new build with your cherry picked change sets.

If your business users are cherry picking the change sets, then they need to be familiar with flowing change sets from stream to stream and dealing with conflicts and gaps as they arise (or have someone do it for them).  It's unclear from your post how they will work, but they may need a repository workspace with both the UAT and PROD stream as flow targets.  Then you switch between flow targets to accept from one stream and deliver to the other.

Is any of this helpful?
Scott
Comments
Andy Jewell commented Dec 04 '13, 11:01 a.m.

I added directional arrrows to clarify.  We have two (or more) releases which are flowing into the UAT stream and both releases are deployed to the UAT environment.  It's from here where the changes are cherry-picked for deployment to PROD.  Sorry about the confusion in that description!


Thanks for your thoughts, it is helpful, for example, it's an interesting approach to accept all changesets and then discard the one's that aren't needed.  This may be complicated for us because the changesets will be needed eventually so I'm wondering if they would be re-deliverable at a later date.  In other words, all changes are flowed into UAT for both releases though the final release (flow into PROD) might be any combination of changes currently in UAT.  So basically, UAT becomes a pickle barrel to choose changes from.

In this approach, I'm wondering if I will need to track the UUID of discarded changesets so that when they eventually do go to PROD I would be able to re-flow them into the stream.  Hmm, I will continue to review your suggestions, they are helpful, thanks!

Scott Cowan commented Dec 04 '13, 11:24 a.m.
JAZZ DEVELOPER

To elaborate on the cherry picking process, create a repository workspace from the PROD stream.  Then in the Pending Changes view, you can select "Change Flow Target..." from the context menu and pick the UAT stream.  The Pending Changes view will show you what change sets are different between your repository workspace (which is synced with PROD for the moment) and UAT.  Accept any new change sets you want, then change the flow target back to PROD and deliver.  You do not need to track the change set UUIDs.  The Pending Changes view will help you in this regard.

Another thing to note about this repository workspace is you may not need to load it.  That could save you a lot of time, but it can add risk.  When it comes to the Load Repository Workspace page of the New Repository Workspace wizard, just click cancel.  However, you won't know if the workspace compiles cleanly.  And you will have to load the workspace if you have to resolve conflicts.

Scott

Andy Jewell commented Dec 04 '13, 12:22 p.m.

Yes, we're on the same page, I think.  In fact, we are doing cherry picking in the same fashion that you describe.  But my problem is that this relies on the current state of the repository workspace.  My build process currently uses a compare command to see what changesets need to be built.  If the build process had already accepted the changes and then fails, in the current design of the build process it can't be restarted because there's no longer a difference between the workspace and the UAT stream.  So I'm looking for something more robust.  Maybe the answer is as simple as creating a new repository workspace (from PROD, as you suggested) for each build.  If the build fails half way through, restarting it should show the same undelivered changesets because the build process would be creating a new workspace every time.  Hmm. . . sounds plausible. . ?

Scott Cowan commented Dec 04 '13, 1:15 p.m.
JAZZ DEVELOPER

So, I think you're having trouble finding a change set you want to discard.  I agree this isn't as easy as it could be.  The trick is to find the component with the change set.  It is listed in the work item links section under Change Sets if that's how you've decided which change sets you want.  The component name is part of the change set label.  Once you find the component in the Pending Changes view, you can "Show > History" to see the list of change sets in the component in reverse chronological order.  You can then select change sets from the top and "Discard...".

1
permanent link
Arun K Sriramaiah (3.2k●2●36●77) | answered Dec 05 '13, 9:00 a.m.
Hi Andy\Scott.

Its a good discussion.

 I would suggest you to create an Baseline on the UAT Stream for the changeset you wanted to include in the build.
and to promote ( replace the baseline in Production Stream) the baseline from UAT stream to Production Stream.

Note: Before replacing anything create a Snapshot on the stream you can revert back to the old content.

1) Create a baseline in UAT
2) Replace the baseline in Prod Stream

Please let me know does it help or if you need any further information.

Regards,
Arun.

Comments
Andy Jewell commented Dec 05 '13, 10:51 a.m.

Arun, I think your suggestion is the ideal in concept, it would be nice to be able to create the appropriate baseline and then promote (or accept) the baseline into PROD.  Unfortunately, in my case there are other changesets in UAT that are not going to production.  Another suggestion I read elsewhere was to suspend the changes from the UAT stream which were not going, and then to create the UAT baseline.  That would work in concept and I'm actively considering it.  I haven't done a proof of concept, I'm not sure I would be able to suspend changesets in a stream or if that's only a workspace option.  Another challenge for me would be that since the two (or three) streams delivering to UAT are fairly long lived, the list of the changesets to suspend would be pretty significant.


What I'd really like to do is somehow create a snapshot of a grouping of changesets but I don't think that's possible.  Right now I'm experimenting with an intermediate "bundling" stream that comes between UAT and PROD.  Thanks for your suggestion!

0
permanent link
Arun K Sriramaiah (3.2k●2●36●77) | answered Dec 06 '13, 5:14 a.m.
Hi Andy,

Yes, you have to suspend the change set before you create a baseline if you don't want to include the change-set into the Baseline.

This should be done from the Repository Workspace ( I mean suspend option).

If your having large number of task than its huge task to do.

Grouping of Changset can be done using the Baseline.

Please let me know if you need any further information.

Regards,
Arun.


Your answer

Register or to post 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.