It's all about the answers!

Ask a question

RTC stream best practice for volatile application maintenance project


Andrew Trobec (49713144139) | asked Apr 19 '13, 5:34 a.m.
Hello All,

I am looking for some RTC stream/component/repository workspace management considerations.  Here is a watered down scenario:

I am performing application maintenance on a per CR basis.  Since the CRs impact the same components I want to maintain the development of each CR independently.  Each CR has to go through DEV and TEST before going to PROD.  If three CRs (A, B, and C) are started simultaneously and promoted from DEV to TEST together I want to be able to promote B and C to PROD without any dependencies on A.  In other words, I don't want to have overlaps between the CRs (there will be some cases where this is inevitable but let's assume that dependent CRs will be grouped as one).

What sort of Stream structure would help me to accomplish this?  Assuming there are 3 components: Interface, Classes, and Database, would it be better to create a Stream containing all three components for each phase (DEV, TEST, PROD) or would it be better to create a Stream per CR and track the phase will some sort of parent stream?  My ultimate goal is being able to work on and promote CRs independently since the environment is very volatile.

Is there any documentation describing how to leverage RTC for various development approaches (feature driven development vs. component-based development)?

I hope I have managed to explain myself!

Best regards,

Andrew

Accepted answer


permanent link
Scott Cowan (966310) | answered Apr 19 '13, 4:06 p.m.
JAZZ DEVELOPER
Hi Andrew,

In RTC development, we have an integration stream with all required components where our final product is built.  The builds get tested and periodically we tag one for a product release.

Various teams create streams with a subset of components that flow into the integration stream.  The team streams are where each team validates their work with an appropriate build before delivering to the integration stream.  This approach facilitates component-based development.

Individuals create repository workspaces that flow into their team stream.  Again, each team member should validate work before delivering to the team stream.

We've found this approach allows you to easily create a side stream off of a team stream for feature-driven development.

Whether or not your CRs can be managed independently depends more on whether the change sets required to resolve them conflict with each other.  If they don't, then they can easily be delivered in any order.  If they do conflict, then often conflicts can be resolved automatically.

This article describes more considerations, https://jazz.net/library/article/599.

Scott
Andrew Trobec selected this answer as the correct answer

Comments
Andrew Trobec commented Apr 29 '13, 9:28 a.m.

Hello Scott,


Thank you for the reply and the link.

I read the document and would like to know how to best carry CRs through the various phases: DEV, TEST, and PROD.  This aspect is not addresed in the article.  Is it best managed with streams, components, component baselines, or a mixture?

Regards,

Andrew


1
Scott Cowan commented Apr 29 '13, 9:46 a.m.
JAZZ DEVELOPER

Hi Andrew,

We create the change sets in our repository workspaces, then deliver to the team stream during the DEV phase.  Then we deliver the change sets to the integration stream when they've pass our unit tests.  When an integration build passes it is ready for integration testing (either manual or automated), then finally when an integration build is sufficient, we tag it for a release.

Each build result captures a snapshot of the stream, so each build can be traced back to the components and change sets it's composed of.  A released build has the same traceability.  We don't create streams for each of these phases, although I suppose one could.

Perhaps there are other best practices out there and someone else on the RTC team can chime in here.

Scott


Andrew Trobec commented Apr 29 '13, 10:26 a.m.

Hello Scott,

Thanks again!  By "tag" for a release, do you mean baseline?
Regards,
Andrew 


1
Scott Cowan commented Apr 29 '13, 10:37 a.m.
JAZZ DEVELOPER

You can tag a build result in the Eclipse editor.  It just adds a searchable label to further identify a build result.  You can see the list of RTC Integration builds and the tags we apply for different releases at https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.build.viewDefinition&id=_AHLqcIkAEd6RvINWj6hoDw


Scott Cowan commented Apr 29 '13, 10:40 a.m.
JAZZ DEVELOPER

If you scroll down far enough you can see tags for releases such as 4.0.3, 4.0.1 and they're further qualified with milestone and release candidate numbers m1, m2, m3, rc1, rc2, etc.  The last one for a release will be qualified with ga for general availability.

One other answer



permanent link
Daniel Toczala (88211514) | answered Apr 29 '13, 11:17 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
You can also check out Stream Strategies with RTC on Jazz.net.

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.