How to manage product development using Rational Team Concert
Manoj Panda, IBMLast updated: Dec 19, 2013
Build basis: Rational Team Concert 4.0.5
Introduction
For long term projects that may have multiple releases during a product’s life cycle and require support of previous versions, handling product versioning and branching of the code base is the most important part of release management. Assuming that properly distributed version control is in place, that the teams vary in size, and that developer may be working on multiple projects at once, the major issue that is being faced is that there is a contractual obligation to support old versions as they previous existed which means that new development can not patch old code.
As a result, current product versioning can be convoluted as each main product has multiple dependencies, each with their own versions which may or may change between annual releases. Likewise, while each product has its own repository, most of the work is not done on the main source trunk but rather on a branch for that years product release with a new branch being made when the product is released so that it may be supported. This in turn means that getting a product’s code base isn’t as simple a matter as one might think when using version control.
Demand for more customizable products with multiple options increases the number of product configurations, which complicates design changes. Offering multiple product variants, based on modular product designs, can deliver a competitive advantage, but adds to the complexity that must be managed.
Lets take a scenario, and see how we might approach this scenario while using Rational Team Concert (RTC).
ABS is the name of a company that develops next generation software (NGS) for airlines and has a variety of customers. All customer may not be running the same product version.
Development Teams are working on 3 different product version streams like AA1.0, JetAir1.1 and Lufthansa2.0. This is to deliver immediate support and maintenance.
At the same time the development team is also working on their upcoming new features and releases on a release 3.0 stream.
1. How to know which are the bug fixes/customization/new product feature for each stream or customer?
2. Is it possible to merge only required bug fixes to other customer specific streams, but not the customer specific features?
3. How do you merge to release 3.0 stream selectively so that only the product fix and product feature from other streams come through?
Lets address the above three question using RTC.
There are many streams for new upcoming releases like release 3.0 and customer specific streams like AA1.0 which is owned by the American Airlines development team of ABS, and is the same as JetAir1.1 stream.
Start with a bug fix on AA1.0 stream, Work Item type defect(115) is created and associated with source code.
Similarly there are 2 more Work Items, one isa change in a product specific (say business request i.e. 117) and another change is for customer specific (project change request i.e. 116) worked on AA1.0 stream.
Scenario-1:
Lets merge only one defect (115) which is there in every stream. In this case, this defect needs to merge into JetAir1.1 stream.
You may have lots of changes done on AA1.0 Stream, so lets find out how many change sets have been made in the AA1.0 stream. Click Search=> Jazz Source control=>Change Set. Modify the requirde parameters and click on Search.
In this scenario, there are many change sets as we can see, but we need to merge only one defect i.e. 115.
Again, before you decide what change set needs to be merged, you can also check where these change sets currently exist. Right-click on the particular change set (115) and click on Locate change sets.
As you can see here, the change set 115 is present only on the AA1.0 Stream, but needs to be merge into the JetAir1.1 stream.
Right-click on change set 115, and click Accept. Please note that you need to verify your workspace so that the same artifacts will load into your workspace and then you can deliver to JetAir1.1 Stream.
Now, both streams, i.e. AA1.0 and JetAir1.1, has the same fix/change set 115, but not the other change sets like 116 and 117 which is of course are not required because change set 116 is for a customer specific change which is only for AA1.0, and 117 is a product specific changes what has been planned to be release as a part of release 3.0.
Scenario-2:
As a part of release 3.0, we need to bring all the fixes done in the AA1.0 stream as well as the product specific changes. So in this scenario, we need to merge only 115 and 117. So again do the same search for change set as we previously did.
Here we can see change set 118 which already exists as a part of release 3.0. Right-click on both 115 and 117, click on Accept and then deliver. This is exactly what the business needs. As we observed, only the defect and product specific changes merged to the release 3.0 stream. But, for the JetAir1.1 stream, only the defect has been merged.
In this article we looked at using RTC 4.0.5 to:
- Merge specific changes to the required stream
- Follow the best practice for the product development
- Locate/find your change set
About the author
Manoj Panda is a Senior IT Consultant at IBM Rational. He has worked on Project Management, Release Management last ten years and having 19 years of IT experience. He can be contacted at manoj.panda@in.ibm.com.Copyright © 2014 IBM Corporation
Yes