[closed] RTC upgrade too painful
Lewis Tsao (217●49●63)
| asked Jun 18 '13, 8:36 a.m.
closed Jun 20 '13, 8:28 p.m. by Millard Ellingsworth (2.5k●1●24●31)
The upgrade of RTC between point releases, for example 4.0.1 -> 4.0.3, is too complicated according to upgrade guide.
Is it not possible to create "fix packs" that can be directly applied to current installations? For example, I am using 4.0.1 and there are numerous bugs to do with WI exports and imports, and there are some nice features I need. Because the upgrade is so complicated, the IT department will not entertain the idea of upgrade anytime soon. So I have a problem. If the upgrade can be achieved as a simple "fix pack" that can be applied directly to current installation, then it is so much easier to work with IT department to plan "fix pack" installs.
showing 5 of 7
show 2 more comments
|
The question has been closed for the following reason: "Other" by millarde Jun 20 '13, 8:28 p.m.
One answer
Millard Ellingsworth (2.5k●1●24●31)
| answered Jun 20 '13, 8:28 p.m.
FORUM ADMINISTRATOR / JAZZ DEVELOPER edited Jun 20 '13, 8:38 p.m.
There is a nascent Plan Item tracking upgrade enhancements. I have added a link to this discussion. Please feel free to continue contributing in the work item. I am closing the question as it isn't a question and cannot be resolved via the forum.
Comments Sorry, I couldn't locate the link, can you add again? Thanks. Thanks, Mr Ellingsworth. I have summarized our problem in this work item.
|
Comments
Having "been around" since V1, the upgrades are orders of magnitude simpler than the required steps from v1 > v2. With v2 > v3 (except QM) the process was shortened a great deal and v3>v4 (and interim versions) it's not that awful. My team (myself and one other) have upgraded over a dozen CLM apps in a morning (e.g. 3.0 > 3.0.1.X)
If you follow the instructions and plan the work accordingly the longest step will be the rebuilding of indices.
Just my $0.02
I disagree. I have RTC 4.0.1 and the instructions to update to 4.0.3 have 21 steps. Hardly an easy migration.
I am not saying that the upgrade process has not vastly improved over the versions.
I suppose I am trying to say that depending on environment the work involved can be viewed by IT departments (where H/W, OS admin, RTC, DB, IHS/WAS, are all separate 3rd parties) suddenly becomes very complicated.
Just assuming everything is inhouse, in same room, but different departments. Imagine set up is distributed servers, multiple WAS instances, multiple reverse proxies (for load balancing), hardware load balancers.
The various steps all require different level of involvement from different departments:
1. Side by side install of RTC
2. Uninstall/resinstall of WAR files in WAS (alternatively, extra installation of war files as extra WAS serververs).
3. If extra provisioning, possible reconfiguration of IHS.
4. I can go on.
The point is, if the upgrade can be sent out as "fix packs" that only replace certain jar files then suddenly lots of things become much more possible.
IT departments are much more likely to agree to (more frequent) upgrades.
Having worked in TSIEM (formerly TCIM) support, I have to say the upgrade can, and should be easier. In TSIEM (and I believe this is typical to Tivoli in general) installing a fix pack had two steps exactly:
1. download a self-extracting archive containing the fixpack
2. run it.
My experience as well has not been good for upgrading. In fact when we went from v3.0.1 to v4 we had to have an IBM tech in house and on the phone to help. Anytime that happens the upgrade is not straight forward. I remember IBM asking if we did the worksheets for the upgrade. Worksheets? HA! Also I have certainly experienced incomplete documentation, whether it be missing steps or wrong information. IMO any upgrade that has over 20 steps is not easy or straight forward. One of my biggest peevs is why we must use the Installation manager. So you have to install this so you can then install the application. Crazy! I'm working for a Medical company where we can't just apply an update/fix for anything until we validate it in a test environment, file the report and wait for the report to clear then we can finally upgrade.
That is also my experience. Due to the difficulty of the upgrade procedure, this is perceived as a risk, and thus, we have to conduct a side-by-side upgrade:
* Create a duplicate of the RTC+DB stack at same version as production (version N-1)
* Upgrade the duplicate stack to newer version N
* Test
* Bring down production
* Switch to version N stack as the new production system.
At the very least, the RTC installation procedures and scripts should take the side-by-side scenario into account. We shouldn't have to install and configure a full RTC at version N-1 just to be able to run the DB schema upgrade scripts.
If I duplicate my production DB (version N-1), I should be able to run a DB schema upgrade script to bring the DB schema to version N, then simply do a full RTC/RRC/RQM install at version N on my new machines.
my prior company is doing the 3.0.1 to 4.0.1 upgrade this weekend (if their plans still hold).
and we made a duplicate environment, copied production data, did the upgrade, tested, updated the run book,
and repeated this twice. last time we upgraded we had 1 jts and one ccm. now we had 1 jts, 5 ccms, and all the Rational Insight infrastructure as well. and as its at 3.x it all has to change at once.
IBM was planning to be onsite as well last I knew.