It's all about the answers!

Ask a question

Switching between Maintenance and Production streams


Richard Daugherty (611) | asked Feb 07 '12, 5:29 p.m.
In the VS2010 RTC client, how does one switch between development and maintenance? I've been searching jazz.net for articles and haven't found anything yet.

I'm also wondering if perhaps I've defined my sandbox at too high a level and if this might be complicating matters. For example my sandbox is at c:\inetpub\wwwroot\ in which I have quite a few projects, each under source control with it's own repository workspace in RTC.

Here's the scenario I'm trying to figure out. Let's say I've delivered a baseline to one stream and it's promoted to production. Next I fork the code and have production in the Maintenance stream, and then launch work on enhancements in the Development stream. Now let's say a bug shows up in production that the users require an immediate fix for. How do I switch from Development to Production without losing my work in process for Development? Once done, how do I switch back? (hopefully it's the same process).

4 answers



permanent link
Ralph Schoon (63.0k33645) | answered Feb 13 '12, 4:17 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Richard,
I can not test that right now, but I think I remember from 3.0 you can switch between sandboxes. You could have more than one sandbox loaded to your machine and change the active sandbox.

permanent link
Sreerupa Sen (1.0k4) | answered Feb 21 '12, 7:25 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
Hi Richard,
I'm not really sure what you meant by switching back and forth in this particular context - repository workspaces? sandboxes?
Here's how we do it in the RTC VS Client team. We have a repository workspace that flows to the maintenance stream and another that flows to the main development stream. The repository workspaces are loaded in different sandboxes in the filesystem. If we fix a bug in say the maintenance stream, we accept the change set(s) from the work item into the main development workspace. Or if it's a simple fix, we change the flow target of the maintenance workspace to the main development workspace and deliver the change there as well.

This change may need to be merged in to the main workspace or may produce compile errors. That's why it's first
delivered to a repository workspace, compiled, tested and
then delivered to the main development stream.

The workspaces are loaded in different sandboxes. In the VS Client's the Team Artifacts Navigator there's a node named Sandbox History under which we have an MRU list of the sandboxes. Using the context menus on these sandboxes it's easy to switch sandboxes.

If this isn't what you asked, please let us know.
Cheers
--Rupa

permanent link
Richard Daugherty (611) | answered Mar 06 '12, 5:58 p.m.
Hello sreerupa,
Until you replied I wasn't sure how to even frame the question properly. When RTC was implemented here the IBM trainer didn't cover how to switch between development and production other than that it was possible. We certainly didn't practice it.

From a Visual Studio point of view, I have one project on my filesystem. From an RTC point of view that project lives in it's own (singular) repository workspace which in turn lives in my sandbox. The sandbox is defined at c:\inetpub\wwwroot. Most of my projects are web development and so the individual project directories live under that directory structure so my sandbox encompasses them all.

My understanding from the training was that one would switch between streams, but we didn't practice doing it and I have no procedures or best practices for doing so. That's what I'm looking for. When I initially got no response on this post I did log PMR's for this.

Conceptually, I understand what you're talking about in your reply, but in practice, I have no idea how to implement what you're describing. I would be very grateful (as will my co-workers) if I can get documentation on how to do this.

FYI, I didn't get notified via email of your reply so I had stopped watching this post. I just checked my junk inbox and there's nothing in it. Very strange!

Thanks!

Rich


Hi Richard,
I'm not really sure what you meant by switching back and forth in this particular context - repository workspaces? sandboxes?
Here's how we do it in the RTC VS Client team. We have a repository workspace that flows to the maintenance stream and another that flows to the main development stream. The repository workspaces are loaded in different sandboxes in the filesystem. If we fix a bug in say the maintenance stream, we accept the change set(s) from the work item into the main development workspace. Or if it's a simple fix, we change the flow target of the maintenance workspace to the main development workspace and deliver the change there as well.

This change may need to be merged in to the main workspace or may produce compile errors. That's why it's first
delivered to a repository workspace, compiled, tested and
then delivered to the main development stream.

The workspaces are loaded in different sandboxes. In the VS Client's the Team Artifacts Navigator there's a node named Sandbox History under which we have an MRU list of the sandboxes. Using the context menus on these sandboxes it's easy to switch sandboxes.

If this isn't what you asked, please let us know.
Cheers
--Rupa

permanent link
Sreerupa Sen (1.0k4) | answered Mar 08 '12, 4:38 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
Hi Rich,

Here's a shot at answering your question based on what I've understood. In some of the steps, there are multiple ways of doing things, I've just stated one to keep this short.

Let's say I'm going to work on two releases - a maintenance one 1.1 and a release one 2.0. At the start both of them start from the code base of 1.0.

So at the start I duplicate Stream_1.0 into Stream_2.0 and Stream_1.1, using the 'Duplicate' menu item on a stream in the Team Artifacts view.

Next I create two repository workspaces for myself - Rupa_1.1 and Rupa_2.0 from Stream_1.1 and Strem_2.0 respectively. I can do that via the 'New Repository Workspace' menu item on a stream.

I load Rupa_1.1 into c:\mysandboxes\1.1_work and Rupa_2.0 into c:\mysandboxes\2.0_work. Note that these are two different sandboxes altogether and they share a parent for convenience - you could load them into entire different folder hierarchies. It's important that you load them in different sandboxes, otherwise you may end up overwriting your code.

Now I start working on 2.0 delivering into Stream_2.0 and 1.1 delivering into Stream_1.1. I have a VS instance opened on a solution or project in c:\mysandboxes\1.1_work, delivering into Stream_1.1. I have another VS instance opened on a solution or project in :\mysandboxes\2.0_work, delivering into Stream_2.0. Note that I cannot work on two different sandboxes at the same time from the same RTC VS instance.

I make a bugfix to file File1.cs in c:\mysandboxes\1.1_work, which gets delivered into Stream_1.1. I need to deliver the same into the 2.0 release as well. There are various ways of doing this.

One Way
---------------
1. After I deliver my changes to Stream_1.1, I use the 'Change Flow Target' menu option on Rupa_2.0 in the Pending Changes view, and change the flow target to Stream_1.1
2. I'll see lots of changes. I carefully choose the one I want to accept, I accept that change set to Rupa_2.0 from Stream_1.1.
3.If there are conflicts, I merge and resolve them.
4. I switch my flow target back to Stream_2.0 and test and deliver.

Another Way
-----------
1. I associate my changeset with work item 123 when I deliver in VS instance 1.
2. In VS Instance 2, I open up work item 123, and from the menu in the work item editor, I choose 'Explore Change Sets'.
3. This opens up my change Set(s) in the change explorer.
4. I multi-select the changes I need and 'Accept' them into my
workspace.
5. I may need to work on them some more, or test them in the 2.0 code base. Once I'm done, I deliver it to Stream_2.0.
6. Sometimes it may happen that File1.cs has moved along in the 2.0 code base, and in that case, the accepted changes cannot automatically be merged into my workspace. Instead RTC will create what it called a 'Patch' which will show up in my Pending Changes view and which I will have to merge with the 2.0 code using the 'Merge into Workspace' command.

This is a rather long winded response - I hope you find it useful. If you don't, please feel free to ask questions.

Here are some articles I found;
http://www.ibm.com/developerworks/rational/library/parallel-development-rational-team-concert/index.html
https://jazz.net/library/article/40

Cheers
--Rupa

Your answer


Register or to post your answer.