RTC stream best practice for volatile application maintenance project
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
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 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
Hi Andrew,
Hello Scott,
Thanks again! By "tag" for a release, do you mean baseline?
Regards,
Andrew
1
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
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
|
|
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.