RTC stream best practice for volatile application maintenance project
Andrew
Accepted answer
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
Comments
Hello Scott,
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
1 vote
Hello Scott,
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
1 vote
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.