You can associate Rational Engineering Lifecycle Manager products and Rational Team Concert streams and component baselines. Rational Team Concert streams are organized as a flat list of component baselines, and cannot represent the underlying component hierarchy of real-world projects. Rational Engineering Lifecycle Manager provides a way to view and manage a hierarchical structure.
The initial setup describes the first step, how to connect the streams and component baselines in Rational Team Concert to the products in Rational Engineering Lifecycle Manager. In all workflows, at least one team member must manage the stream for your team. This team member might be a development lead or team manager. Stream managers decide which of the following scenarios their teams need, and then follow the workflow to understand the steps to use it.
Streams and component baselines are not stored in the index. Rational Engineering Lifecycle Manager and Rational Team Concert exchange component baselines with each other directly, without using the index. For the exchange to occur, your administrator must establish a friend relationship between the servers. See Establishing cross-server communication to enable Rational Engineering Lifecycle Manager OSLC preview. Your administrator can manually set all of the Rational Team Concert servers that you want to connect to. Set servers on the Application Administration screen > Settings page > Integrations > Rational Team Concert.
Before you can exchange component baselines between tools, you must set up the streams and component baselines that your team needs to complete product development. Although your team might include many projects as part of the component baselines, projects are not part of the integration. Projects are not part of the setup.
You can add as many components to the stream as your team needs for their project. As the project moves through iterations, you might add or remove more component baselines. In other words, the stream you are creating might or might not be the final one, which is alright. The integration is flexible enough to allow modifications during any point in development.
See Creating streams. To learn more about streams, see, Streams and components.
The stream manager can then receive or send component baselines between the tools.
You can connect a stream to only one product.
Both receiving and sending component baselines are initiated from Rational Engineering Lifecycle Manager. You can receive and send component baselines as often as needed. For example, your team requires a new component part way through development. You add it to the stream, and receive it in Rational Engineering Lifecycle Manager immediately or whenever you have time.
Use products to organize component baselines in the product tree in a way that makes sense for your project. To organize component baselines, you can move them so that they are nested, add links to artifacts and URLs that affect the component baseline, and add custom properties. You can also reuse component baselines by creating child products to gather the component baselines that you want to reuse.
This action updates the list of component baselines in the Rational Team Concert stream with the changes you made in step 5. If you moved products, but did not remove or add products that are connected to component baselines, you do not need to send components to Rational Team Concert.
The following workflows describe how to get updates from Rational Team Concert streams, reuse component baselines, and branch a product and then share it. Each workflow assumes that you completed the Initial setup. (Your team might not use the load rules in step 2.)
In this scenario, your development team works in the stream that you created for them. In the stream, you added or removed component baselines to support the development effort.
The Rational Team Concert stream might now look different from the Rational Engineering Lifecycle Manager product hierarchy that is connected to that stream. You are ready to receive the updates that you made in Rational Team Concert streams into Rational Engineering Lifecycle Manager.
This process is a natural part of development. Your development team might request many changes or just a few, depending on the project length, how much function is changing for the release, and many other reasons. New projects might contain many changes to the stream, but established projects might not require as many.
See Receiving and sending component baselines.
New component baselines are added to the product tree directly under the product that is connected to the stream. The new products are given the same name as the incoming component baselines and the same version as the baseline name.
If there is an existing tip product for an incoming component baseline, Rational Engineering Lifecycle Manager reuses that tip product.
If an existing product that is not the tip product has a matching component or baseline, Rational Engineering Lifecycle Manager does not reuse the product. Instead, Rational Engineering Lifecycle Manager creates multiple products that are connected to the same component baseline, each with their own unique product history. In this case, each connected product is insulated from the other.
Any product that is connected to a component baseline that is no longer used in the Rational Team Concert stream is removed.
In this scenario, your team wants to reuse component baselines from their stream or from other streams. Reuse gives projects modularity. If you created a component baseline that works for multiple parts of a product, you can reuse it. For example, suppose you created a GPS component baseline that can be used in 10 different mobile phones (10 streams). Reusing the GPS component baseline in different streams saves development time.
To reuse component baselines, you must create a product to gather the component baselines that you want to reuse. The product is not connected to a stream, but resides under the product that is connected to the stream. The following scenario describes the steps to reuse component baselines.
Use the child product to gather the component baselines that you want to reuse.
You can replace individual products that are connected to the component baselines or the product that gathers all of the component baselines.
Replacing versions pins the products. If the reused product hierarchy is modifiable, any change that is made to the reused product hierarchy shows in the pinned product hierarchy. See Versions and variants.
In this scenario, your team wants to create a variant of a product that is connected to a stream and then reuse it where necessary. Branching provides teams with the flexibility to create variants of a product whenever the time is right. For example, a team might need to create a different flavor of a product.
If you no longer want to send or receive components for a branch, but you might want to work with the same stream again, disconnect the tip of the branch from the stream before you make your final baseline. If you forget to disconnect, you might have to check out the branch again to disconnect it from the stream before you can connect that stream to a different product. (A stream can be connected to one branch of one product.)
See Replacing a branch.
Any products or child products that you create in the product tree follow the rules of product tree management. See Versions and variants.
Load rules define a subset of a product hierarchy to load into a Rational Team Concert workspace. In Rational Engineering Lifecycle Manager, you can export a load rules file. In Rational Team Concert, after you add component baselines to your repository workspace, you can use load rules to load only the component baselines you want to work on.
See Generating load rules for component baselines.
For details about load rules, see Loading or unloading repository workspaces
Developers work in Rational Team Concert workspaces. If team members need a component added to or removed from the stream, they typically ask the stream manager, a development lead, or team manager to do it. The stream manager fulfills the request. The developers accept the changes that are made to the stream, and the team members continue with their work, as in the following workflow.
See Checking in unresolved changes and Delivering change sets.