It's all about the answers!

Ask a question

Using RRC and RQM 4.0.2, now ready to upgrade RTC 2.0.0.2 to 4.0.2, seeking migration advice


Paul Sims (31513421) | asked Aug 18 '11, 11:57 a.m.
edited Apr 22 '13, 6:23 p.m.
This is an earlier question, updated to reflect where we—the IBM WebSphere Commerce development team—are today. I left the original text indented below so you can refer to it.

We adopted Eclipse 3.6 (we now support Rational Application Developer 8.x) in the WebSphere Commerce Developer's Toolkit released last Friday with IBM WebSphere Commerce V7.0 Feature Enhancement Pack 6 (FEP6). Because of this, we are no longer restricted to using RTC Release 2.x and can upgrade to Release 4.0.2. We understand there is no direct upgrade path from Release 2.x to Release 4.x, so we'll include Release 3.x in a step-wise process.

Until the IBM WebSphere Commerce V7.0 FEP5 release is out of service, we need to have access to an RTC environment that works with FEP5 and earlier IBM WebSphere Commerce Developer's Toolkits. These Toolkits are based on Eclipse 3.4 and thus only work with RTC 2.x and earlier releases.

First question: Can anyone think of an imaginative and efficient way to work with RTC-managed source code using Eclipse 3.4 when that code resides in an RTC 4.0.2 or later repository?

While we lagged behind on RTC 2.0.0.2, we kept our RRC and RQM project areas up-to-date. Our RRC and RQM project areas are on a separate CLM 4.0.2 instance named ecdclm and are connected to our RTC 2.0.0.2 project area, which runs on an instance named kanrtc01. Our environment uses WebSphere Application Server and DB2.

Second question: Is there any way for us to bring back together our RTC and RRC/RQM instances under a single hostname, or will we be forced to run RRC/RQM and RTC on separate servers forever? We are wondering if the host renaming tools available in recent CLM releases can help us converge the two server instances (kanrtc01 and ecdclm).

We look forward to receiving feedback and suggestions from the Jazz Community. I expect other teams may face a similar problem, so we hope it's something we can come up with a solution to.

- Paul

Previously posted on 18 Aug 2011.
The IBM WebSphere Commerce development team uses RTC 2.0.0.2 running on Linux with WebSphere Application Server and a DB2 UDB back end. All Scrum teams use RTC's planning and reporting features. A few use RTC's SCM and build features. Others use an internal SCM application (CMVC).

The Commerce team's development environmentWebSphere Commerce Developer Editionis based on Rational Application Developer (RAD) Version 7.5.x. In the future the team will move to RAD Version 8.x. Due to the development environment, the team cannot immediately adopt RTC 3.0.1 because the RTC plug-in for Rational Application Developer 7.5.x is incompatible with the 3.0.1 server.

For this reason, we want to deploy /rm 3.0.1 and /qm 3.0.1 and continue using the RTC 2.0.0.2 project area, tracked and tested by /qm with RTC tracking /rm. We believe this is a supported configuration. If it is not, please tell us now.

Knowing that Requirements Composer uses the /ccm database, we're concerned about problems that could arise when we want to upgrade our RTC server. Will we have to merge the /rm data from the /ccm database with the RTC database? Is that even possible?

We are seeking advice about how to plan our upgrade so we don't "paint ourselves into a corner" due to making a poor decision now.

3 answers



permanent link
Rosa Naranjo (2.9k11723) | answered Aug 18 '11, 2:27 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
Paul
It is possible to continuing using the RTC 2002 server as a friend of the 301 RQM and RRC servers. The 3.0.1 JTS associated with the 3.0.1 RQM and RRC servers just needs to be made aware of the RTC 2002 server. This is actually one of the steps in the 'Configuring the server' section of either an upgrade or a new 3.0.1 installation (not sure if your RQM and RRC applications are upgrades or brand new installations).

See this link: http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0m1/topic/com.ibm.jazz.install.doc/topics/t_upgrade_add_friend_relationships_jts.html

I am not sure what you mean by 'Knowing that Requirements Composer uses the /ccm database...'.

RRC v3.01 uses the same data storage as the JTS 3.0.1. I need to understand more what your concern is here.
See these links as well for more information regarding topology and planning:
http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0m1/topic/com.ibm.jazz.install.doc/topics/c_understand_upgrade.html
http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0m1/topic/com.ibm.jazz.install.doc/topics/c_deployment_topology_considerations.html

Look at the topology examples in the infocenter for v3.0.1 as well as the Upgrade workshop materials available here: https://jazz.net/library/article/662

At the time of the deployment of RRC and RQM 3.0.1, you will decide how the JTS 3.0.1 application will be installed/deployed/configured: either as a single app on one app server, or colocated with one of the CLM applications. You will also decide on the topology for your RRC and RQM applications. All example departmental and enterprise topologies illustrate the use of a single, shared Jazz Team Server for multiple distributed applications.

At the time of the RTC upgrade to v3.0.1, in order to take advantage of the benefits of using a shared JTS, you would just point the CCM upgrade scripts to the existing JTS that was established at the time of the RRC and RQM 3.0.1 installations.

The IBM WebSphere Commerce development team uses RTC 2.0.0.2 running on Linux with WebSphere Application Server and a DB2 UDB back end. All Scrum teams use RTC's planning and reporting features. A few use RTC's SCM and build features. Others use an internal SCM application (CMVC).

The Commerce team's development environmentWebSphere Commerce Developer Editionis based on Rational Application Developer (RAD) Version 7.5.x. In the future the team will move to RAD Version 8.x. Due to the development environment, the team cannot immediately adopt RTC 3.0.1 because the RTC plug-in for Rational Application Developer 7.5.x is incompatible with the 3.0.1 server.

For this reason, we want to deploy /rm 3.0.1 and /qm 3.0.1 and continue using the RTC 2.0.0.2 project area, tracked and tested by /qm with RTC tracking /rm. We believe this is a supported configuration. If it is not, please tell us now.

Knowing that Requirements Composer uses the /ccm database, we're concerned about problems that could arise when we want to upgrade our RTC server. Will we have to merge the /rm data from the /ccm database with the RTC database? Is that even possible?

We are seeking advice about how to plan our upgrade so we don't "paint ourselves into a corner" due to making a poor decision now.

We look forward to receiving suggestions from the Jazz Community.

permanent link
Jim Ruehlin (79114) | answered Aug 18 '11, 2:30 p.m.
JAZZ DEVELOPER
The RM application does not use the RTC database in 3.0.1. It uses the JTS's database, as it does in 2.x. So there are no worries about impacting the RTC upgrade when upgrading RRC.

Because Jazz uses REST and OSLC, links between apps are forward and backward compatible. So you can upgrade QM and RM to 3.0.1, leave RTC at 2.x, and still maintain/create CLM links between the data in these applications. The Upgrade Workshop steps you through how to do this.

The InfoCenter has good material on planning and performing your upgrade. Generate customized installation instructions from the Interactive Upgrade guide.

Use the Upgrade Workshop to understand how to perform the upgrade.

There is also advice and tips on the JazzPractices blog.

permanent link
Paul Sims (31513421) | answered Aug 18 '11, 2:46 p.m.
Rosa and Jim, thank you for your replies. I will share this information with our hosting team in Ottawa. Jim, I discovered the upgrade workshop earlier today and will review the material.

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.