What is the best way to baseline and build selective changesets?
3 answers
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
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!
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
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. . ?
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...".
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
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.
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.